[Catalog-sig] trove - LGPL v3 not recognised?

[Toshio Kuratomi]

On Mon, Nov 14, 2011 at 10:36:45AM +1300, Robert Collins wrote:
> On Mon, Nov 14, 2011 at 10:25 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> > Am 13.11.2011 22:06, schrieb Robert Collins:
> >> I tried to publish a package with
> >> License :: OSI Approved :: GNU lesser General Public License v3
> >>
> >> but its rejected - there is a Library or Lesser category, but no
> >> discrimination between v2 and v3 - as v3 is incompatible with v2, I
> >> figure users will want to know.
> >>
> >> Whats the 'right way' of handling this?
> >
> > You should request a new classifier here; I take your message that
> > you actually do request
> >
> > License :: OSI Approved :: GNU lesser General Public License v3
> >
> > I'll let this request sit for some time for people to object,
> > and then add this classifier. Remind me if I forget.
> 
> That would be great!. Uhm I made a typo - lower case l should be upper:
> License :: OSI Approved :: GNU Lesser General Public License v3

So actually, the GNU licensing classifiers could do with a bit of a thought.
We definitely could use more than we currently have.  How many and the
wording to use could use a bit of discussion:

The GNU licenses all have clauses similar to the following (This particular
wording is the one used in the GPLv2):

"""
Each version is given a distinguishing version number.  If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation.  If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
"""

This has lead to some very common scenarios by code authors and has also
lead to some scenarios that are most likely not what the author intended.

Common Scenarios
================
I would propose the following classifiers based on the common scenarios
I see everyday:

License :: OSI Approved :: GNU Lesser General Public License v2 (LGPLv2)
License :: OSI Approved :: GNU Lesser General Public License v3 (LGPLv3)
License :: OSI Approved :: GNU Lesser General Public License v2 or later (LGPLv2+)
License :: OSI Approved :: GNU Lesser General Public License v3 or later (LGPLv3+)
License :: OSI Approved :: GNU General Public License v2 (GPLv2)
License :: OSI Approved :: GNU General Public License v3 (GPLv3)
License :: OSI Approved :: GNU General Public License v2 or later (GPLv2+)
License :: OSI Approved :: GNU General Public License v3 or later (GPLv3+)

The version 2 and version 3 classifiers are for when the code specifies
a specific version.  The "or later" variants cover authors who choose to
give the users of their code the freedom to choose a later version of the
license published by the Free Software Foundation as quoted in the above
clause.

.. note::
    At the moment, people do publish code under the (L)GPLv3 or later but
    since there is no later version of the (L)GPL it doesn't have any
    immediate difference from the plain (L)GPLv3 but it could in the future.

    A GPLv1 but not LGPL did exist at one time but it is specifically used
    so infrequently (I have never seen software that seemed to intentionally
    use the GPLv1) that it only affects this analysis in the last section of
    this message.


Usually Unintended Licensing
============================
The last sentence in the license clause I quoted says "If the Program does
not specify a version number of this License, you may choose any version
ever published by the Free Software Foundation."   This is often something
that people who use (or redistribute) the code notice but an author does
not.  The author may put a copy of the GPLv2 in their software package and note
that their software is "Licensed under the terms of the GPL".  The author
assumes that using the GPLv2 (or GPLv3) text is sufficient to show that they
intend to use that version of the GPL.  Because the license specifically
states that in this case, the software is under any version of the GPL, the
software may actually be used under the terms of the GPLv1, v2, or v3 (at
this time).

How does this bear upon pypi?  If we expect that the author of a piece of
code is the one who maintains the pypi listing, then we probably do not need
to worry about it too much (unless one of the authors really intends "any
version of the GPL" rather than GPLv2 or later).  The author will see the
available classifiers and make a choice of which version of the license
they intend.

If we expect that people who are not upstream are making pypi listings on
behalf of upstream, then there's a case to be made for having classifiers
that represents "GNU General Public License, any version" and "GNU Lesser
General Public License, and version" as they should be adding classifiers
that reflect the actual license of the code.

This case could be covered with the current classifiers as they do not
specify any version but see below for the inadequacies of the current
classifier in this role.


Comparison to Current Classifier
================================
In pypi, we currently have the following license classifiers:
 
License :: OSI Approved :: GNU General Public License (GPL)
License :: OSI Approved :: GNU Library or Lesser General Public License (LGPL)

These are different than the originally proposed classifier above in two
ways -- lack of version specification and the use of the common short form.
Common short form is easy to add (as I did in my examples above).

The question of whether to add version specifiers to these classifiers is
more complex.  I think we should add the classifiers for (L)GPLv2 as well as
the ones for (L)GPLv3 as those are explicit expressions of the code's
licenses.  But that doesnt mean that the current classifiers should go away.

If they do go away, we'll need to change the classifiers that are currently
on packages to something else which will be wrong in some cases (unless we
read all.the code that these modules belong to to determine what the
classifier needs to be).

If they don't go away, module authors will be able to continue to upload new
modules with these classifiers.  This is undesirable because the
classification does not give enough information to consumers of the code to
tell if there will be license conflicts in their projects.  (example: If I'm
writing Apache licensed software, I need to know whether the module I'm thinking
of using is GPLv2 or GPLv3 as version 3 is compatible but version 2 is
not.  If I'm writing GPLv3 code I need to know if the code is licensed
GPLv2. GPLv2+, or GPLv3 as the two versions are incompatible with each
other).  This is no worse than the current case -- it would just be nice to
be able to deprecate the unversioned classifiers in some way.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20111113/59f7a296/attachment.pgp>