allison at lohutok.net
Wed Apr 27 22:37:44 UTC 2011
On 04/26/2011 03:16 PM, Scott James Remnant wrote:
>>From discussion about replacing the existing Canonical CLA with the
> Harmony one for Upstart:
> * the Harmony agreements are clearly written by a lawyer for a
> lawyer. But they're not intended to be given to lawyers, they are
> intended to be given to ordinary people who are expected to be
> able to understand them sufficiently to make a decision about
> their rights. Requiring every contributor to hire a lawyer is
> nonsensical and absolutely does not meet any "ease of
> contribution" requirements.
> * this is also true of the copyright license itself, be it GPL, BSD
> or Apache - but those have been around longer, are better
> understood and summarised and are necessary in of themselves.
> Adding a second legal document on top is not just doubling the
> problem, but understanding the interaction squares it ;-)
This is valuable feedback, and we've gotten similar feedback from
several sources now, so I'd say we're going to need to do another
language-simplification pass before the Beta drafts. (We've certainly
tried to make the agreements easy-to-read, but it seems to be something
we have to work at constantly, balancing between redrafting for legal
accuracy and redrafting for simplicity and clarity.)
Do a fresh pass over the Alpha drafts for simplicity and clarity.
Any pointers to specific sections that are particularly difficult to
understand will be very helpful. (Early in the process, I was a good
"naive reader", but I've spent far too much time combing through the
fine details of these agreements now.)
> * the right to sub-license the Contribution is granted from
> Contributor to Canonical, but no reciprocal right is granted for
> the Work as a whole back to the Contributor (ie. the right to
> sub-license is exclusive to Canonical)
It's true that these agreements don't create a joint ownership
arrangement. This is something the group discussed in great detail over
several calls. In general, joint ownership is considered a legally murky
area, especially on an international scale, and best avoided. (Even the
Linux kernel developers, some of the most vocal advocates of individual
ownership over aggregated ownership, have very carefully and
intentionally avoided categorizing their work as joint ownership.)
It's not an easy question, but to see a scenario where joint ownership
(or any grant of all rights in the entire work to all contributors) is
dangerous, consider a project with strong copyleft beliefs, call it Foo.
The license for Foo is GPL, and the developers want guarantees that the
project will only be released under the GPL. The Foo project adopts a
Harmony contributor agreement, with Option One "only under the current
license". This combination gives the developers the guarantees they want
that their code will always be released under a copyleft license, with
the copyleft set of freedoms and restrictions. Now, if the project also
granted all rights in the entire work to all contributors, that would
mean that any contributor (even if they only contributed one line) could
arbitrarily decide on their own to release the entire work under a BSD,
commercial, or proprietary license, completely undermining the copyleft
goals of the developers. Remember Jeff Merkey
(http://lwn.net/Articles/106353/). Copyright trolls aren't a new idea.
In an overview of current projects, the "best practice" where ownership
isn't aggregated, is for each developer to own their contributions, so
each developer has an "ownership" in the project (and a responsibility
to the project) that's proportional to the work they've done. This means
that each developer always has the right to do whatever they like with
their own contributions. Where a developer or group of developers have
contributed a substantial portion of the code in a project, they also
have substantial rights in the entire work, and substantial sway over
the direction and use of that copyright. If copyright infringement or
license enforcement legal action is ever needed, the largest copyright
owners in the work will be brought in as key players in the case. (This
is part of the responsibility of those individual owners to the whole
project.) It's highly likely that someone who has contributed thousands
of lines of code to a project is going to feel a much greater sense of
ownership in and responsibility to the project than someone who has
contributed a few lines, so it seems both socially fair and legally
sensible. The greatest power goes to those who are most entitled to the
power because they've invested the most, and to those who are most
likely to use the power wisely.
In Harmony, we carefully kept a tight parallel between the individual
ownership (copyright license) and aggregated ownership (copyright
assignment) versions of the agreements. In this case, that means that
even though the ownership is aggregated with the project, each
contributor still has the right to do whatever they like with their
contributions. A substantial contributor under assignment could release
their contributions under some other license, sell proprietary licenses,
or otherwise completely fly against the wishes of the other developers
in the project. But, the good or harm they can do toward the overall
project goals is limited exactly the same as in the copyright license
version of the agreement: their rights are proportional to the amount of
work they've contributed.
So, that's part of the answer, but only part. The five options are also
relevant to reciprocity. The first four are a restriction on the
outbound license, and the reciprocity is baked into that and the choice
of the outbound license. Projects that highly value broad, egalitarian
rights are likely to choose a permissive license such as the BSD, and
one of the options that permit such permissive licenses. Projects that
highly value the guarantees of copyleft licenses are likely to choose
copyleft licenses, and options that only permit copyleft licenses.
The fifth option is a different approach, it doesn't put any
restrictions on the outbound license, but offers a much stronger
guarantee of reciprocity. When a contribution is accepted into a work,
that contribution is guaranteed to be released under the current
license, which means the contributor (or anyone in the whole world) has
the right to fork the work+contributions under the current license.
There's been some discussion about whether the strong reciprocity in the
fifth option has been explained clearly enough. I'll make a note of that
here for Beta drafting.
Clarify the reciprocal nature of Option Five.
> * the patent rights associated with the Contribution are granted
> from Contributor to Canonical, but no reciprocal rights are
> granted for the Work as a whole back to the Contributor (ie.
> patent rights are exclusive to Canonical)
I'm not quite sure I understand this comment, so I'll write out my
thought process and see if we meet in the middle. If I'm not quite
there, please explain more of what you're thinking.
The case that's covered in the agreements is that a contributor (call
her Alex) holds patent A, writes code that uses patent A, and then
contributes that code to project Bar. Without a patent license from Alex
to Bar, Bar would then be infringing on Alex's patent, because Bar isn't
the patent holder. So, in the contributor agreement Alex grants a patent
license to Bar, because she wants Bar to be able to use and distribute
The scenario I think you're describing is that Bar holds a patent B,
Alex writes code that uses patent B, and then contributes that code to
project Bar. Without a patent license from Bar to Alex, Bar isn't
infringing on their own patent because they hold it, and Alex isn't
infringing on Bar's patent because the code is distributed by Bar. So,
no patent license needed for that "usual" case.
But, there is a way that Alex could infringe on Bar's patent, if she
took the code she wrote and used it in some other project. On the
copyright side that'd be fine, since she either owns the code (CLA
version) or has the right to do whatever she wants with the code (CAA
version). But, on the patent side, it would be an infringement.
It would be possible to grant a license to Alex to do whatever she wants
with her contribution, with a full patent license in B that she could
take to any codebase in the world. I'll tag a comment below, so we'll
talk about this in the Harmony group as we draft the Beta.
Discuss potential for patent license back to contributor.
Discuss potential for patent license back to contributor.
But personally, as far as I understand it, I'd say this is every bit as
dangerous as the joint ownership scenario above. It would leave projects
open to "submarine contributions", where someone tries to get seemingly
innocuous patches accepted so they can gain access to the project's
patents, or more likely to the patents of other contributors.
The contributor does get a patent license to the whole work, though, the
same patent license as all users through the outbound license. It varies
by choice of outbound license (and so is something that every project
needs to think through, whether they're using a Harmony agreement or
not), but FLOSS outbound licenses that address patents do so in a way
that grants a patent license sufficient to use, modify and redistribute
the work, but not sufficient to cover any arbitrary reuse of any
arbitrarily tiny contribution. That is to say, the outbound licenses
have been carefully thought through, and the patent licenses they
include are safe.
> * in addition, no patent rights are granted for the Work as a whole
> back to an ordinary User, combined with the GPLv2 this is a
> nuclear event should the rights pass to an evil holder
Patent rights for the ordinary user are handled by the outbound license.
We worked to make the Harmony patent license general enough that it
could be passed on by the project through any of the existing outbound
free and open source software licenses that address patents.
The Harmony agreements only cover the rights granted between the
contributor and the project. There are a number of outbound license
issues (rights granted to users) we could have brought into the
contributor agreements, and some existing contributor agreements do.
But, expanding the scope also increases the complexity of the documents
(which we wanted to avoid). And, the more we embed specific details of
the outbound license into the contributor agreements, the harder it is
to use the agreements with a wide variety of outbound licenses.
More information about the Harmony-Review