[Harmony-Review] Providing a copyleft-compatible option?

[Allison Randal]

I left this one for the lawyers to respond, but it looks like it got 
lost. I'll prompt the drafting group. In the mean-time, here's a 
layman's answer.

On 04/17/2011 08:24 AM, Dan Scott wrote:
> Over on identi.ca, a lengthy thread has brought up a number of issues
> (some more substantial than others, IMO). One of those issues is that
> the current CLA drafts don't include an outbound-licensing option that
> ensures that a contribution submitted under a copyleft license will
> remain copyleft.
>
> We added 2.1(d) option 4 ("any licenses which are recommended by
> the Free Software Foundation for use in GNU projects") thinking that
> that would satisfy the desire for a copyleft-only set of outbound
> licenses, but:
>
>    * Is a clear list of licenses which satisfies this condition published
>      anywhere? From the FSF side, I found a list of GNU licenses at
>      http://www.fsf.org/licensing/education - but those aren't explicitly
>      identified as "recommended for use in GNU projects". On the GNU
>      side, http://www.gnu.org/licenses/licenses.html states "we normally
>      use the GNU General Public License (GNU GPL), but occasionally we
>      use other free software licenses". "Normally" may or may not be
>      interpreted in this case as the only "recommended" license.
>
>    * If the argument is made that the GNU project's use of other free
>      software licenses includes the (linked-to) "GPL-compatible Free
>      Software Licenses"
>      (http://www.gnu.org/licenses/license-list.html#SoftwareLicenses),
>      then that list includes many non-copyleft permissive licenses; so
>      the desire to limit to a copyleft-only set of outbound licenses is
>      subverted.

The language "recommended by the Free Software Foundation for use in GNU 
projects" is something that (official? or inofficial?) representatives 
for FSF gave us as what they considered an appropriate counterpart to 
"approved by the Open Source Initiative". At the time we added it, what 
I understood (and I think others in the drafting group too) was that 
this would give us a definition of copyleft licenses. But, it later 
became clear that it's far more broad than just copyleft licenses. 
Still, since it was someone in some way affiliated with the FSF that 
requested the language in that very specific phrasing, I'd (personally) 
hesitate to rip it out unless we heard from the same source that the new 
version was fine. (I don't think the FSF itself will switch to a Harmony 
copyright assignment agreement, but other projects who consider 
themselves more closely aligned to FSF-philosophy than OSI-philosophy 
may use Harmony agreements, and we want to have an option that 
accommodates them. I have a fundamental question here whether the 
guarantee of copyleft is more important to that group, or the 
"recommendation" by the FSF. I suspect the strong value in copyleft is 
the more important of the two.)

In the review of the Beta drafts, two options came up. One is to change 
that phrase to "recommended by the Free Software Foundation for use
by projects using Project Harmony contribution agreements". 
Unfortunately, that change was made in our collaborative Etherpad doc 
after the group had already finished discussing the Outbound License 
section and moved on later in the document, and I don't know who made 
the edit so I can't ask about it. On the whole, the language is a little 
more specific, but it's also a little oddly circular ("you're using X, 
so we recommend doing Y, if you're using X"). And, it also runs into the 
problem that there is no clear definition of what the FSF would 
recommend for projects using Harmony, and no guarantee that they'd want 
to make or maintain that list.

The better option, from my perspective, is to just say "copyleft 
licenses". That leads to a short option, only 4 more words than Option One:

(Option Four) As a condition on the grant of rights in Sections 2.1 and 
2.2, We agree to license the Contribution only under the terms of the 
license or licenses which We are using on the Submission Date for the 
Material or any copyleft license (including any right to adopt any 
future version of a license if permitted).

This also wasn't discussed in the most recent meeting, but it's open as 
a possibility.

> If we can't provide a definitive list of copyleft-only licenses that
> meets the intention of 2.1(d) option 4, then we can fall back to 2.1(d)
> option 1: "We agree to license the Contribution only under the terms of
> the license or licenses which We are using". "We" is defined as the
> "fill in the blank" value at the start of the CLA, so presumably the
> project, organization, or company. Many projects that publish
> their code under a copyleft license include components of code from
> permissively-license projects, which leaves open a huge loophole for
> relicensing code under a permissive license.

The language is tighter than just "licences which We are using", it's 
"licenses which We are using on the Submission Date for the Material". 
That is, if an organization has multiple code bases, some GPL, some BSD, 
etc, but you contribute to one that's GPL, then the condition in Option 
One restricts the outbound license to the GPL. We took some steps to 
clarify this in the defintions in the Beta drafts, with:

"When this Agreement covers more than one software project, the Material 
means the work of authorship to which the Contribution was Submitted."

Meaning, a project can have multiple bodies of code each using different 
licenses, and you can sign one agreement for all of them, but when the 
agreement talks about the license of the "Material", it's the license of 
the specific body of code you contributed to.

> For example: original code for the primary project I contribute to is
> licensed under GPL v2, but we distribute tarballs that include a custom
> build of Dojo Toolkit which is itself licensed under the Modified BSD.
> One could therefore argue that our project is "using" both GPL v2 and
> the Modified BSD license, and by the current terms of 2.1(d) option 1 a
> contributor would have no assurance that their code would not be able to
> be relicensed by the project under the Modified BSD license.

In that case, the outbound license of the code you contributed to was 
GPLv2. It doesn't matter that the GPLv2 code is later distributed with 
code under another license, or that the project distributes both GPLv2 
and Modified BSD code. What matters is that you contributed to GPLv2 
code, and can expect your contribution to also be distributed as GPLv2.

> This problem with 2.1(d) option 1 is, of course, greatly magnified once
> you move beyond a single software project as "We/Us" to umbrella
> organizations and companies which almost certainly "use" permissive
> licensed code in one way or another.

Again, covered by making sure that it's talking about the license of the 
code that you contributed to, and not just any random license the 
organization or company happens to use.

> One way to satisfy the intent to provide a copyleft-only list of
> outbound licenses would be to replace 2.1(d) option 4 with an explicit list of
> strong copyleft licenses - which, from scanning the GNU list of
> licenses, would leave the GPL and AGPL as the only choices.

This is doable now using Option Two. Some projects might choose this 
even if Harmony did have a general option for copyleft licenses, if they 
wanted to be absolutely sure that it was only a specific set of copyleft 
licenses.


The question of how to describe the set of copyleft licenses is still 
under discussion. I'd like to find an elegant solution, all suggestions 
welcome (many brains make light work).

Allison