[License-review] Request for Approval of Universal Permissive License (UPL)

Tue Apr 15 09:05:35 UTC 2014

Carlo, thank you for making the important point about ad-personam attacks. I
will note though for the record that there are no innocents here. Google
itself has included patent-limited software in Android despite the
overarching Apache License that applies to that software. I personally like
that motivation, but other views may differ.

Much more important, though, is your following comment:

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.

Probably many lawyers here been approached by patent owners seeking to
license software under an open source copyright license while limiting the
scope of their patent licenses.  It is a difficult question. Motivation of
the licensor matters, of course, but not in the ad-personam way that it was
addressed earlier.

I am not aware of any specific provision of the OSD which *requires* a
patent owner to grant patent licenses  broader than for the specific
software work licensed by its copyright license, but many FOSS licenses
*add* the phrase "Derivative Works" or the more vague "Larger Works" to be
more generous than the OSD requires.

It would be helpful to me to hear your views about acceptable ways to limit
the scope of a patent license while the copyrighted software itself remains
free for open source.

/Larry

From: Carlo Piana [mailto:osi-review at piana.eu] 
Sent: 15 April 2014 17:09
To: license-review at opensource.org
Subject: Re: [License-review] Request for Approval of Universal Permissive
License (UPL)

Chris, all

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.

I concur with John Cowan here (who also replied to the same message).

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. 

Cheers

Carlo

On 15/04/2014 16:01, Chris DiBona wrote:

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?  

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.

Chris

On Apr 15, 2014 6:10 AM, "Jim Wright" <jim.wright at oracle.com
<mailto:jim.wright at oracle.com> > wrote:

Responses inline and thanks!

 Regards,
  Jim

On Apr 14, 2014, at 7:25 AM, Josh Berkus <josh at postgresql.org
<mailto:josh at postgresql.org> > wrote:

> Jim,
>
> I think you're now seeing why nobody has created a license like this
> before; it's a bit of a challenge.
>
>
>>> - What if a downstream fork modifies that file?
>>
>> A downstream fork cannot modify the file and expect this to be
>> legally effective any more than they could simply edit the license
>> text - the authors of the Software are making a grant of specific
>> scope, and a downstream recipient cannot expand that scope.
>
> You're assuming here that the downstream recipient has no patents of
> their own to grant usage to.  Let's give an example:
>
> 1. Oracle releases a new compression library under this license.  It
> includes several Java things in LARGER_WORKS.txt.
>
> 2. The Google Android team decide to include that compression library
> into Android OS.  At this point, they want to *add* Android to
> LARGER_WORKS, covering any compression patents which Google owns.
>
> So realistically, LARGER WORKS would need to be an append-only file to
> which each downstream contributor adds their own covered works, or
> possibly some kind of online registry. This provision is going to make
> the license significantly more complicated.

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

>
>>> - Can you give examples of what would go in such a file?
>>
>> Sure, the first example that I can think of would be Oracle Java,
>> where someone is developing a JSR reference implementation and this
>> therefore allows us to ship that code in either OpenJDK or the
>> proprietary licensed Java packages.  Another example from my own
>> world would be MySQL, which likewise has versions shipping under both
>> GPLv2 and proprietary licenses.
>
> Presumably this would only be a concern for patents which only covered
> UPL licensed technology plus larger work, and not either individually,
> yes?  Sadly, I can imagine several such.

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.

>
>>> - What if a downstream distributor fails to include the
>>> LARGER_WORKS.TXT file with the software?
>>>
>>
>> That's a good one.  This is just another form of the downstream
>> distributor choosing to sublicense the code on other terms (just like
>> they could under GPL or Apache or a proprietary license), and would
>> therefore mean the person receiving the Software would not get the
>> broader patent grant from the downstream distributor.  They also
>> might not know they could actually get a broader grant from the
>> original authors without looking, but it doesn't mean they wouldn't
>> benefit from the broader license, since the authors granted those
>> rights when they distributed the Software originally.
>
> That's a problem which would solve itself, I think.  What's a bigger
> issue is that popular libraries licensed under the UPL would accumulate
> multiple, conflicting LARGER_WORKS files.
>
> I do not agree with the other developers on this list that the UPL
> somehow violates the OSD.
>
> --Josh Berkus
>
> _______________________________________________
> License-review mailing list
> License-review at opensource.org <mailto:License-review at opensource.org> 
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-review

_______________________________________________
License-review mailing list
License-review at opensource.org <mailto:License-review at opensource.org> 
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-review

_______________________________________________
License-review mailing list
License-review at opensource.org <mailto:License-review at opensource.org> 
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-review

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20140415/ee5e386c/attachment.html>