Hi Allison, thanks for your reply<br><br><div class="gmail_quote">On Wed, Apr 27, 2011 at 3:37 PM, Allison Randal <span dir="ltr">&lt;<a href="mailto:allison@lohutok.net">allison@lohutok.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 04/26/2011 03:16 PM, Scott James Remnant wrote:</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Any pointers to specific sections that are particularly difficult to<br>
understand will be very helpful. (Early in the process, I was a good<br>
&quot;naive reader&quot;, but I&#39;ve spent far too much time combing through the<br>
fine details of these agreements now.)<br>
<br></blockquote><div>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.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
&gt;     * the right to sub-license the Contribution is granted from<br>
<div class="im">&gt;       Contributor to Canonical, but no reciprocal right is granted for<br>
&gt;       the Work as a whole back to the Contributor (ie. the right to<br>
&gt;       sub-license is exclusive to Canonical)<br>
<br>
</div>It&#39;s true that these agreements don&#39;t create a joint ownership<br>
arrangement. This is something the group discussed in great detail over<br>
several calls. In general, joint ownership is considered a legally murky<br>
area, especially on an international scale, and best avoided. (Even the<br>
Linux kernel developers, some of the most vocal advocates of individual<br>
ownership over aggregated ownership, have very carefully and<br>
intentionally avoided categorizing their work as joint ownership.)<br>
<br>
It&#39;s not an easy question, but to see a scenario where joint ownership<br>
(or any grant of all rights in the entire work to all contributors) is<br>
dangerous, consider a project with strong copyleft beliefs, call it Foo.<br>
The license for Foo is GPL, and the developers want guarantees that the<br>
project will only be released under the GPL. The Foo project adopts a<br>
Harmony contributor agreement, with Option One &quot;only under the current<br>
license&quot;. This combination gives the developers the guarantees they want<br>
that their code will always be released under a copyleft license, with<br>
the copyleft set of freedoms and restrictions. Now, if the project also<br>
granted all rights in the entire work to all contributors, that would<br>
mean that any contributor (even if they only contributed one line) could<br>
arbitrarily decide on their own to release the entire work under a BSD,<br>
commercial, or proprietary license, completely undermining the copyleft<br>
goals of the developers. Remember Jeff Merkey<br>
(<a href="http://lwn.net/Articles/106353/" target="_blank">http://lwn.net/Articles/106353/</a>). Copyright trolls aren&#39;t a new idea.<br>
<br></blockquote><div>The case being considered here is Upstart, with Canonical as the copyright holder asking for Option Five.</div><div><br></div><div>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 it.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">&gt;     * the patent rights associated with the Contribution are granted<br>
<div class="im">&gt;       from Contributor to Canonical, but no reciprocal rights are<br>
&gt;       granted for the Work as a whole back to the Contributor (ie.<br>
&gt;       patent rights are exclusive to Canonical)<br>
<br>
</div>I&#39;m not quite sure I understand this comment, so I&#39;ll write out my<br>
thought process and see if we meet in the middle. If I&#39;m not quite<br>
there, please explain more of what you&#39;re thinking.<br>
<br></blockquote><div>Note I was careful to distinguish Contribution and Work in the same manner as the agreement itself.</div><div><br></div><div>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 ;-)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The case that&#39;s covered in the agreements is that a contributor (call<br>
her Alex) holds patent A, writes code that uses patent A, and then<br>
contributes that code to project Bar. Without a patent license from Alex<br>
to Bar, Bar would then be infringing on Alex&#39;s patent, because Bar isn&#39;t<br>
the patent holder. So, in the contributor agreement Alex grants a patent<br>
license to Bar, because she wants Bar to be able to use and distribute<br>
the code.<br>
<br></blockquote><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The scenario I think you&#39;re describing is that Bar holds a patent B,<br>
Alex writes code that uses patent B, and then contributes that code to<br>
project Bar. Without a patent license from Bar to Alex, Bar isn&#39;t<br>
infringing on their own patent because they hold it, and Alex isn&#39;t<br>
infringing on Bar&#39;s patent because the code is distributed by Bar. So,<br>
no patent license needed for that &quot;usual&quot; case.<br>
<br></blockquote><div>Except when taken into account that Bar is owned by Canonical, and Canonical is acquired by Evil an (NP entity/patent troll).</div><div><br></div><div>Now all patents A or B are owned by Evil, and Alex doesn&#39;t have a patent license to continue development in the newly forked project to keep Bar open and free.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">But personally, as far as I understand it, I&#39;d say this is every bit as</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

dangerous as the joint ownership scenario above. It would leave projects<br>
open to &quot;submarine contributions&quot;, where someone tries to get seemingly<br>
innocuous patches accepted so they can gain access to the project&#39;s<br>
patents, or more likely to the patents of other contributors.<br>
<br></blockquote><div>The inverse leaves just as dangerous scenario - Evil using the harmony agreement to acquire patents by soliciting contributions.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
The contributor does get a patent license to the whole work, though, the<br>
same patent license as all users through the outbound license. It varies<br>
by choice of outbound license (and so is something that every project<br>
needs to think through, whether they&#39;re using a Harmony agreement or<br>
not), but FLOSS outbound licenses that address patents do so in a way<br>
that grants a patent license sufficient to use, modify and redistribute<br>
the work, but not sufficient to cover any arbitrary reuse of any<br>
arbitrarily tiny contribution. That is to say, the outbound licenses<br>
have been carefully thought through, and the patent licenses they<br>
include are safe.<br>
<br></blockquote><div>Upstart is GPLv2, there is no outbound patent license included in that copyright license.</div><div><br></div><div>An alternate option I proposed was changing the outbound license of Upstart, I understand that is being considered by Canonical.</div>
<div><br></div><div>Scott</div></div>