[License-discuss] OSI and SPDX license list (license issues)

[Jilayne Lovejoy]

Hello OSI (and SPDX-legal)!

I've updated the SPDX License List (new version about to be released) as
per the various issues that were resolved previously in this thread and
have left the outstanding issues (we are down to three - yeah!) here, so
we can proceed.

Recap, with my additional comments proceeded by "JL-4/10/13:"
>
>>>1) 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.

JL-4/10/13: can anyone speak to this question regarding whether the "OSI
version" of the Artistic license is "used in the wild"?  I'll see what I
can find out on my end from our scanner at OpenLogic, but would be great
if others can weigh in as well.
>
>
>>>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.

JL-4/10/13: ok, that explains why it ended up this way and why/that the
libpng license was not OSI approved, but as in the thread, it still seems
the naming causes confusion.  What are the ramifications of changing the
name on the OSI site from zlib/libpng to just zlib?  (if this is a
audacious suggestion, just seems logical)
- if not, then I think we should adjust the SPDX list to be the same as
OSI (I.e. "zlib/libpng" and "libpng:)


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

JL-4/10/13: any further thoughts on how to resolve this one :)

Cheers,

Jilayne
>