<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Chris, all<br>
<br>
not my role to moderate the discussion, but I find it
uncharacteristic to carry a discussion in a public forum
concerning licenses only based on the attitude of the proponent.
While I myself have strong feelings about the action Oracle has
brought in the Java space, especially after having been told and
perjured oh so many times how their patents were held only for
defensive purposes and never to attack, this is IMHO not the right
place to discuss the motives or to bring an ad-personam argument
against a legal text which should be judged as is, not because of
(possibly not entirely unwarranted, speaking in corporate terms)
reservations on the proponent's intent in submitting or later
using the license.<br>
<br>
I concur with John Cowan here (who also replied to the same
message).<br>
<br>
Meanwhile, I have followed too superficially the long and winding
discussion on how the limitation of scope for the patent grant is
against the OSD to rule out that the objection is founded. I have
been reminded far too often of my misdeed by proposing the MXM
licence and how to exclude patents from the "IP grant" is very
likely against OSD. The same should apply, ceteris paribus, to any
limits the downstream reach of the patent grant. Scratching my
head here. <br>
<br>
Cheers<br>
<br>
Carlo<br>
<br>
<br>
<br>
On 15/04/2014 16:01, Chris DiBona wrote:<br>
</div>
<blockquote
cite="mid:CAEq5uwkfoXXrmQXGQbKWCAvv-+LWTFPYKFkNiupFwkYdzzd-iw@mail.gmail.com"
type="cite">
<p dir="ltr">Stab you? Seriously? How dare you use that kind of
violent imagery here when Oracle has sued half a dozen companies
for daring to use "open source" java. ylYou're pretending to be
all friendly now? </p>
<p dir="ltr">What a joke. Its clear to me that UPL can't be
trusted because oracle wrote it. I mean what chutzpah you have.
If OSI approves it we'll need to acknowledge that it has finally
and conclusively lost it's way in a time when it was honestly on
the ascent. OSI should not abandon its credibility and even
continue this conversation with what is no better than a
schoolyard bully.</p>
<p dir="ltr">Chris</p>
<div class="gmail_quote">On Apr 15, 2014 6:10 AM, "Jim Wright"
<<a moz-do-not-send="true"
href="mailto:jim.wright@oracle.com">jim.wright@oracle.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Responses inline and thanks!<br>
<br>
Regards,<br>
Jim<br>
<br>
On Apr 14, 2014, at 7:25 AM, Josh Berkus <<a
moz-do-not-send="true" href="mailto:josh@postgresql.org">josh@postgresql.org</a>>
wrote:<br>
<br>
> Jim,<br>
><br>
> I think you're now seeing why nobody has created a
license like this<br>
> before; it's a bit of a challenge.<br>
><br>
><br>
>>> - What if a downstream fork modifies that file?<br>
>><br>
>> A downstream fork cannot modify the file and expect
this to be<br>
>> legally effective any more than they could simply
edit the license<br>
>> text - the authors of the Software are making a grant
of specific<br>
>> scope, and a downstream recipient cannot expand that
scope.<br>
><br>
> You're assuming here that the downstream recipient has no
patents of<br>
> their own to grant usage to. Let's give an example:<br>
><br>
> 1. Oracle releases a new compression library under this
license. It<br>
> includes several Java things in LARGER_WORKS.txt.<br>
><br>
> 2. The Google Android team decide to include that
compression library<br>
> into Android OS. At this point, they want to *add*
Android to<br>
> LARGER_WORKS, covering any compression patents which
Google owns.<br>
><br>
> So realistically, LARGER WORKS would need to be an
append-only file to<br>
> which each downstream contributor adds their own covered
works, or<br>
> possibly some kind of online registry. This provision is
going to make<br>
> the license significantly more complicated.<br>
<br>
<br>
Well, Oracle does not need to license its own patents for use
in its own products, and neither does Google, so problem
solved! ;-) But I think I see what you're getting at, so
let's reverse it - let's say Chris suddenly decides he doesn't
want to stab me anymore and that he contributes to Oracle Java
under the UPL, let's call it Project X, and names Java in the
Larger Works file. And, no longer fearing for my life, I come
out of hiding and decide to add to that code and license my
patents for use in gmail. This could be accommodated in a
couple of ways that occur to me offhand, but the cleanest way
would be two separate licenses, one from Google covering
Project X plus Java, and one from Oracle covering Project X
plus gmail. In theory you also could just set it up with a
base Larger Works scope for all contributors plus any
additional scope from a particular contributor listed
elsewhere (yet another additional permission), so that no one
is purporting to change the scope<br>
of anyone else's grants, and this doesn't seem all that
complicated, but in any event, IMHO, folks are not really all
that likely to want to be changing the license scope for their
own contributions from that of the rest of the project all
that frequently, and trying to manage differently scoped
license grants for different contributors to the same project
was not a problem I was trying to solve for.<br>
<br>
<br>
><br>
>>> - Can you give examples of what would go in such
a file?<br>
>><br>
>> Sure, the first example that I can think of would be
Oracle Java,<br>
>> where someone is developing a JSR reference
implementation and this<br>
>> therefore allows us to ship that code in either
OpenJDK or the<br>
>> proprietary licensed Java packages. Another example
from my own<br>
>> world would be MySQL, which likewise has versions
shipping under both<br>
>> GPLv2 and proprietary licenses.<br>
><br>
> Presumably this would only be a concern for patents which
only covered<br>
> UPL licensed technology plus larger work, and not either
individually,<br>
> yes? Sadly, I can imagine several such.<br>
<br>
Yep. And as I said to Richard, I actually seriously hope
folks will adopt it in circumstances beyond that as well,
though it might or might not happen.<br>
<br>
><br>
>>> - What if a downstream distributor fails to
include the<br>
>>> LARGER_WORKS.TXT file with the software?<br>
>>><br>
>><br>
>> That's a good one. This is just another form of the
downstream<br>
>> distributor choosing to sublicense the code on other
terms (just like<br>
>> they could under GPL or Apache or a proprietary
license), and would<br>
>> therefore mean the person receiving the Software
would not get the<br>
>> broader patent grant from the downstream distributor.
They also<br>
>> might not know they could actually get a broader
grant from the<br>
>> original authors without looking, but it doesn't mean
they wouldn't<br>
>> benefit from the broader license, since the authors
granted those<br>
>> rights when they distributed the Software originally.<br>
><br>
> That's a problem which would solve itself, I think.
What's a bigger<br>
> issue is that popular libraries licensed under the UPL
would accumulate<br>
> multiple, conflicting LARGER_WORKS files.<br>
><br>
> I do not agree with the other developers on this list
that the UPL<br>
> somehow violates the OSD.<br>
><br>
> --Josh Berkus<br>
><br>
> _______________________________________________<br>
> License-review mailing list<br>
> <a moz-do-not-send="true"
href="mailto:License-review@opensource.org">License-review@opensource.org</a><br>
> <a moz-do-not-send="true"
href="http://projects.opensource.org/cgi-bin/mailman/listinfo/license-review"
target="_blank">http://projects.opensource.org/cgi-bin/mailman/listinfo/license-review</a><br>
<br>
_______________________________________________<br>
License-review mailing list<br>
<a moz-do-not-send="true"
href="mailto:License-review@opensource.org">License-review@opensource.org</a><br>
<a moz-do-not-send="true"
href="http://projects.opensource.org/cgi-bin/mailman/listinfo/license-review"
target="_blank">http://projects.opensource.org/cgi-bin/mailman/listinfo/license-review</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
License-review mailing list
<a class="moz-txt-link-abbreviated" href="mailto:License-review@opensource.org">License-review@opensource.org</a>
<a class="moz-txt-link-freetext" href="http://projects.opensource.org/cgi-bin/mailman/listinfo/license-review">http://projects.opensource.org/cgi-bin/mailman/listinfo/license-review</a>
</pre>
</blockquote>
<br>
</body>
</html>