[License-discuss] OSI and SPDX license list
Karl Fogel
kfogel at red-bean.com
Thu Feb 14 18:40:26 UTC 2013
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.
Where I can help clarify any of the issues (for example, in my responses
quoted below) I'll be happy to do so of course.
Best,
-K
>Complete list (combining yours and mine) of outstanding issues as follows,
>with past commentary and questions indicated with"-->"
>
>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?
>
>
>
>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.
>--> 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
>>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?
>
>
>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)
>
>
>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?
>
>
>5) adding missing OSI-approved licenses to SPDX License List: he MITRE
>Collaborative Virtual Workspace License (CVW License) and Reciprocal
>Public License, version 1.1
>
>--> yes, we should add those; will bring it up on call this morning (in a
>few minutes...)
>
>
>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.!!
>
>Cheers,
>
>Jilayne
>
>
>
>On 2/14/13 10:00 AM, "Martin Michlmayr" <tbm at hp.com> wrote:
>
>>I just went through the list of OSI Superseded and Retired Licenses at
>>http://opensource.org/licenses/do-not-use
>>and updated them to use SPDX identifiers.
>>
>>I noticed that a few OSI approved (but superseded/retired) licenses
>>are not on the SPDX list:
>>
>> - Jabber Open Source License
>> http://opensource.org/licenses/jabberpl
>> I saw that there has been some discussion on this and needs action
>>from OSI:
>> http://lists.spdx.org/pipermail/spdx-legal/2012-November/000713.html
>> I'll try to find out more in OSI's archives.
>>
>> - The MITRE Collaborative Virtual Workspace License (CVW License)
>> http://opensource.org/licenses/mitrepl
>>
>> - Reciprocal Public License, version 1.1
>> http://opensource.org/licenses/rpl1.1
>> You have version 1.5 but not 1.1.
>>
>>Can you consider the last two for inclusion in the SPDX list? Once
>>you assign an SPDX identifier, I can update the OSI page.
>>
>>All licenses on the OSI site (except those mentioned above) should use
>>SPDX identifiers in their URLs now as well as in the title. If you
>>notice any where the SPDX identifier is missing, let me know and I'll
>>fix it.
>>
>>I'm aware that the SPDX list contains some OSI-approved licenses that
>>are not on the OSI web site (e.g. AFL-1.x, AFL-2.x, OSL-2.0). I'll
>>work on resolving that next.
>>
>>--
>>Martin Michlmayr
>>Open Source Program Office, Hewlett-Packard
>>_______________________________________________
>>Spdx-legal mailing list
>>Spdx-legal at lists.spdx.org
>>https://lists.spdx.org/mailman/listinfo/spdx-legal
>>
More information about the License-discuss
mailing list