Request for checking GPL compatibility

[Suraj N. Kurapati]

Hello,

Below is the result of my attempt to distill the SleepyCat license
into the the MIT license template (everything is same as the MIT
license except the conditions paragraph in the middle).

This license satisfies my ethical needs (attribution + share-alike)
and seems to be easily understood by my peers. It also appears to
satisfy the OSD, DFSG, the three tests (desert island, dissident,
and tentacles of evil) outlined in the DFSG-FAQ, and GPL compatibility.

However, I am not very confident about the GPL compatibility, so I
humbly request your assistance in verifying its satisfaction.

Thanks for your consideration.

------------------8<------------------------>8---------------------

Copyright (c) <year> <copyright holders>

Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation files
(the "Software"), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify, merge,
publish, distribute, sublicense, and/or sell copies of the Software,
and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:

All copies and substantial portions of the Software (the "Subsets")
and their corresponding source code (the "Code") must include the
above copyright notice and this permission notice.  The Subsets must
be distributed with the Code or with information on how to obtain
the Code.  The Code must reflect all modifications made to the
Subsets and must be available for no more than the cost of
distribution plus a nominal fee.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

------------------8<------------------------>8---------------------

[Matthew Flaschen]

Suraj N. Kurapati wrote:
> Hello,
>
> Below is the result of my attempt to distill the SleepyCat license
> into the the MIT license template (everything is same as the MIT
> license except the conditions paragraph in the middle).

Why do you want to do this?  You could achieve much the same purpose
with the GPL itself or of course the original Sleepycat.  Making a new
(apparently equivalent) license doesn't really make things easier.  It
means there's just one more license to read over.

> This license satisfies my ethical needs (attribution + share-alike)
> and seems to be easily understood by my peers. It also appears to
> satisfy the OSD, DFSG, the three tests (desert island, dissident,
> and tentacles of evil) outlined in the DFSG-FAQ, and GPL compatibility.
>
> However, I am not very confident about the GPL compatibility, so I
> humbly request your assistance in verifying its satisfaction.

I agree that it's OSD-compliant.  IANAL, but it's probably
GPL-compatible, since I see no relevant differences between it and the
original Sleepycat, which is
(http://www.gnu.org/licenses/license-list.html#SoftwareLicenses).
You're better off asking the FSF at licensing@...

Matthew Flaschen

[Wilson, Andrew-2]

 
Matthew Flaschen wrote:

>Suraj N. Kurapati wrote:
>> Hello,
>>
>> Below is the result of my attempt to distill the SleepyCat license
>> into the the MIT license template (everything is same as the MIT
>> license except the conditions paragraph in the middle).
>
>Why do you want to do this?  You could achieve much the same purpose
>with the GPL itself or of course the original Sleepycat.  Making a new
>(apparently equivalent) license doesn't really make things easier.  It
>means there's just one more license to read over.

Echoing Matthew, exactly what is the motivation for your license?
Please consider the unwritten, but still becoming more
commonly accepted, 'OSD #11' which discourages new open
source licenses which are duplicative of existing licenses.
In your case, please clarify why Sleepycat, or LGPL (since
it does not appear you want source code obligations to
spread by linking) would not suffice.

Your license is admirably concise, though.  ;-)

Andy Wilson
Intel Open Source Technology Center

[Suraj N. Kurapati]

Wilson, Andrew wrote:

>  
> Matthew Flaschen wrote:
>
>> Suraj N. Kurapati wrote:
>>> Below is the result of my attempt to distill the SleepyCat license
>>> into the the MIT license template (everything is same as the MIT
>>> license except the conditions paragraph in the middle).
>>
>> Why do you want to do this?  You could achieve much the same purpose
>> with the GPL itself or of course the original Sleepycat.  Making a new
>> (apparently equivalent) license doesn't really make things easier.  It
>> means there's just one more license to read over.
>
> Echoing Matthew, exactly what is the motivation for your license?

Sorry, here is my motivation:

I had been using the GPL for some years without fully understanding
its implications. Recently, I spent some time thinking about my
ethical beliefs regarding free software and discovered that I prefer
something like Creative Commons' by-sa (attribution + share-alike)
license.

Since CC does not recommend using their licenses for software, my
friend suggested the Sleepycat license. However, I found the
Sleepycat's copyleft condition (the third condition) to be:

1. too strong: I just want to free my source code; I don't want to
impose this condition on the user's own source code.

2. shaky: "must be freely redistributable under reasonable
conditions" -- what constitutes as "reasonable"? I fear that things
might get so bad that, ultimately, a Judge will have to answer this
question in court.

I looked at other by-sa licenses (particularly MPL, CDDL, CPL, EPL)
but found them to be lengthy and having much legalese. In contrast,
I admire the MIT license for its short length and clarity, so I
wished to make Sleepycat + MIT hybrid license.

> Please consider the unwritten, but still becoming more
> commonly accepted, 'OSD #11' which discourages new open
> source licenses which are duplicative of existing licenses.

I don't want to fuel license proliferation, but I don't seem to have
very much choice -- my particular ethical beliefs are very unpopular
in terms of the available OSS licenses.

Nevertheless, my software is insignificant, so I don't expect this
license to have any meaningful effect on license proliferation.

> In your case, please clarify why Sleepycat, or LGPL (since
> it does not appear you want source code obligations to
> spread by linking) would not suffice.

Please see above for my reluctance towards the Sleepycat license.

I feel the LGPL is too restrictive because LGPL code can only be
incorporated into LGPL or GPL code. Instead, I want my code to be
incorporable into any other code as long as my terms are satisfied.

> Your license is admirably concise, though.  ;-)

Wonderful! I spent a whole week trying to simplifying it. :)


Thanks for your consideration.

[Suraj N. Kurapati]

Matthew Flaschen wrote:
> I agree that it's OSD-compliant.

Thanks for reviewing my license.

> IANAL, but it's probably GPL-compatible, since I see no relevant
> differences between it and the original Sleepycat, which is
> (http://www.gnu.org/licenses/license-list.html#SoftwareLicenses).
>
> You're better off asking the FSF at licensing@...

Ah, thanks for the tip.  Will do.

[Matthew Flaschen]

Suraj N. Kurapati wrote:
> I had been using the GPL for some years without fully understanding
> its implications.

I encourage you to research the license and reconsider using it.  The
FSF has a comprehensive FAQ at http://www.gnu.org/licenses/gpl-faq.html.

 Recently, I spent some time thinking about my
> ethical beliefs regarding free software and discovered that I prefer
> something like Creative Commons' by-sa (attribution + share-alike)
> license.

Of course, that is similar to the GPL, except the GPL provides better
for software by dealing with source code availability and other issues.

> Since CC does not recommend using their licenses for software

No, in fact they recommend the GPL and LGPL
(http://creativecommons.org/software/) for this.

> 1. too strong: I just want to free my source code; I don't want to
> impose this condition on the user's own source code.

As Andrew stated, this is the purpose of the LGPL.

> I looked at other by-sa licenses (particularly MPL, CDDL, CPL, EPL)
> but found them to be lengthy and having much legalese.

There's a reason for this legalese.  All of these are still far shorter
than proprietary software EULAs people agree to every day.  Many
contracts are still longer.

> I don't want to fuel license proliferation, but I don't seem to have
> very much choice -- my particular ethical beliefs are very unpopular
> in terms of the available OSS licenses.

That's really not true.  I believe LGPL or an MPL-style license could
serve you very well.  And unfortunately, everyone believes they have a
compelling reason for a new license, but OSI needs to say no sometimes.

> Nevertheless, my software is insignificant, so I don't expect this
> license to have any meaningful effect on license proliferation.

It is undesirable to have rarely used licenses, since they clutter the
license list and cause confusion.

> I feel the LGPL is too restrictive because LGPL code can only be
> incorporated into LGPL or GPL code.

That is incorrect.  It can be linked into any program (even proprietary
ones), as long as the program's license allows private modification
(however, source need not be provided) and reverse engineering for
debugging those modifications.  Please read LGPL section 6
(http://www.gnu.org/licenses/lgpl.html).

Matthew Flaschen

[John Cowan]

Matthew Flaschen scripsit:

> [The LGPL] can be linked into any program (even proprietary
> ones), as long as the program's license allows private modification
> (however, source need not be provided) and reverse engineering for
> debugging those modifications.  Please read LGPL section 6
> (http://www.gnu.org/licenses/lgpl.html).

IMAO, the LGPL is the most incomprehensible widely used FLOSS license
(the *most* incomprehensible FLOSS license being the Reciprocal Public
License).  And while the matter is not subject to proof, I believe
that most creators of proprietary software either avoid LGPLed code
because the license is so complicated, or else simply ignore the
requirements for private modification and reverse engineering.
IOW, the folk theorem about the LGPL is "Just like the GPL, except
you can use it in proprietary stuff too."

(I urged ESR, before he went to speak with Netscape, to have them
avoid the LGPL precisely because it was hard to understand: this
remark may have been partly responsible for the MPL and its
descendant licenses.)

--
John Cowan  cowan@...  http://ccil.org/~cowan
If I have seen farther than others, it is because I was standing on
the shoulders of giants.
        --Isaac Newton

[Matthew Flaschen]

John Cowan wrote:

> Matthew Flaschen scripsit:
>
>> [The LGPL] can be linked into any program (even proprietary
>> ones), as long as the program's license allows private modification
>> (however, source need not be provided) and reverse engineering for
>> debugging those modifications.  Please read LGPL section 6
>> (http://www.gnu.org/licenses/lgpl.html).
>
> IMAO, the LGPL is the most incomprehensible widely used FLOSS license
> (the *most* incomprehensible FLOSS license being the Reciprocal Public
> License).

Perhaps, but I believe it serves a necessary purpose.  The MPL's
file-by-file test is certainly simple, but essentially makes the
copyleft worthless (#include anyone?).  The LGPL attempts to preserve it
where possible.

  And while the matter is not subject to proof, I believe
> that most creators of proprietary software either avoid LGPLed code
> because the license is so complicated, or else simply ignore the
> requirements for private modification and reverse engineering.

It's really not that complicated.  People probably do violate the
private modification and reverse engineering requirements, but they only
take one sentence in the proprietary license to do right.  The hard part
is figuring out the difference between modifying the library and using
it in a new application; there's no easy solution here.

> IOW, the folk theorem about the LGPL is "Just like the GPL, except
> you can use it in proprietary stuff too."

That is true to an unfortunate extent.  Education is the answer.

Matthew Flaschen

[Suraj N. Kurapati]

Matthew Flaschen wrote:
> Suraj N. Kurapati wrote:
>> 1. too strong: I just want to free my source code; I don't want
>> to impose this condition on the user's own source code.
>
> As Andrew stated, this is the purpose of the LGPL.

Please allow me to explain:

The existing copyleft licenses require derived (copy/paste/modify)
works to be licensed under (usually) themselves upon distribution.
For example, MPL begets MPL, GPL begets GPL, and LGPL begets either
LGPL or GPL.

This becomes an obstacle for developers using permissive licenses,
like MIT or BSD, who want to copy/paste/modify some copyleft source
code into their own source code -- because doing so would require
their code to be licensed under the copyleft license upon
distribution. As a result, such developers tend to avoid
incorporating copylefted source code.

I want to avoid this obstacle because, for me, as long as my code is
kept free (i.e. upon distribution, source code is available and
modifications are not kept secret) then I am happy. I neither mind
nor wish to impose the incorporator's choice of license.

For this reason, I do not feel that the LGPL suits my needs.

> And unfortunately, everyone believes they have a compelling
> reason for a new license, but OSI needs to say no sometimes.
>
> It is undesirable to have rarely used licenses, since they
> clutter the license list and cause confusion.

I agree and have accordingly refrained from submitting my license to
the OSI for approval because there do not seem to be enough
developers wanting the same things in a license as I do.

>> I feel the LGPL is too restrictive because LGPL code can only
>> be incorporated into LGPL or GPL code.
>
> That is incorrect.  It can be linked into any program (even
> proprietary ones), as long as the program's license allows
> private modification (however, source need not be provided) and
> reverse engineering for debugging those modifications.

You are correct, but I was thinking in terms of
copying/pasting/modifying code rather than calling API functions or
linking to a library.

So, what I meant to say is that: when you copy/paste/modify some
LGPL code into your own code, your own code is pulled under either
LGPL or GPL upon distribution. This is the restrictiveness I was
referring to.

In contrast, if you copy/paste/modify some MIT licensed code into
your own code, your own code is not forced to become licensed under
MIT upon distribution (but you must still adhere to the MIT license
for the parts you copied). This is a feature I want in a license.


Thanks for your consideration.

[Matthew Flaschen]

Suraj N. Kurapati wrote:
> I want to avoid this obstacle because, for me, as long as my code is
> kept free (i.e. upon distribution, source code is available and
> modifications are not kept secret) then I am happy. I neither mind
> nor wish to impose the incorporator's choice of license.

IANAL, but I don't think this license (Sleepycat + MIT) allows
incorporation of your code into software with simple permissive licenses
(e.g. BSD).  To do so, you would need to allow your code to be
distributed under the BSD license. The BSD license /does/ allow
modifications to be kept secret.

> I agree and have accordingly refrained from submitting my license to
> the OSI for approval because there do not seem to be enough
> developers wanting the same things in a license as I do.

Okay, I would also urge you to use an OSI-approved license, but that's
ultimately your decision.

> In contrast, if you copy/paste/modify some MIT licensed code into
> your own code, your own code is not forced to become licensed under
> MIT upon distribution (but you must still adhere to the MIT license
> for the parts you copied). This is a feature I want in a license.

It's true that you are not specifying that the work that is pasted into
be licensed under Sleepycat/MIT.  However, it is still not compatible
with BSD (or MIT/Xorg/etc.) because it requires source availability.

Matthew Flaschen

[John Cowan]

Matthew Flaschen scripsit:

> IANAL, but I don't think this license (Sleepycat + MIT) allows
> incorporation of your code into software with simple permissive licenses
> (e.g. BSD).  To do so, you would need to allow your code to be
> distributed under the BSD license. The BSD license /does/ allow
> modifications to be kept secret.

Sleepycat + MIT is self-contradictory anyway, because MIT allows
sublicensing: you can strip off the Sleepycat language whenever
you want.

--
A: "Spiro conjectures Ex-Lax."                  John Cowan
Q: "What does Pat Nixon frost her cakes with?"  cowan@...
  --"Jeopardy" for generative semanticists      http://www.ccil.org/~cowan

[Suraj N. Kurapati]

John Cowan wrote:

> Matthew Flaschen scripsit:
>
>> IANAL, but I don't think this license (Sleepycat + MIT) allows
>> incorporation of your code into software with simple permissive licenses
>> (e.g. BSD).  To do so, you would need to allow your code to be
>> distributed under the BSD license. The BSD license /does/ allow
>> modifications to be kept secret.
>
> Sleepycat + MIT is self-contradictory anyway, because MIT allows
> sublicensing: you can strip off the Sleepycat language whenever
> you want.

IANAL but I don't think this is possible because (1) the conditions
paragraph of the MIT license is self-preserving and (2) I put the
Sleepycat language within that conditions paragraph.

One cannot gain the ability to sublicense unless one satisfies the
conditions paragraph of the MIT license, correct?  If not, I could
simply take some MIT licensed code, remove the license's conditions
paragraph, and redistribute it as I please.

[Suraj N. Kurapati]

Matthew Flaschen wrote:
> IANAL, but I don't think this license (Sleepycat + MIT) allows
> incorporation of your code into software with simple permissive licenses
> (e.g. BSD).  To do so, you would need to allow your code to be
> distributed under the BSD license. The BSD license /does/ allow
> modifications to be kept secret.

Alright, but why is it not possible to satisfy both licenses?

If I incorporated some code under my license (A) into some BSD code
(B), then A is governed by my license and B remains governed by the
BSD license, correct?

Can't you just provide the source code taken/modified from my
license along with the BSD/MIT distribution to satisfy both licenses?

>> In contrast, if you copy/paste/modify some MIT licensed code into
>> your own code, your own code is not forced to become licensed under
>> MIT upon distribution (but you must still adhere to the MIT license
>> for the parts you copied). This is a feature I want in a license.
>
> It's true that you are not specifying that the work that is pasted into
> be licensed under Sleepycat/MIT.  However, it is still not compatible
> with BSD (or MIT/Xorg/etc.) because it requires source availability.

True, they are philosophically incompatible. However, in practice, I
think they would play quite nicely together:

By incorporating code under my license, an MIT or BSD developer is
not surrendering his entire project to my license -- he just has to
do some extra work for the portions of his project that are based
from my code. That "extra work" is simply to make the source code
(only for the portions under my license) available upon distribution.

Since most OSS projects make source code available anyways, they
would not have any problem incorporating code under my license --
unless, of course, they strongly believe in their license's philosophy.

[Matthew Flaschen]

Suraj N. Kurapati wrote:
> Matthew Flaschen wrote:
>> IANAL, but I don't think this license (Sleepycat + MIT) allows
>> incorporation of your code into software with simple permissive licenses
>> (e.g. BSD).  To do so, you would need to allow your code to be
>> distributed under the BSD license. The BSD license /does/ allow
>> modifications to be kept secret.
>
> Alright, but why is it not possible to satisfy both licenses?

First IANAL, but I'm fairly confident the below's correct: When code is
distributed under the BSD license, that always allows private
modifications.  If you say your code can be distributed under BSD (which
you're not doing here), then you're saying people can make proprietary
versions of it.

> Can't you just provide the source code taken/modified from my
> license along with the BSD/MIT distribution to satisfy both licenses?

If I put a work under BSD (regardless of what else it's under) I'm
giving people the right to make a proprietary version of the entire
work.  That's what the license says, and that's what it means.  Whether
I personally provide source is irrelevant if I tell others they don't
have to.  That means Sleepycat/MIT (which requires source code stay
available) can never be compatible with BSD.

> True, they are philosophically incompatible.

They are also legally incompatible.  I don't have the right to include
Sleepycat/MIT code in a BSD work.  If I did so, I would be telling
people they could make it proprietary.  I'm not the copyright holder, so
I can't give them that additional right.

> By incorporating code under my license, an MIT or BSD developer is
> not surrendering his entire project to my license

By doing that, he would be putting *your* Sleepycat/MIT code under BSD
(unless he chose to relicense the combination under Sleepycat).
Sleepycat/MIT doesn't allow that, so he would be breaking the law.

> That "extra work" is simply to make the source code
> (only for the portions under my license) available upon distribution.

Even if he did so, he would be giving others (through the BSD license)
permission not to provide source.

I'm not going to speculate any more about philosophical
incompatibilities.  The current SleepyCat/MIT license is not at all
compatible with BSD.  If you make a new license you think /is/, post it
then.

Matthew Flaschen

[Suraj N. Kurapati]

Hello,

I learned more about this topic on the debian-legal mailing list:

  This is the main thread for the topic:
  http://lists.debian.org/debian-legal/2007/04/msg00087.html

  See this message and both of its follow-ups:
  http://lists.debian.org/debian-legal/2007/04/msg00100.html

I am answering below based on what I learned there.


Matthew Flaschen wrote:
> I don't have the right to include Sleepycat/MIT code in a BSD
> work.  If I did so, I would be telling people they could make it
> proprietary.  I'm not the copyright holder, so I can't give them
> that additional right.

No.  After you copy&paste some Sleepycat/MIT code into a file
containing purely BSD code, the result is that:

1. You now have two disjoint portions of code: the copied&pasted
portion is governed by the Sleepycat/MIT license, whereas the
remainder is governed by the BSD license.


2. The entire file is now governed by both licenses.

In particular, when acting upon the entire file, you must obey (1)
the intersection of permissions granted by both licenses and (2) the
sum of restrictions placed by both licenses.

Here, the intersection of permissions is equivalent to the
permissions granted by the MIT license or the 2-clause BSD license.


3. When acting upon a single portion of the file, you need only obey
the portion's associated license.

For example, when you act upon the copied&pasted portion, you must
follow the Sleepycat/MIT license -- the BSD license does not apply
to this portion.

Likewise, when you act upon the non copied&pasted portion, you must
follow the BSD license -- the Sleepycat/MIT license does not apply
to this portion.

>> By incorporating code under my license, an MIT or BSD developer
>> is not surrendering his entire project to my license
>
> By doing that, he would be putting *your* Sleepycat/MIT code
> under BSD (unless he chose to relicense the combination under
> Sleepycat). Sleepycat/MIT doesn't allow that, so he would be
> breaking the law.

No.  After incorporation, the Sleepycat/MIT code remains governed by
Sleepycat/MIT; the BSD code remains governed by BSD.

Another reason why the Sleepycat/MIT code does not become pulled
under the BSD upon incorporation is that, as you said, he cannot
relicense my code because he is not the copyright holder.

>> That "extra work" is simply to make the source code (only for
>> the portions under my license) available upon distribution.
>
> Even if he did so, he would be giving others (through the BSD
> license) permission not to provide source.

No.  The copied&pasted Sleepycat/MIT code is only governed by the
Sleepycat/MIT license -- the BSD license does not apply to it.


Thanks for your consideration.

[Matthew Flaschen]

Suraj N. Kurapati wrote:
>>> That "extra work" is simply to make the source code (only for
>>> the portions under my license) available upon distribution.
>> Even if he did so, he would be giving others (through the BSD
>> license) permission not to provide source.
>
> No.  The copied&pasted Sleepycat/MIT code is only governed by the
> Sleepycat/MIT license -- the BSD license does not apply to it.

Okay, that makes sense.  What would be a mistake would be to say BSD
alone applied to the whole combined file (yet source still had to be
provided).  Before, I thought that was what you intended.

Thanks for clearing things up.

Matt Flaschen