Re: [License-discuss] Boilerplate license text for permissive licenses?
On Tue, 27 Nov 2012, Matthew Flaschen wrote: But I don't see how you can remove the placeholder from BSD 3-Clause while still having it be the same license. The original says, Neither the name of the University nor the names of its contributors You have to put something in place of University. It commonly has name of the author I also had the fun scripting to parse out the different licenses (and convert to a LaTeX format for 68 printed pages) for a product I sell. It has over 100 different BSD and MIT licenses and 26 advertising clauses This product includes software developed ... I just realized that I listed different cases (like author versus Author) as different licenses too, but I think that is only a few. ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] BSD, MIT [was Re: Draft of new OSI licenses landing page; please review.]
(responding to two different emails...) Even if the rest of Karl's proposal does not go through, and nothing else changes with the license list pages, I'd be perfectly happy moving BSD and MIT to the redundant or superseded lists. On Thu, 5 Apr 2012, Luis Villa wrote: But I think they should no longer be part of the category of licenses labeled if you were to start a new project from scratch, you should probably use one of these - which I think is what Karl is aiming at here, and what our current page may well be read to imply even if not changed. Superseded should not imply that the projects that actively use them have dropped them because they are inferior or replaced with a newer or different license. They may have been superseded by you, but generally they are not by the existing developers (copyright owners). Not speaking for my employer (who makes one of the most used softwares), but I do agree with their opinion on this ... when we started a new software project from scratch, we purposely chose to use a MIT/BSD style of license. And we make sure our dependencies match up with the same goals and simplicity. In addition, some significant software collections continue to require or highly suggest that new from scratch projects use the BSD/MIT style license (even if they are standalone and won't cause tainting of other code in the suite.) Also regarding superseded what features should be changed or added? Note that the even the Open Source Definition doesn't include many of the longer/newer license features. Changing topic some ... have there been any precedents related to the terms/conditions not included in the MIT/BSD style licenses? It would be interesting to provide references to case records / court opinions related to each criteria in the Open Source Definition and then expand on that for each point in some other licenses like Apache 2, GPL 2, GPL 3, etc. (Has anyone done this research?) ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] BSD, MIT [was Re: Draft of new OSI licenses landing page; please review.]
On Thu, 5 Apr 2012, John Cowan wrote:
Jeremy C. Reed scripsit:
Superseded should not imply that the projects that actively use them
have dropped them because they are inferior or replaced with a newer or
different license. They may have been superseded by you, but generally
they are not by the existing developers (copyright owners).
In all cases, the superseded licenses have been superseded by
later versions from the same source. They are the APSL 1.0, CPL 1.0,
Artistic 1.0, Eiffel Forum 1.0, Plan 9, MPL 1.0 and 1.1, OSL 1.0, and
the Reciprocal PL 1.0.
Likewise, the retired licenses have been abandoned by their stewards:
they are the Intel Open SL, the Jabber Open SL, the Mitre CVW, and
the SISSL.
None of these have a place on the main list$, and do not appear on Karl's
draft list either.
Okay.
I was responding to the earlier suggestion of moving BSD and MIT to the
redundant or superseded lists.
Using BSD generically can be confusing. Even the CSRG code under
copyright of The Regents of the University of California had at least
four different BSD licenses (1987, 1988, 1991, 1999). And then there are
the derivates of these. Some of these could be considered superseded
when a owner made changes (such as the advertising clause removal
specifically for the CSRG BSD code).
(I am authoring a detailed book about Western Electric, ATT, BSD
licensing... currently around 200 pages with over 75 interviews already
done left to integrate.)
Jeremy C. Reed
echo 'EhZ[h ^jjf0%%h[[Zc[Z_W$d[j%Xeeai%ZW[ced#]dk#f[d]k_d%' | \
tr'#-~''\-.-{'
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Greetings, Earthlings! Need quotes for article
On Mon, 19 Dec 2011, Robin 'Roblimo' Miller wrote: Tentative title: Are 69 Open Source Licenses Enough? 69 is way too few. In my little research of just around 600 man pages I found over 100 different licenses -- mostly due to slight wording changes. My questions: Do we really need that many open source licenses? No. Is there any way to consolidate some of them, which would make life simpler for a whole lot of people? Or does each one of these licenses serve an essential purpose for someone (or some company)? One way projects (like NetBSD) have consolidated licenses is to ask copyright owners if they can change their license text to standard boilerplate (or if they can re-assign the copyright and use a standard license). But there is no easy way for this. Changing old codes' licenses is difficult to near impossible due to difficulty to finding owners. Some copyright owners are stubborn and may respond negatively even on a polite request. In the case of significant license changes (such as MIT style changed to copyleft), I find it bad taste (and a little dishonest) if code contributors over the years shared patches because they knew the license was of a certain type of copyright. ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] a Free Island Public License?
This software is licensed for any purpose excepting the right to make publicly available derived works which depend exclusively upon non-free components. On Fri, 16 Dec 2011, Chad Perrin wrote: TL;DR Summary: My take would be that this satisfies the conditions of the Open Source Definition, though I may have overlooked something in my first reading. I think it conflicts with criterion #9. It appears to also satisfy the conditions of the FSF/GNU Four Freedoms I think it conflicts with the first freedom. and the Debian Free Software Guidelines, I think it conflicts with description of the first point. but fail to satisfy the conditions of the Copyfree Standard Definition. It appears to qualify as a copyleft license, but a somewhat atypical example of a copyleft license, in that its proliferation mechanism is not tied directly to proliferation of itself. ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] a Free Island Public License?
On Fri, 16 Dec 2011, Chad Perrin wrote: My take would be that this satisfies the conditions of the Open Source Definition, though I may have overlooked something in my first reading. I think it conflicts with criterion #9. I think that's true only to the extent that other copyleft licenses do, as well. If you have some differing insight, please share. I'd like to know what I missed. It appears to also satisfy the conditions of the FSF/GNU Four Freedoms I think it conflicts with the first freedom. I think that, too, is true only to the extent that other copyleft licenses do. Again, I'd like to know what prompts you to think otherwise. and the Debian Free Software Guidelines, I think it conflicts with description of the first point. See my above two responses to your disagreement with my estimation of the license's compliance with various standards. I'm curious about your points of disagreement. Two vague sentences from the license include: This software is licensed for any purpose excepting the right to make publicly available derived works which depend exclusively upon non-free components. In particular, the Derived Work fails this test if it depends upon proprietary software, remote services or hardware to provide features that do not have a corresponding Free Software implementation. I believe these could be understood to conflict with: - ``The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.'' While I know this is about distribution, it can be said that it is distributed with its dependencies. The license in question doesn't override others licenses, but if used it implies about its dependencies which I'd suggest could be distributed together. This argument is weak. - ``The freedom to run the program, for any purpose (freedom 0).'' How can it be used for any purpose if it can't depend on non-free software implementation? I this think is a strong argument. - ``The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale.'' This is about distribution collections. Maybe this one isn't a good enough argument but it similar to the point above. ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
