Licence Changes and Naming of a Commercial Derivative

[Jimmy Kaplowitz]

Hi,

I gave some of these responses on IRC, but here's a more complete version:

On Mon, Dec 17, 2012 at 11:09:19AM -0400, David Pratt wrote:
> Hi, I have two issues I'd appreciate advice about for our TideSDK project.
> 
> The first is that the core talent of TideSDK wish to create a
> commercial derivative work called TideSDKPro.

Please avoid conflating "commercial" and "proprietary". Commercial means there
is ongoing exchange / buying / selling of merchandise (cf wiktionary entry on
commerce). Proprietary means that software freedom isn't preserved for the
recipient. Mozilla Corporation is an example of a commercial entity, even
for-profit, which focuses on (mostly) free and open-source software like
Firefox. It has revenue from revenue sharing deals with search engines,
merchandise sales, and the like.

> I understand that we cannot create a for profit commercial entity under a non
> profit organization so a comercial entity has been established.

It's not strictly true that non-profit organizations can't own commercial
entities - Mozilla Foundation owns Mozilla Corporation - nor that they can't
charge for some things directly. However, given both the wording and spirit of
SPI's corporate purposes, SPI shouldn't sell proprietary software or own a
for-profit company that does.

> The first question relates to our use of a related product name. The core
> contributors of TideSDK involved in the commercial entity wish to retain an
> association with TideSDK in name only for the commercial entity. The TideSDK
> is an open source under a non-profit and will continue this way. TideSDK will
> be continued to be developed by us.  The commercial entity will abide by the
> existing Apache 2 license and build on top of the open source code. The
> commercial entity will also contribute code to TideSDK under its licensing
> terms.

If it's not associated with SPI, I don't see an obstacle here in terms of SPI
rules. I would encourage you to consider other options for any needed revenue
generation, since often the existence of a proprietary derivative tied to the
free software project's core team causes the pace of the free project's
development to slow way down and impedes the acceptance of patches from
non-core contributors. If the license is Apache 2, of course, yours may not
remain the only proprietary derivative. See below about how a license change
could affect this.

> My questions is this:
> 
> Does SPI have any policy around the naming? Is there anything
> preventing us from using a name derived from our open source project?
> There seem to be other projects that have done such things. The most
> recent in memory was Couchbase and CouchDB. Couchbase was formed by a
> group of CouchDB's core contributors while CouchDB was Apache 2
> licensed software.

Unless you've transferred any naming rights surrounding TideSDK (e.g. trademark
rights) to SPI ownership, we don't have an applicable policy. For such rights
which SPI does own,
http://www.spi-inc.org/corporate/resolutions/1998/1998-11-16.iwj.2/ together
with relevant bits of
http://www.spi-inc.org/corporate/resolutions/2004/2004-08-10.iwj.1/ is our
policy.

However, if the TideSDK project wants to retain any measure of control over the
word TideSDK (e.g. as a registered or unregistered trademark), it may wish to
develop a trademark policy. This is even more true when creating a derivative
using the TideSDK name. If SPI is to own the trademark, this can be done in
consultation with the SPI board and our legal counsel at the Software Freedom
Law Center.

> The second issue for consideration is a licensing change from the Apache 2
> license to another open license of our choosing. We know we want a license
> that encourages those using our code to contribute back to the code base and
> perhaps something copyleft. We have a growing base of users and we'd like to
> get this sorted sooner than later. My second question is this:

If you go to a copyleft license like GPL, or even a copyleft license which
triggers obligations in the SaaS/website context like the AGPL, any proprietary
derivative couldn't be created within that license. A proprietary derivative
could be created if all copyright holders grant separate permission or assign
copyright to the proprietary licensor, since then the copyleft wouldn't apply
to the proprietary product.

While this doesn't violate any specific SPI rule if done outside of SPI, it
does have the downside of "some developers/products/etc are more equal than
others", and impedes acceptance of patches from non-core contributors unless
they agree to a copyright assignment or special permission grant in favor of
the proprietary licensor.

To sum up, none of this violates SPI policy unless you wanted SPI to do it, but
the license change will have certain consequences and looks bad to large chunks
of the free software community. It's more common among startups that want to
get no-cost development and PR/goodwill by dabbling in open source than among
free software projects.

> How should we go about the license change to ensure this is handled properly
> for our team and contributors.

Speaking generally, any license change should receive written consent from all
copyright holders.  The set of copyright holders is mostly equivalent to the
set of contribution authors, except for those authors whose total contributions
have been trivial (e.g. just a one-character typo fix), and except for the fact
that sometimes the author's creation may be owned by someone else like their
employer.

If you want specific legal advice on this in the context of the TideSDK free
software project which is associated with SPI -- not in the context of your
proprietary derivative -- we can involve our SFLC legal counsel. That would
best be done away from spi-general and spi-private because of attorney-client
privilege implications.

- Jimmy Kaplowitz
jimmy at spi-inc.org