On Thu, Feb 14, 2013 at 10:40 AM, Karl Fogel <[email protected]> wrote: > Jilayne Lovejoy <[email protected]> writes: >>Martin - you read my mind, as I was just about to send an update of the >>outstanding OSI-SPDX License List issues. I'm copying Karl Fogel, John >>Cowan, as they are on the original string helping with these issues, as >>well as the "license-discuss" list for OSI. > > I'm following this, but just to be up front: I'm mostly doing other > stuff at OSI, now that Luis Villa chairs the license working group. > Luis is more qualified to handle these issues than I was anyway! Luis > is of course also volunteering his time, so this isn't meant as pressure > on him -- I just wanted to set expectations accurately about where > responses would come from.
Yes, I'm the guy on the hook, though for historical questions I'll probably end up asking Karl, Martin, and John :) >>1) Apple Public Source License 1.0 & Apple Public Source License 1.1 >> >>> Was this ever OSI approved? Note at top of fedora url says: This >>> license is non-free. At one point, it could be found at >>> http://www.opensource.apple.com/apsl/1.0.txt, but that link now >>> redirects to APSL 2.0. A copy of the license text has been taken >>> from archive.org's October 01, 2007 revision. >> >>> > The Archive shows that APSL 1.2 was approved. Wikipedia claims that >>> > APSL 1.0 was also approved, but gives no authority for this statement. >>> > That also matches my recollections (there was a considerable fuss at >>>the >>> > time, because it was OSI-approved but not FSF-free, the first of the >>>new >>> > licenses with that property). >> >>--> do I understand correctly that neither 1.0 nor 1.1 were OSI approved? >>A little confused by email comments/string, can someone from OSI clarify? The version released in 1999 (I assume 1.0 but can't verify) was approved by OSI, not without controversy: https://lwn.net/1999/0318/a/raymond.html Unfortunately, as best as I can tell our actual records don't go back to those older versions (something I'd like to fix) so I can't be specific. It is likely correct to say that 1.0 and 1.1 were approved. [If anyone on license-discuss has memories or archives that go back further, that'd be great.] >>2) Artistic License 1.0 >> >>Karl/John/OSI: >> > OSI approved, but only can find license on the "superseded licenses" >> > category list. >> > >> > Also note that Perl link has 10 clause version of license, whereas >> > OSI link has 9 clause with note at top about additional clause. for >> > searching/templating reasons, these should probably be listed as two >> > different licenses. Suggest naming as follows: >> > Artistic License 1.0 (Perl) // Artistic-Perl-1.0 >> > Artistic License 1.0 // Artistic-1.0 >> > >> > thoughts? >> >>Excellent idea, except maybe we should put the "(Perl)" before the >>version number, since "Perl" describes a flavor of the license and that >>flavor could conceivably happen to other versions, though we hope not. >>That would also match the proposed SPDX short name. Thus >> >> Artistic License (Perl) 1.0 // Artistic-Perl-1.0 >> Artistic License 1.0 // Artistic-1.0 >> >>Would that work for you? >> >>For now I've renamed http://opensource.org/licenses/artistic-license-1.0 >>to opensource.org/licenses/Artistic-1.0, edited it to link correctly to >>the superseding version (Artistic-2.0), and to link to a new page >>opensource.org/licenses/Artistic-Perl-1.0. >> >>Now, independently of the above, there is a serious bug in the Perl >>clause, and while I understand why it was OSI-approved, I think the OSI >>approved its *intended* meaning rather than its textual meaning. >> >>This should really be a separate thread, but I want to at least write it >>down here now, so there's a record of it somewhere: >> >>The OSI page above says: >> >> | Some versions of the artistic license contain the following clause: >> | >> | 8. Aggregation of this Package with a commercial distribution is >> | always permitted provided that the use of this Package is >> | embedded; that is, when no overt attempt is made to make this >> | Package's interfaces visible to the end user of the commercial >> | distribution. Such use shall not be construed as a distribution of >> | this Package. >> | >> | With or without this clause, the license is approved by OSI for >> | certifying software as OSI Certified Open Source. >> >>That's great, except s/commercial/proprietary/ :-(. What the text >>obviously means is "proprietary", and furthermore, if it were to be >>interpreted literally as "commercial", then it would (to my mind) be >>clearly not open source. >> >>I'm not sure what to do about this now. I just wanted to mention it. >>Any review of old licenses, such as you have done, is bound to turn up >>issues like this. Thank goodness it's an issue with Artistic-Perl-1.0 >>and not with, say, GPL-2.0 :-). >> >>JL/SPDX: >>in regards to adding a new license/version for Artistic License (Perl) 1.0 >> this is a good idea and your naming suggestions are inline with the >>naming protocol for SPDX, so that's all good. BUT one problemŠ the actual >>license on the Perl site (http://dev.perl.org/licenses/artistic.html ) is >>not the same as the one here >>(http://www.opensource.org/licenses/Artistic-Perl-1.0) --> the OSI perl >>version is simply the Artistic License 1.0 verbatim with the additional >>clause. However, the license on the Perl site has other differences. I'm >>attaching a Word document with a merge and compare between the OSI >>Artistic Perl and the Perl site Artistic Perl licenses >> >>--> anyone know what to do about this? I feel like the one on the Perl >>site should be captured, but what about the OSI variation? For the >>moment, I'm not adding the Artistic Perl license to the SPDX License List >>until this is sorted out, as I don't want to add one and then have to >>change it later. Hrm. Can we consult with someone (Daniel German?) to see if the OSI one is actually used "in the wild"? If it is, then that's a mess, but if it is not used in the wild, then we can simply switch the OSI one to match the official one. >>--> There also appears to be a "Clarified Artistic License" which is >>different yet again. That is on the SPDX license list already (and >>assumed to NOT be OSI approved) Correct. >>3) GNU Library General Public License v2 >> >>> > Was this ever OSI approved? >>> >>>I don't know. I suspect the answer to that one would not be so hard >>>to find, but I want to plough to the end of this spreadsheet right now >>>and get these responses posted. I did a cursory search on the OSI >>>site and didn't find any evidence of approval. Anyone here know about >>>LGPL-2.0? >> >>The differences between 2.0 and 2.1, other than the name (GNU Library >>vs. Lesser Public License) are entirely editorial. I can provide a list >>of them for anyone who wants it. >> >>--> so, is that a yes, it's OSI approved? Yes. [It may not have been formally approved at any point in the past, but if submitted, it would obviously be approved. I see no downside as marking it as such.] >>4) Zlip/libpng license >> >>OSI lists the "zlib/libpng" license as OSI approved here - >>http://www.opensource.org/licenses/Zlib this text is the same as the >>actual zlib license, see here: http://zlib.net/zlib_license.html. >> However, the libpng license, while incorporating some of the same text as >>the zlib license, has a different disclaimer and additional text, see >>here: http://www.libpng.org/pub/png/src/libpng-LICENSE.txt >>As a result, SPDX lists these licenses separately, that is: zlib License >>(OSI approved) http://spdx.org/licenses/Zlib and libpng License (not OSI >>approved) http://spdx.org/licenses/Libpng >>Yet, the libpng license text actually states that it is OSI approved. >> >>--> so, first question is: was the libpng license (separately or >>specifically) OSI approved? If so, can we list it separately? >> >>--> Either way, can we name the two licenses to avoid confusion? (see old >>string re: this naming issue here - >>http://old.nabble.com/FW%3A--png-mng-implement--zlib-libpng-license-name-td >>24275146.html) That thread also explains the history, which is good. It appears that the libpng license was changed *after* approval and never submitted to OSI. So I'd say that no, the "new" libpng license with UCITA clause is not OSI-approved. >> >>5) Jabber Open Source License v1.0 when going through the FSF list, we >>decided to add and in doing so noticed the archived text here >>(http://archive.jabber.org/core/JOSL.pdf) is not the same as the OSI has >>on their site (it was OSI approved). We decided because it's an old >>license to hold off and not add to list yet - and resolve with OSI (with >>goal of having on list b/c it was OSI approved and we endeavored to have >>all OSI licenses on SPDX list, even if old). license text also can be >>found at: http://code.google.com/p/jabber-net/wiki/FAQ_License >> >>--> what to do about this? Urgh. I'm really not sure; sending this email without resolution on this point so that the other issues can at least get dealt with. >>6) missing short identifiers on OSI website or in OSI urls - I have noted >>some where the url did not have the short identifier in the spreadsheet >>version of the SPDX-LL, Martin - I can help you with that, if it's not >>obvious. >> >>I'd love to start getting all of these resolved - OSI folks, please let me >>know what I can do to facilitate, help, etc.!! If someone can shoot me a list of where the discrepancies are, I can fix them. Luis _______________________________________________ License-discuss mailing list [email protected] http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
