[License-discuss] OSI and SPDX license list
luis at tieguy.org
Thu Feb 14 19:26:44 UTC 2013
On Thu, Feb 14, 2013 at 10:40 AM, Karl Fogel <kfogel at red-bean.com> wrote:
> Jilayne Lovejoy <jilayne.lovejoy at openlogic.com> 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
>>> > time, because it was OSI-approved but not FSF-free, the first of the
>>> > 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:
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
>> > 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
>>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 :-).
>>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)
>>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
>>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
>>As a result, SPDX lists these licenses separately, that is: zlib License
>>(OSI approved) http://spdx.org/licenses/Zlib and libpng License (not OSI
>>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 -
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
>>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
>>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.
More information about the License-discuss