[Harmony-Review] Assignment to a non-profit should be required to stay with a non-profit

Allison Randal allison at lohutok.net
Sun Apr 10 20:57:03 UTC 2011


On 4/8/11 2:53 PM, David A. Wheeler wrote:
> Many people (including me) perceive assigning to a non-profit as
> being *fundamentally* different than contributing to a for-profit.
> But with the the current text, after assigning to a non-profit, the
> work could end up getting controlled by a for-profit.  Maybe the
> non-profit went bankrupt or for some other reason had to "sell" its
> assets; maybe a judgement forced a transfer.  I think that will have
> a chilling effect on potential contributions.
>
> I think the assignment text needs to add a clause like this: "If we
> are a non-profit at the time of your submission, then your
> contribution cannot be later re-assigned to a for-profit
> organization."  Or something like that.  That way, for-profits and
> non-profits can use the same agreement, but contributors will know
> that what was contributed to a non-profit will stay that way.

This is something we talked about over several drafting sessions. The 
tricky part is that many countries already have laws about what a 
non-profit can do with their intellectual property (code, documentation, 
etc). For example, here's part of the articles of incorporation of one 
of the free software non-profits I work on (located in the USA):

------
Upon the winding up and dissolution of the Corporation, the assets of 
the Corporation remaining after payment of or provision for payment of 
all debts and liabilities of the Corporation shall be distributed to an 
organization or organizations, as determined by the Board of Directors, 
that are recognized as exempt under Section 501(c)(3) of the Code or any 
successor provision, and used exclusively to accomplish the purposes for 
which this Corporation is organized.
------

Translating to plain English, that's: "your contribution, or donation, 
or whatever the non-profit owns, cannot be later given to a for-profit". 
It's an essential part of becoming a non-profit, proving that you don't 
intend to divert the assets to some for-profit purpose at a later date. 
(Governments really don't want organizations to skip out on taxes for a 
number of years claiming to be doing work for charity and public benefit 
and then suddenly turn that around to private profit.)

So, putting language about non-profits and for-profits into the Harmony 
agreements is problematic for two reasons:

- This is already pretty well handled by non-profit laws in various 
countries, so it's redundant, and,
- It's handled slightly differently in each country, making it very 
difficult to craft very specific language that can also apply well 
internationally.


We decided to address the concern more generally, for *all* cases where 
the contribution changes hands. Talking through it, we came to the 
conclusion that the core of the issue isn't so much "who holds the 
contribution" as it is "what they are allowed to do with the 
contribution". The relevant text is near the bottom of the agreements:

"Either party may assign the rights and obligations under the Agreement 
to any third party if the third party agrees, as a condition of the 
assignment, in writing to abide by the rights and obligations in the 
Agreement."

What this says in plain English is "even if this contribution changes 
hands someday, the new rights-keeper is bound by the same terms that the 
original one was".

As an example, let's say a developer in the Silicon Valley starts a free 
software project, we'll call it FMing (a website, service, and APIs for 
sharing/streaming Creative Commons licensed music). FMing becomes wildly 
popular, and catches the attention of a large, multinational 
corporation, we'll call it Frooppie.

Frooppie offers to purchase FMing for some enormous sum. FMing's primary 
developer decides this is a great opportunity for her project to see a 
wider audience (or maybe that she's tired of living on Ramen noodles in 
a rathole apartment, or some other combination of motivating factors), 
and accepts the offer. Where does this leave FMing's contributors?

If FMing was using a Harmony contributor agreement, then as part of the 
purchase Frooppie would be required to respect the terms of the 
agreements already in place with the contributors. This is where the 
project's choice of Harmony options becomes highly relevant. When FMing 
adopted a Harmony agreement, they had to choose between several options: 
license vs assignment, and one of five ways of handling the outbound 
license. (To be clear, the project chooses the options once, and every 
contributor signs the same agreement with the same options.)

The choice between license and assignment isn't actually relevant in 
this example, because the difference between "I own the code I wrote, 
and you can also do whatever you want with it" and "you own the code I 
wrote, and I can also do whatever I want with it" has no practical 
effect here. We were enormously careful in drafting the Harmony 
agreements to make that true.

The choice that is relevant to this example is the option about the 
outbound license. Different projects have different cultures, values, 
and needs, and those will feed into their choice of options. I'll only 
describe the effects of two options here, because the others are on a 
spectrum between the two. For illustration, we'll say FMing uses the 
Affero GPL for their code.

(Option One) The FMing community highly values the GPL-style philosophy 
of "freedom means users have the right to look at the source code and 
all changes to the source code". They pick Option One, saying that the 
project will only release contributions under the AGPL. When Frooppie 
buys FMing, they are also obligated to only release contributions under 
the AGPL. (There are good reasons why a project might not choose Option 
One, especially if they think they might need to change the project's 
license at some point in the future. But, in a scenario like this one, 
tighter restrictions might be more important to the community than 
greater future flexibility.)

(Option Five) The FMing community highly values the BSD-style philosophy 
of "freedom means developers have the right to change the code and use 
it for their own purposes". They pick Option Five, saying the project 
can release under any license, but will also release contributions under 
the current license. When Frooppie buys FMing, they take on the same 
obligations to the contributors. If version 1.0 of FMing is released as 
AGPL, version 2.0 might be BSD license, but any contributions to 1.0 
will also be AGPL. There are various ways Frooppie might release the 
contributions under AGPL. One possibility, Frooppie might publish a 
patch list of all the contributions accepted for 1.0, so anyone can 
assemble the AGPL release with the later AGPL contributions. Another 
possibility, Frooppie might release version 1.9 as AGPL with all the 
contributions included, before releasing 2.0 as BSD. However Frooppie 
publishes them, the important requirement is that since 1.0 and the 
contributions have been released as AGPL, those lines of code in that 
release are always available to the world as AGPL, no matter what 
license future releases use. The same is true of contributions to the 
2.0 release: since the code is under the BSD license, the contributions 
will also be available under the BSD license. (There are also good 
reasons why a project might not choose Option Five. Again, it's 
restrictions versus flexibility, a choice that each project makes for 
itself.)

For either option (and any of the range of options between the two) the 
contributors have effectively said "whoever holds these rights we're 
granting, you will respect our wishes". It's a powerful tool for 
contributor's rights, far more powerful because it covers all scenarios 
than it would be if it only covered transfers from a non-profit to a 
for-profit.


Thanks for the thoughtful comment, this is an important point to talk about.

Allison


More information about the Harmony-Review mailing list