[Harmony-Review] Feedback

Scott James Remnant scott at netsplit.com
Wed Apr 27 23:21:38 UTC 2011

Hi Allison, thanks for your reply

On Wed, Apr 27, 2011 at 3:37 PM, Allison Randal <allison at lohutok.net> wrote:

> On 04/26/2011 03:16 PM, Scott James Remnant wrote:

> 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.)
> To be honest, I found the entire thing quite difficult to read. In
particular a continual need to keep referring from the text back to the
glossary at the top was just mind-bending.

> >     * 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.
> The case being considered here is Upstart, with Canonical as the copyright
holder asking for Option Five.

This leaves Upstart open to the problem of *Canonical* being acquired by an
entity without the best interests of the project in mind. And due to the
agreement, none of the other contributors being able to do anything about

> >     * 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.
> Note I was careful to distinguish Contribution and Work in the same manner
as the agreement itself.

I guess the confusion is a great example why the kinds of legal documents
that define terms in one place that they use elsewhere are confusing ;-)

> 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 code.
> Agreed.

> 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.
> Except when taken into account that Bar is owned by Canonical, and
Canonical is acquired by Evil an (NP entity/patent troll).

Now all patents A or B are owned by Evil, and Alex doesn't have a patent
license to continue development in the newly forked project to keep Bar open
and free.

> 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 inverse leaves just as dangerous scenario - Evil using the harmony
agreement to acquire patents by soliciting contributions.

> 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.
> Upstart is GPLv2, there is no outbound patent license included in that
copyright license.

An alternate option I proposed was changing the outbound license of Upstart,
I understand that is being considered by Canonical.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.harmonyagreements.org/pipermail/harmony-review/attachments/20110427/5752d9be/attachment-0001.html>

More information about the Harmony-Review mailing list