[License-discuss] OSI and SPDX license list

[Luis Villa]

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
>>>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