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

Tue Apr 15 15:59:12 UTC 2014

LOL... Seriously?  I was totally kidding Chris, but based on both your original note and this response (and other context), it seems good humored discussion between us is not possible right now.  I hope that changes at some point.  But in the meantime, I'm not going have this turn into mailing list silliness by dignifying the accusations or characterizations with a substantive response, and please accept my apology to any extent your outrage/offense is genuine.

 Regards,
  Jim

On Apr 15, 2014, at 7:01 AM, Chris DiBona <cdibona at gmail.com> 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> 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
> _______________________________________________
> 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/817342bf/attachment.html>