Re: Fwd: Licence Changes and Naming of a Commercial Derivative

Hi David,

Cool. Glad you're taking a thoughtful approach. Only a few brief comments left from me:

* Debian is already working with SPI and SFLC on a trademark policy for Debian.
TideSDK does not have to have the same trademark policy as Debian, but looking
at Debian's for ideas is reasonable. A July 2012 draft is at
<http://lwn.net/Articles/509124/>, and you may want to reach out to the Debian
Project Leader (Stefano Zacchiroli <leader(at)debian(dot)org> or zack on OFTC) and
introduce yourself for further discussions.

* If TideSDK wants to register the trademark via SPI, email legal(at)spi-inc(dot)org
and CC board(at)spi-inc(dot)org, but leave off more public lists given that it
involves legal advice. TideSDK would need to have sufficient funds to cover
applicable government filing fees, but SFLC's legal assistance for a task like
this (assuming it stays routine) would not incur a fee. SFLC may also advise if
you prefer to go for an unregistered trademark and want SPI to clearly own it.

* More generally, legal advice on licensing changes for TideSDK, to the extent
it remains free software, should be available via SPI's relationship with SFLC,
as described above. Preserving attorney-client privilege means that your legal
advice communications probably shouldn't be CC'ed as broadly as even
spi-private. They should be restricted to SPI's lawyers (legal(at)spi-inc(dot)org aka
SFLC), board members, and individuals in TideSDK who need to be in the loop. If
you have more questions about what attorney-client privilege means as applied
to TideSDK and what the impact of not preserving it is... ask the lawyers. :)

* The first time you discuss something with SFLC related to your planned
derivative, be sure they understand your intentions clearly. Not only will it
ensure they give you the best advice, they should know that the TideSDK core
team has multiple distinct roles. In those situations where the interests of
TideSDK are at odds with your derivative or with you as individuals, they would
represent TideSDK. (Similarly, if TideSDK's interests are ever at odds with
SPI, they'd represent SPI. This will hopefully never become relevant.)

OK, not as brief as I thought. Have a good night! :)

- Jimmy

On Mon, Dec 17, 2012 at 09:46:51PM -0400, David Pratt wrote:
> Sorry missed the general list in the reply
>
> ---------- Forwarded message ----------
> From: David Pratt <david(dot)pratt(at)tidesdk(dot)org>
> Date: Mon, Dec 17, 2012 at 9:45 PM
> Subject: Re: Licence Changes and Naming of a Commercial Derivative
> To: Jimmy Kaplowitz <jimmy(at)spi-inc(dot)org>
>
>
> Hi. Thank you for the replies. We are amidst some critical decisions
> about how we should structure our efforts for the future. We love what
> we do together in the open project and hoped the thousands of uses we
> have would respond to donation.
>
> Regardless of what we will do, there will be ongoing work on TideSDK
> and it will continue being maintained and improved. The bottom line
> for us is we want to see our amazing software survive and to meet the
> needs of developers globally. We have a strong vision for it and we
> cannot move fast enough without full time efforts and resources. The
> donations have been helpful but far from enough for dedicated full
> time people. We had managed to secure build servers and bandwidth for
> a year through donation which was very much appreciated.
>
> Despite having a team of 17, there is a handful of truely dedicated
> talent that contributes the majority of the code. This is a pattern
> repeated in most projects. Currently the most dedicated souls are
> working 16 - 20 hrs per day to push ahead. We've learned so much
> already from our experience with TideSDK and the derivative itself
> will be dual licensed and not strictly proprietary since it will have
> a different set of capabilities. We understand open source and have
> worked in it for many years.
>
> We had thought about the use of TideSDK in the naming for this. It
> does not make sense for a variety of reasons. We don't want to confuse
> our users or disrupt our community that we have grown around it. A
> trademark policy makes sense for it and I would like to work out a
> policy similar to that applied by the Apache Foundation for its
> brands.
>
> For the licensing decision, we need help with the legal aspects to
> determine the best license solution to meet our needs - and to
> approach this properly for the changes to take place. We understand
> the implications to our community of a licensing change. It may be
> that we do nothing about changing the licensing but we feel it is
> needed for good reason. I will move this discussion to spi-private as
> a result.
>
> Regards,
> David
>
>
> On Mon, Dec 17, 2012 at 12:19 PM, Jimmy Kaplowitz <jimmy(at)spi-inc(dot)org> wrote:
> > 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(dot)org
> _______________________________________________
> Spi-general mailing list
> Spi-general(at)lists(dot)spi-inc(dot)org
> http://lists.spi-inc.org/listinfo/spi-general