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

Jim Wright jim.wright at oracle.com
Wed Sep 3 15:15:33 UTC 2014


Apologies all for delayed responses here, I'm traveling this week.  See inline below.

 Regards,
  Jim


> On Aug 29, 2014, at 2:12 AM, Henrik Ingo <henrik.ingo at avoinelama.fi> wrote:
> 
> Hi Jim
> 
> Now I don't remember exactly why I became so involved in this review
> in your last submission (maybe it was just a random moment I decided
> to devote time to OSI...) but given how many opinions I had back then,
> I now feel compelled to comment on this revision too.
> 
> 
>> On Mon, Aug 25, 2014 at 9:12 PM, Jim Wright <jim.wright at oracle.com> wrote:
>> This would be used
>> with a larger works file containing something like following: The Reference
>> Implementation of JSR-XXX Including Maintenance Releases as defined In the
>> Java Community Process Program.
>> 
>> There are three revisions to the license plus the larger works proposal
>> here:
>> 
>> - One, it removes the reference to future versions of the Software and
>> Larger Works from the base license text and pushes this, for the purpose of
>> the JCP, to the larger works file, and limits the scope of those future
>> versions in that larger works file to the final RI and Maintenance Releases.
>> I deemed this ok for use in various other contexts as well, as you can
>> recover all or some future versions of whatever you are seeking the license
>> for by referring to it in the larger works file where appropriate.
> 
> This change, and in particular the example sentence given above, has
> the effect of greatly limiting the scope of the patent grant compared
> to the previous revision. In particular it makes sense that should
> this piece of software one day no longer be part of, or a complete
> Java reference implementation, there is also no longer a justification
> for the author to have granted all of his patents to all of Java.
> 
> Related:
> 
> In the previous round of comments myself and some others pointed out
> that the way the larger works file is setup doesn't accommodate for
> workflows and code flows that are typical in the open source
> community, where code snippets may propagate and merge into completely
> different projects than those intended by the original author. (One
> example given was that if Joe Hacker contributes code to Java, but
> Google copies the same code into Android, then Oracle would benefit
> from the patent grant but Google would not.)
> 
> This concern has mostly not been addressed in your new revision, but I
> wanted to note that changing the scope of the patent grant actually
> does impact this in 2 ways:
> - since the patent grant is more limited, one could say that likewise
> is this concern. (E.g. Oracle and Google are still not equals, but the
> grant to Oracle is more limited in scope so the difference is
> smaller.)
> - If the "Larger work" is designated as "the reference implementation
> of JSR-XXX" rather than "Java as published by Oracle", then arguably
> if Google copies the whole RI into Android, it is still covered by the
> patent grant.
> 
> Would you agree with my reading here?
> 

Yes - the intent here is to permit the Larger Works file to flexibly specify different scopes like this, and if one were to specify the RI in this fashion, then it would be covered whatever platform it was running on.  That may be the right scope for the JCP, but the point here is flexibility - each project can choose an appropriate scope for their own community.



> 
>> - Two, it clarifies that arbitrary derivative works are not necessarily
>> licensed for additional patent claims that might be infringed by changes
>> (most folks did not interpret the license this way but because a couple
>> asked about it, we clarified).
> 
> This refers to:
> 
> "...sold, copy, create derivative works of (provided that this does
> not license additional patent claims beyond those covering the
> unmodified Software and Larger Works), display, perform, distribute,
> and sublicense the Software and the Larger Work(s) on either these or
> other terms."
> 
> I appreciate that the text in parenthesis was added as a
> clarification, however I'm afraid the current text can be read in the
> other extreme instead: In practice it would often forbid creation of
> any derivative works, since any non-trivial modification is more than
> likely to infringe on somebody's patent, or at least that somebody
> could easily claim that it does. For example, say that IBM is the
> original author of some code to which I add some functionality, it's
> clearly quite possible that my new functionality infringes on IBM's
> vast patent portfolio. The above text could then be read as saying
> that I'm not allowed to create a derivative work at all - not just
> that the original patent grant doesn't extend to the derivative work.
> 
> I'm sorry as I'm neither a lawyer or native English speaker, I will
> not attempt to come up with a better sentence, but I hope you
> understand what I'm criticising here.
> 
> henrik
> 

Mr. Cowan's response is the right one here - this is not a proscription on creating a derivative work, it simply limits the scope of the patent license to the Software and the designated Larger Works.  I don't think many would read this as barring other derivative works, as such a construction would also bar them under other permissive licenses like BSD and Apache.   The feedback I got from the community here is that patent holders will not agree to a scope which licenses all their patents for any arbitrary modification, and in fact would be nervous about a license which could possibly be interpreted this way, thus the clarification - of course, you still *could* apply the license this way by simply stating that all derivative works are covered (and thanks in advance if you do ;-), which would be even broader than I intended the original draft.  



> 
> 
> 
> -- 
> henrik.ingo at avoinelama.fi
> +358-40-5697354        skype: henrik.ingo            irc: hingo
> www.openlife.cc
> 
> My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7



More information about the License-review mailing list