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

Tue Apr 15 14:01:10 UTC 2014

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> wrote:

> Responses inline and thanks!
>
>  Regards,
>   Jim
>
> On Apr 14, 2014, at 7:25 AM, Josh Berkus <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
> > http://projects.opensource.org/cgi-bin/mailman/listinfo/license-review
>
> _______________________________________________
> License-review mailing list
> 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/32822d47/attachment.html>