Re: [License-discuss] A simple, no-requirements license.
On Thu, Apr 24, 2014 at 10:06 AM, Gervase Markham wrote: > On 23/04/14 16:59, Buck Golemon wrote: > > and another > > package's license says "modified versions cannot contain additional > > attribution requirements." > > I don't know of any licenses which say that. Can you point me at an > example? > I cannot. I don't have broad knowledge of license terms. My question is: Is it possible to have an MIT-like license with no requirements on derivative works? (I'm referring to this clause: "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.") While I don't know whether the MIT requirements cause issues with any OSI or other popular license, it's factual that there is a demand for an absolutely-permissive open-source license, and until there is an OSI-vetted solution, people will continue to use or invent other solutions (think of: sqlite, cc0, unlicense, wtfpl). The wtfpl, the unlicense and other public domain attributions are crayon licenses, while the cc0 is too complex and not OSI-approved besides, so I come here asking for help in making a simple yet legally sound license which fills this demand. I'm trying to follow up on the suggested course of action in these posts: * http://projects.opensource.org/pipermail/license-review/2012-February/000243.html * http://projects.opensource.org/pipermail/license-review/2012-January/47.html ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] A simple, no-requirements license.
On 23/04/14 16:59, Buck Golemon wrote: > and another > package's license says "modified versions cannot contain additional > attribution requirements." I don't know of any licenses which say that. Can you point me at an example? Gerv ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] A simple, no-requirements license.
MIT requires preservation of copyright and license, which falls directly into the scenario outlined on Wikipedia: http://en.wikipedia.org/wiki/License_compatibility Suppose a software package has a license that says, "*modified versions > must *[preserve license and copyright notice]" and another package's > license says "modified versions cannot contain additional attribution > requirements." Without direct permission from the copyright holder(s) for at > least one of the two packages, it would be impossible to legally > distribute a combination of the two because these specific license > requirements cannot be simultaneously fulfilled. Thus, these two packages > would be license-incompatible. I suppose the goal could be restated as: a license similar in spirit to MIT, but without the copyright and license requirements. On Apr 23, 2014 5:41 AM, "Ben Tilly" wrote: > Why don't you feel that http://opensource.org/licenses/MIT meets this > need? > > On Tue, Apr 22, 2014 at 11:54 AM, Buck Golemon > wrote: > > Apologies for the previous message. > > I fat-fingered the send button before finishing my revision. > > > > --- > > There's a gap that CC0 and the Unlicense have attempted to fill, which is > > still not covered by any OSI approved license. > > Are any of you willing (and able) to attempt to fill this gap? > > > > I believe the first step would be to agree on a (short!) list of minimum > > requirements. > > > > My own requirements: > > > > 1) The license should be understandable by myself and my fellow > engineers. > >* This requires brevity. > > 2) The license should have the absolute minimum of compatibility issues > with > > other OSI licenses. > >* The licensee would ideally have no requirements placed on them by > the > > license. > > 3) Assure both the licensee and licensor against litigation by the other > (to > > the extent possible, of course). > > > > It's entirely possible that 2) and 3) cannot both be accomplished by a > > single license, but that's what I'm here to find out. > > > > > > > > I'm trying to follow up on the suggested course of action in these posts: > > * > > > http://projects.opensource.org/pipermail/license-review/2012-February/000243.html > > * > > > http://projects.opensource.org/pipermail/license-review/2012-January/47.html > > > > ___ > > License-discuss mailing list > > License-discuss@opensource.org > > http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss > > > ___ > License-discuss mailing list > License-discuss@opensource.org > http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss > ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] A simple, no-requirements license.
Why don't you feel that http://opensource.org/licenses/MIT meets this need? On Tue, Apr 22, 2014 at 11:54 AM, Buck Golemon wrote: > Apologies for the previous message. > I fat-fingered the send button before finishing my revision. > > --- > There's a gap that CC0 and the Unlicense have attempted to fill, which is > still not covered by any OSI approved license. > Are any of you willing (and able) to attempt to fill this gap? > > I believe the first step would be to agree on a (short!) list of minimum > requirements. > > My own requirements: > > 1) The license should be understandable by myself and my fellow engineers. >* This requires brevity. > 2) The license should have the absolute minimum of compatibility issues with > other OSI licenses. >* The licensee would ideally have no requirements placed on them by the > license. > 3) Assure both the licensee and licensor against litigation by the other (to > the extent possible, of course). > > It's entirely possible that 2) and 3) cannot both be accomplished by a > single license, but that's what I'm here to find out. > > > > I'm trying to follow up on the suggested course of action in these posts: > * > http://projects.opensource.org/pipermail/license-review/2012-February/000243.html > * > http://projects.opensource.org/pipermail/license-review/2012-January/47.html > > ___ > License-discuss mailing list > License-discuss@opensource.org > http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss > ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] A simple, no-requirements license.
Apologies for the previous message. I fat-fingered the send button before finishing my revision. --- There's a gap that CC0 and the Unlicense have attempted to fill, which is still not covered by any OSI approved license. Are any of you willing (and able) to attempt to fill this gap? I believe the first step would be to agree on a (short!) list of minimum requirements. My own requirements: 1) The license should be understandable by myself and my fellow engineers. * This requires brevity. 2) The license should have the absolute minimum of compatibility issues with other OSI licenses. * The licensee would ideally have no requirements placed on them by the license. 3) Assure both the licensee and licensor against litigation by the other (to the extent possible, of course). It's entirely possible that 2) and 3) cannot both be accomplished by a single license, but that's what I'm here to find out. I'm trying to follow up on the suggested course of action in these posts: * http://projects.opensource.org/pipermail/license-review/2012-February/000243.html * http://projects.opensource.org/pipermail/license-review/2012-January/47.html ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
[License-discuss] A simple, no-requirements license.
There's a gap that CC0 and the Unlicense have attempted to fill, which is still not covered by any OSI approved license. Are any of you willing (and able) to attempt to fill this gap? I believe the first step would be to agree on a (short!) list of minimum requirements. My own requirements: 1) The license should be understandable by myself and my fellow engineers. * This requires brevity. * The license should have the absolute minimum of compatibility issues with other OSI licenses. * * The licensee would ideally have no requirements placed on them by the license. * Assure both the licensee and licencor against litigation by the other (to the extent possible, of course). I'm trying to follow up on the suggested course of action in these posts: * http://projects.opensource.org/pipermail/license-review/2012-February/000243.html * http://projects.opensource.org/pipermail/license-review/2012-January/47.html ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
