trove - LGPL v3 not recognised?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

trove - LGPL v3 not recognised?

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?

-Rob
_______________________________________________
Catalog-SIG mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/catalog-sig
Reply | Threaded
Open this post in threaded view
|

Re: trove - LGPL v3 not recognised?

"Martin v. Löwis"
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.

Regards,
Martin
_______________________________________________
Catalog-SIG mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/catalog-sig
Reply | Threaded
Open this post in threaded view
|

Re: trove - LGPL v3 not recognised?

Robert Collins
On Mon, Nov 14, 2011 at 10:25 AM, "Martin v. Löwis" <[hidden email]> 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

Cheers,
Rob
_______________________________________________
Catalog-SIG mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/catalog-sig
Reply | Threaded
Open this post in threaded view
|

Re: trove - LGPL v3 not recognised?

Toshio Kuratomi-2
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" <[hidden email]> 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

_______________________________________________
Catalog-SIG mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/catalog-sig

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: trove - LGPL v3 not recognised?

"Martin v. Löwis"
> 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).

What's the "common short form"? If it's the abbreviation (i.e. "GPL"),
they already have it, no?

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

Fine with me.

> But that doesnt mean that the current classifiers should go away.

Most certainly not. Once a classifier has been added, it can *never* go
away. That's why I ask people really think carefully whether they
really need a classifier, in exactly that spelling, before it's added.

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

I don't see that as a problem. Hopefully, the code itself gives enough
information. So if people can't know for sure, and if they need to know
(which they often don't), they need to check the source. The trove
classifier shouldn't be considered legally binding.

People like you (i.e. distribution packagers) can start going around and
ask authors to update their classifiers. Over time, all current packages
would use the correct classifiers.

Regards,
Martin
_______________________________________________
Catalog-SIG mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/catalog-sig
Reply | Threaded
Open this post in threaded view
|

Re: trove - LGPL v3 not recognised?

Toshio Kuratomi-2
On Mon, Nov 14, 2011 at 08:44:00AM +0100, "Martin v. Löwis" wrote:

> > 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).
>
> What's the "common short form"? If it's the abbreviation (i.e. "GPL"),
> they already have it, no?
>
I was referring to Robert Collins's proposed::

  License :: OSI Approved :: GNU Lesser General Public License v3

Instead, I proposed it include the short form like the current GPL licenses:

  License :: OSI Approved :: GNU Lesser General Public License v3 (LGPLv3)

> > But that doesnt mean that the current classifiers should go away.
>
> Most certainly not. Once a classifier has been added, it can *never* go
> away. That's why I ask people really think carefully whether they
> really need a classifier, in exactly that spelling, before it's added.
>
<nod>  Fully understood.  I wanted to be explicit about the pros and cons of
each strategy (and agree that keeping classifiers forever seems better).

-Toshio

_______________________________________________
Catalog-SIG mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/catalog-sig

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: trove - LGPL v3 not recognised?

Terry Reedy
In reply to this post by Toshio Kuratomi-2
On 11/13/2011 7:37 PM, Toshio Kuratomi wrote:

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

Is the classifier depth limited to 3, or can we do instead add optional
fourth level classifiers :: v2, :: v2 or later, :: v3, and :: v3 or
later to the current three level classifiers.
License :: OSI Approved :: GNU General Public License (GPL)
License :: OSI Approved :: GNU Library or Lesser General Public License
(LGPL)

I am presuming that one can now search for 'OSI Approved', in which case
this alternative would make it possible to search for GPL or LGPL
without the fourth specifier.

--
Terry Jan Reedy

_______________________________________________
Catalog-SIG mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/catalog-sig
Reply | Threaded
Open this post in threaded view
|

Re: trove - LGPL v3 not recognised?

Toshio Kuratomi-2
On Mon, Nov 14, 2011 at 08:06:12PM -0500, Terry Reedy wrote:

> On 11/13/2011 7:37 PM, Toshio Kuratomi wrote:
>
> >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+)
>
> Is the classifier depth limited to 3, or can we do instead add
> optional fourth level classifiers :: v2, :: v2 or later, :: v3, and
> :: v3 or later to the current three level classifiers.
> License :: OSI Approved :: GNU General Public License (GPL)
> License :: OSI Approved :: GNU Library or Lesser General Public
> License (LGPL)
>
> I am presuming that one can now search for 'OSI Approved', in which
> case this alternative would make it possible to search for GPL or
> LGPL without the fourth specifier.
>
I don't know about the technical possibility but I did consider proposing
something along those lines instead of expanding the third level.  The
reasons I didn't were:

1) The other licenses which have versions attached to them do not place the
   version into a fourth level
2) The utility of searching like that is limited.  If I'm searching for
   particular licenses, it's typically because I need to know whether the
   license is compatible with some other license.  The GPL v2 and versoin
   3 licenses are not compatible with each other.  GPLv2+ would be
   compatible with both.  GPLv3+, once again would not.

   With this in mind, it seemed like code which used the trove license
   categories would need to operate on each license+version independently,
   even if we grouped them that way in the categorization scheme.

-Toshio

_______________________________________________
Catalog-SIG mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/catalog-sig

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: trove - LGPL v3 not recognised?

"Martin v. Löwis"
In reply to this post by Terry Reedy
> Is the classifier depth limited to 3, or can we do instead add optional
> fourth level classifiers :: v2, :: v2 or later, :: v3, and :: v3 or
> later to the current three level classifiers.

The current implementation supports 5 levels, the longest classifiers
are like

 Topic :: System :: Networking :: Monitoring :: Hardware Watchdog
 Topic :: System :: Systems Administration :: Authentication/Directory
:: NIS
 Topic :: Multimedia :: Graphics :: Capture :: Digital Camera
 Topic :: Desktop Environment :: Window Managers :: Enlightenment :: Epplets
 Topic :: Desktop Environment :: Window Managers :: Sawfish :: Themes 0.30
 Topic :: Desktop Environment :: Window Managers :: Sawfish :: Themes
pre-0.30

So using versions as a sublevel would be entirely appropriate; the
top-level classifier is then understood as leaving the sublevel
"unspecified".

Regards,
Martin
_______________________________________________
Catalog-SIG mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/catalog-sig
Reply | Threaded
Open this post in threaded view
|

Re: trove - LGPL v3 not recognised?

"Martin v. Löwis"
In reply to this post by Toshio Kuratomi-2
> 1) The other licenses which have versions attached to them do not place the
>    version into a fourth level

That's probably because nobody thought of it.

> 2) The utility of searching like that is limited.

Why do you say that? You have full search capabilities either way. In
fact, sub-classifiers improve the search capabilities.

>    If I'm searching for
>    particular licenses, it's typically because I need to know whether the
>    license is compatible with some other license.

I'm not really sure what the common case for searching for a license is.
One reason might also be that people want to know what the most popular
licenses are, and would there want to aggregate GPL (any version).

But let's assume that people actually search for licenses to find
software that is compatible with their needs (whether that is their
license, their company policies, or their personal preferences).

>    The GPL v2 and versoin 3 licenses are not compatible with each other.

Then you search for either one by subclassifier (as you would for
a flat classification). However, there are also cases where the
license in question is compatible with both GPL versions, so you would
want to search for GPL "any version".

>    With this in mind, it seemed like code which used the trove license
>    categories would need to operate on each license+version independently,
>    even if we grouped them that way in the categorization scheme.

In the use cases you cited. I think there are also use cases where you
would want to entire supercategory.

Regards,
Martin
_______________________________________________
Catalog-SIG mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/catalog-sig
Reply | Threaded
Open this post in threaded view
|

Re: trove - LGPL v3 not recognised?

Toshio Kuratomi-2
On Tue, Nov 15, 2011 at 07:46:54AM +0100, "Martin v. Löwis" wrote:
> > 1) The other licenses which have versions attached to them do not place the
> >    version into a fourth level
>
> That's probably because nobody thought of it.
>
<nod>  But consistency in the classifiers is a nice thing.  If your goal as
a consumer of the data is really trying to isolate the version from the rest
of the license name, for instance, you already have to parse the version off
the end of some strings.  Making new classifiers that use another level for
a version means you have to maintain parsing of the version as a separate
field as an additional case.

Note that one of those other licenses is a GNU license:

License :: OSI Approved :: GNU Affero General Public License v3


> > 2) The utility of searching like that is limited.
>
> Why do you say that? You have full search capabilities either way. In
> fact, sub-classifiers improve the search capabilities.
>
I say this because in this case the different versions are simply ways of
naming different licenses.  The licenses have different terms and conditions
and in and of themselves are not even compatible.  The value of categorizing
the GPLv2 and GPLv3 license together is rather slim.  The value of
categorizing the MIT and new BSD licenses together would be higher than the
value of categorizing the GPLv2 and GPLv3 licenses together.  Wishing to
categorize the GPLv2 and GPLv3 together is only a superficial goal based on
the fact that they share the common substring "GNU General Public License"
in their name.

> >    If I'm searching for
> >    particular licenses, it's typically because I need to know whether the
> >    license is compatible with some other license.
>
> I'm not really sure what the common case for searching for a license is.
> One reason might also be that people want to know what the most popular
> licenses are, and would there want to aggregate GPL (any version).
>
Commonly people would not want to aggregate the GPL licenses here because
the GPL licenses are incompatible with each other and have different terms
and conditions.  If you want to know about popular licenses, you would want
to keep the GPLv2 and GPLv3 licenses separate in your count.  Or put another
way, if you are counting the GPLv2 and GPLv3 together, you likely aren't
really looking for a count of popular licenses.  You're likely looking for
a count of types of licenses.  These are some of the ways that people might
like to categorize licenses:

* Copyleft, non-copyleft, proprietary
* GPLv2-compatible, GPLv3-compatible, non-GPL compatible open source, proprietary
* Backed by a legal team, analyzed by a legal team, not rigorously analyzed

These are somewhat helped by having the version separated but they all have
issues as separating the version portion of the license name from the rest
is only an imperfect match for what you really want.  In the end, you have
to maintain lists of licenses that meet your categorizing criteria.  Having
the version as a separate field doesn't help as the textual portion of the
license name and the version portion have to be considered together to
determine which terms and condions need to be evaluated in your context.
The only thing that the raw name without version really brings to the table
is brand identification.

Here's a different example of this -- Let's say we were designing categories
for people who might want to classify software by which programming language
they were written in.  Would we want to group perl, python, and php together
because someone might want to search out popularity of languages according
to which begin with "p"?  Do we want to group Visual Basic and C#
together because both originated with Microsoft?  These groupings may fit
with what someone wants to accomplish but they're superficial groupings
based on things that have nothing to do with what the subject matter is
actually about.

Similarly, grouping the licenses based on the existence of a common
substring in the name is basing it on a superficial characteristic of the
license.  Instead, determine which attributes of the license are important
and you want to optimize for then optimize for that.


> But let's assume that people actually search for licenses to find
> software that is compatible with their needs (whether that is their
> license, their company policies, or their personal preferences).
>
> >    The GPL v2 and versoin 3 licenses are not compatible with each other.
>
> Then you search for either one by subclassifier (as you would for
> a flat classification). However, there are also cases where the
> license in question is compatible with both GPL versions, so you would
> want to search for GPL "any version".
>
This is lawyerly-debatable.  Since the GPLv2 and GPLv3 are incompatible and
since they are strong copylefts, the FSF's position has been that you cannot
license code in such a way that it can use both GPLv2  and GPLv3 licensed
code.  This has not been tested in court yet so lawyers continue to debate
the validity of this and the applicability in different situations (for
instance, is dynamic linkage different from shared?  Are scripting languages
different than compiled?) but anyone who doesn't want to risk having to go
to court over this needs to keep it in mind.

> >    With this in mind, it seemed like code which used the trove license
> >    categories would need to operate on each license+version independently,
> >    even if we grouped them that way in the categorization scheme.
>
> In the use cases you cited. I think there are also use cases where you
> would want to entire supercategory.
>
I could see *other* supercategories which could be of benefit but I don't see
that there is a case to be made for this particular separation.  A license's
version is a part of its name as the terms and conditions between versions
can change dramatically (and in the case of GPLv2 and GPLv3, LGPLv2
and LGPLv3; they did).

Here's some examples of other supercategories that could be considered:

::FSF :: GNU General Public License v3
:: Apache :: Apache Software License v2

This scheme would highlight the body that created a license.  Not all
licenses have a traceable or well known originator, though.  But for the
ones that do, this helps to answer the question of what legal team created
it or stands behind it/can explain the intent when it was drafed.

:: GNU Lesser General Public License v2 (LGPLv2) :: 2.0
:: GNU Lesser General Public License v2 (LGPLv2) :: 2.1
:: GNU Lesser General Public License v3 (LGPLv3) :: 3.0

This scheme would highlight when minor changes are made vs incompatible
changes.  This particular example is problematic, however, because the
particular change incorporated between v2.0 and v2.1 was a rename.  The 2.0
version is actually the GNU Library General Public License.  The concept is
problematic as deciding what's an incompatible change and what isn't is
debatable.  In the GPL context, version 2 and version 3 are incompatible
with each other so it's clear that they are different licenses.  On the
other hand, you have licenses like Old BSD (aka BSD with advertising) versus
the New BSD license.  The two are compatible with each other and the common
name for each is the same but externally, the new BSD license is compatible
with the GPL while the old one is not which is a major difference.

Talking about supercategories for licenses, though, points me in the
direction that really we're talking about wanting to add attributes to
describe the license itself, not attributes to describe the software.  That
seems out of scope for the trove categories being used on pypi.  (pypi
already sorta does this with the OSI Approved supercategory marking the
licenses as open source... but I'm wondering if that wasn't a mistake.
After all, the FSF maintains a similar list of licenses and the two lists
are not super/subsets of each other.) Limiting it to the license name (of
which the version is a part as the version + textual portion of the name
together reference the set of terms and conditions which make up the
license) might be better.

-Toshio

_______________________________________________
Catalog-SIG mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/catalog-sig

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: trove - LGPL v3 not recognised?

Robert Collins
These are the ones I would like to see:

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

Doing a 4th level would raise a bunch of interactions between legal
intent  - the above list seems like a good compromise. We've just had
a user turn up confused around this again, so - do we have sufficient
consensus to add these?

-Rob
_______________________________________________
Catalog-SIG mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/catalog-sig
Reply | Threaded
Open this post in threaded view
|

Re: trove - LGPL v3 not recognised?

Robert Collins
On Mon, Dec 12, 2011 at 6:41 AM, Robert Collins
<[hidden email]> wrote:

> These are the ones I would like to see:
>
>> >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+)
>
> Doing a 4th level would raise a bunch of interactions between legal
> intent  - the above list seems like a good compromise. We've just had
> a user turn up confused around this again, so - do we have sufficient
> consensus to add these?
>
> -Rob

Ping? I'm not sure how to check if these were added or not ?

-Rob
_______________________________________________
Catalog-SIG mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/catalog-sig
Reply | Threaded
Open this post in threaded view
|

Re: trove - LGPL v3 not recognised?

Richard Jones-32
On 30 January 2012 11:27, Robert Collins <[hidden email]> wrote:

> On Mon, Dec 12, 2011 at 6:41 AM, Robert Collins
> <[hidden email]> wrote:
>> These are the ones I would like to see:
>>
>>> >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+)
>>
>> Doing a 4th level would raise a bunch of interactions between legal
>> intent  - the above list seems like a good compromise. We've just had
>> a user turn up confused around this again, so - do we have sufficient
>> consensus to add these?
>>
>> -Rob
>
> Ping? I'm not sure how to check if these were added or not ?

The classifier list is available on PyPI via the "List trove
classifiers" sidebar link:
http://pypi.python.org/pypi?%3Aaction=list_classifiers

I've not been following the discussion closely so I'm not sure that a
consensus has been agreed upon (I'm guessing that the participants in
the November discussion went on vacation.)


     Richard
_______________________________________________
Catalog-SIG mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/catalog-sig