[License-review] Request for Approval : Modular Open-source Software License (MOSL)

[Hadrien Grasland]

On 09/25/2012 07:02 PM, Bruce Perens wrote:
> On 09/25/2012 09:40 AM, Hadrien Grasland wrote:
>> Now, people could indeed decide to add additional license terms to 
>> request that one pays some kind of extra charge for the binary, but I 
>> did not and that's what matters as far as OSD compliance is 
>> concerned. Isn't it ?
> So, you're not looking for a GPL-like license at all in that case, but 
> an LGPL-like one. GPL very clearly requires free redistribution of the 
> entire program, including any additions that people might make to it. 
> LGPL allows derivative works that are not under the same terms.

Well, I'm not sure it's that. What I want to allow is for derivative 
works to be licensed under the same terms and some more.

>> Otherwise, I have to ask again : both the BSD and the MIT licenses 
>> permit one to charge for source code by adding extra terms. Should 
>> they be declared OSD-incompatible ?
> Assume that I give you source code under the BSD license. You can't 
> add terms to /my/ license without my permission. What you can do is 
> place your /own/ license on your derivative work. This might be a 
> modified copy of the BSD license, but it should not be called the BSD 
> license at that point. My license still applies to the pieces that I 
> own, without any additional terms at all.

That's what I have in mind, indeed. Sorry for using the wrong terminology.

> It's a bad idea to have something called the "Modular Open Source 
> License" that allows arbitrary additions to be added to it and is 
> still called the Modular Open Source License once those things are 
> added. Because, of course, it might not be Open Source any longer.

I agree that this can be a problem. In fact, the original draft actually 
featured a clause to avoid this outcome.

However, note that the name might be changing anyway, and here is why. 
It has been suggested on this mailing list that I base my license on the 
Sleepycat license, which I didn't know about and turns out to share 
similar goals. That would indeed be a more sensible choice : it's 
shorter, more to the point, and has probably already been thoroughly 
reviewed in the past unlike my naively home-made draft. But if I did 
build a derivative of that license, shouldn't I make this clear by 
changing the resulting license name to something matching like 
"Generalized Sleepycat License" ? Also, I am not sure if copyright law 
would allow me to do this without owning the rights to the original 
Sleepycat license, do you know if it is the case ?

> There's also the issue of license proliferation. Where the number of 
> OSI-approved licenses is N, the problem of understanding the 
> combination of any two licenses in the set requires the study of N * 
> N-1 combinations by lawyers. Developers aren't often equipped to do 
> this study on their own. We don't want you to have to hire a lawyer 
> just to develop Open Source (although that is in fact the case for 
> companies today). So, we tend to discourage the creation of new 
> licenses. A license that is literally built to be modified would thus 
> pose a bad effect for the community, by increasing the combinatorial 
> problem.

I think that you are misunderstanding me due to the bad wording of my 
post above. I would not exactly want to build a license that can be 
modified, rather I want to create a license that allows relicensing of 
derivative works under a superset of the original terms, just like BSD 
and MIT do, and unlike what the GPL (and the LGPL to a lesser degree) 
does. The superset would not be the same as the license, it would be a 
new license in its own right, and potentially not an OSD-compliant one. 
And I do not ask for OSI validation of the resulting supersets.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20120925/1a70f532/attachment.html>