[License-review] Request for Approval of Universal Permissive License (UPL)
Carlo Piana
osi-review at piana.eu
Tue Apr 15 16:09:12 UTC 2014
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
> 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/b27423dd/attachment.html>
More information about the License-review
mailing list