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

Gervase Markham gerv at mozilla.org
Mon Apr 14 10:19:18 UTC 2014


Hi Jim,

On 13/04/14 18:55, Jim Wright wrote:
> On Apr 11, 2014, at 6:02 AM, Gervase Markham <gerv at mozilla.org>
> wrote:
>> Did you consider forking the Apache license with an additional 
>> GPL-2-relicensing permissions grant clause?
> 
> Unfortunately this is much less clean - then you're distributing 3rd 
> party GPL code, which has different implications for everyone
> involved, and also the patent grant does not cover the entire work
> you're contributing to if it's not licensed under the Apache license,
> which in the case of proprietary code it usually isn't.

I don't quite understand your response. What do you mean by "then you're
distributing 3rd party GPL code"?

Say you release some software under the UPL. The point of the UPL is
that the code can be used anywhere (including in GPLed software). What
would be different, and worse, if you instead chose the Apache license?
Answer: no GPLv2-only compat. So what would be different, and worse, if
you instead chose the Apache license with specific GPLv2-only compat?

Surely, apart from the GPL-compat question, any objections to my
modified Apache idea would also be objections to straight Apache?


>> Does hereunder mean "written further down in this file", or "under
>> this license"?
> 
> Under this license.  (Apologies for legalese. :-)

Please do de-legalese that; I think it's confusing.

> It certainly doesn't stop anyone from dual licensing the doc under
> some other license, CC or otherwise, which may not be a bad idea for
> some applications, but yes, you're correct, the licensor is granting
> all the same rights in the included documentation that they are in
> the code, as we want to make sure that anyone using this as a
> contribution agreement gets the full set of rights in the entire
> contribution and doesn't have to try to sort out different licenses
> to specs or other doc, data, etc. that are included with the
> Software.

I see your point here; I agree that "code under license A; docs under
license B" is a problem if you then want to copy code into docs, or docs
into code.

>> Could you explain the rationale behind a specific list of larger
>> works? The admin of such a list sounds like a pain.
> 
> The idea here is that the original authors of the Software 

So, before you go on... it seems to me that in both this answer and
others in your thread, you have in mind a model of software where there
are Original Authors, and then everyone else. The Original Authors set
up how things are going to work, and everyone else runs with it.

Thing is, this way of thinking about software doesn't match the modern
world, where things are cut, excerpted, remixed, recombined, forked and
twisted into new shapes on a regular basis. If my codebase contains 500
lines of your project's code spread across 6 different files, plus 5000
lines of my code, plus 300 lines of someone else's... who are the
Original Authors of the work? If one of the contributing bits of
software has a LARGER_WORKS.TXT, does it carry over? What happens if two
contributing bits have different LARGER_WORKS.txt files? I can't just
make a unified file. But how can I keep them separate in any
understandable way, particularly if code from the two different projects
has ended up in the same files?

I understand that this is part of the additional permissions for
patents, and if the mechanism broke down, you'd be simply back to
something MIT-like. But the patent stuff is what this license has over
the MIT license, so it needs to work well in practice.

Gerv



More information about the License-review mailing list