no support for licence with "or (at your option) any later version"

[carandraug]

GPL licences often come with the "or (at your option) any later version" clause. For example, GPL-2 and GPL-2+ are two different licenses, and so are GPL-3 and GPL-3+. Would be nice if this would be handled since it is confusing for packagers to see GPL_3 (which infers GPL version 3 only) on the metadata files while the licence on the individual files claims to be GPL 3+.

[xtaran]

I was just about to open the very same bug report against Software::License as I have exactly this issue explaining to Dist::Zilla that my project is GPL_3+, not just GPL_3. (And in META.json and friends, it ended up as even only gpl.)

[Leont]

Essentially, that's nothing more than creating your own subclass that has the appropriate text. I don't think this requires anything from Software::License's core.

It is a bit annoying though that our metafiles can't express this, but that's a problem for another ticket (and I'm afraid not something we can fix easily). Legally that's not the part that matters though AFAIK, so I guess that's acceptable.

[carandraug]

Essentially, that's nothing more than creating your own subclass that has the appropriate text. I don't think this requires anything from Software::License's core.

That is true for all the Software::Licence::*. My point is that GPL with "any later version" is very common and would make sense to support it in core. I would say that it's even more common than GPL locked to a specific version but I only have anecdotal evidence.

[xtaran]

Hi,

On Tue, Jan 31, 2017 at 05:47:08PM -0800, Carnë Draug wrote: > Essentially, that's nothing more than creating your own subclass > that has the appropriate text. I don't think this requires > anything from Software::License's core. […] My point is that GPL with "any later version" is very common and would make sense to support it in core. I would say that it's even more common than GPL locked to a specific version

Exactly.

but I only have anecdotal evidence.

It's actually the _default_ when you follow the FSF's guidelines: https://www.gnu.org/licenses/gpl-howto.html Only few projects, like e.g. the Linux kernel, choose to drop the "any later version" phrase and stick to an explicit version of the GPL. (Dito for LPGL, AGPL, etc. btw.) So please add this notion to Software::License core as at least GPL_1+, GPL_2+ and GPL_3+. Thanks in advance! Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe@deuxchevaux.org (Mail) X See http://www.nonhtmlmail.org/campaign.html | abe@noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ (Web)

[carandraug]

It's actually the default when you follow the FSF's guidelines: https://www.gnu.org/licenses/gpl-howto.html

Only few projects, like e.g. the Linux kernel, choose to drop the "any later version" phrase and stick to an explicit version of the GPL. (Dito for LPGL, AGPL, etc. btw.)

I certainly have been using GPL_3 when I meant GPL-3+ and only caught on to this because Debian asked me to clarify the licence. So should those classes have the "any later version" there by default and a new GPL_N_only, etc classes be added instead?

[Leont]

My point is that GPL with "any later version" is very common and would make sense to support it in core.

There are two different things here:

1. Writing these subclasses.
2. Merging them into S::L itself, as opposed to separate CPAN distributions.

Given how thinly stretched the maintainers of this dist are, they're unlikely to do number 1 for you anytime soon. But if you can make step 2 as little work as pressing "accept merge request", your odds are remarkably higher.

I would say that it's even more common than GPL locked to a specific version but I only have anecdotal evidence.

On CPAN neither is particularly common, but that's only because Perl-license (Artistic | GPL1+) is the norm.

[carandraug]

There are two different things here:

• Writing these subclasses.
• Merging them into S::L itself, as opposed to separate CPAN distributions.

Given how thinly stretched the maintainers of this dist are, they're unlikely to do number 1 for you anytime soon. But if you can make step 2 as little work as pressing "accept merge request", your odds are remarkably higher.

I have no problem doing 1. I just want to make sure that 2 can happen too so I can do this right. So can I make the GPL licences (and LPGL, AGPL, etc. as mentioned above) have the "at your option" clause by default? And add new classes with "_only" on the name?

[Leont]

So can I make the GPL licences (and LPGL, AGPL, etc. as mentioned above) have the "at your option" clause by default? And add new classes with "_only" on the name?

I think such a change of the existing classes would require a broader discussion, including existing authors using the {A,L,}GPL subclasses

[xtaran]

Hi,

On Wed, Feb 01, 2017 at 12:33:26PM -0800, Leon Timmermans wrote: > So can I make the GPL licences (and LPGL, AGPL, etc. as mentioned > above) have the "at your option" clause by default? And add new > classes with "_only" on the name? I think such a change of the existing classes would require a broader discussion, including [existing authors using the {,A,L}GPL subclasses](http://grep.cpan.me/?q=license%5Cs*%3D%5Cs*.%3FGPL+file%3Adist%5C.ini)

I agree with Leon that we should stay backwards compatible. If possible just adding a plus sign to the current identifiers would be nice. If that's not possible because the identifier needs to be able to be a Perl Module name, I suggest appending the string "_or_later". Kind regards, Axel

[Leont]

I agree with Leon that we should stay backwards compatible.

I think that's the only realistic option at this stage.

If possible just adding a plus sign to the current identifiers would be nice. If that's not possible because the identifier needs to be able to be a Perl Module name, I suggest appending the string "_or_later".

It has to be a valid class name…

[dod38fr]

An alternative solution is to create a Software::License class using new_from_short_name from Software::LicenseUtils class.

Debian version of Software::License has been patched to accept GPL-3+ as a valid version.

This set of patches also enable all Software::License::L?GPL.* classes to accept a or_later parameter to handle the or_later clause. This is used by cme with dpkg model to provide the correct license text when dealing with L?GPL-\d\+ clause in dpkg/copyright files.

All the best

[xtaran]

Hi Dominique,

On Wed, Feb 01, 2017 at 10:55:39PM -0800, Dominique Dumont wrote: An alternative solution is to create a `Software::License` class using `new_from_short_name` from `Software::LicenseUtils` class.

This doesn't seem to suffice for dzil's usage of Software::License:

Debian version of `Software::License` has been patched (https://anonscm.debian.org/cgit/pkg-perl/packages/libsoftware-license-perl.git/tree/debian/patches) to accept `GPL-3+` as a valid version.

If I use "GPL-3+" as license in a dist.ini on Debian Unstable, dzil bails out as follows: `Software::License::GPL-3+' is not a module name

This set of patches also enable all `Software::License::L?GPL.*` classes to accept a `or_later` parameter to handle the or_later clause.

Neither does "license = GPL_3 or_later" work inside dist.ini files: `Software::License::GPL_3 or_later' is not a module name

This is used by cme with dpkg model (https://github.com/dod38fr/config-model/wiki/Managing-Debian-packages-with-cme) to provide the correct license text when dealing with `L?GPL-\d\+` clause in `dpkg/copyright` files.

I assume you meant debian/copyright files. Kind regards, Axel

[Leont]

Neither does "license = GPL_3 or_later" work inside dist.ini files:

`Software::License::GPL_3 or_later' is not a module name

You're using a space where you should use an underscore.

[dod38fr]

This doesn't seem to suffice for dzil's usage of Software::License:

You're right.

If I use "GPL-3+" as license in a dist.ini on Debian Unstable, dzil
bails out as follows:

May be dzil should be fixed to use new_from_short_name instead of
plain new. This would make license entry in dist.ini more tolerant. I.e. GPL-1 could be accepted as well as GPL_1

clause in dpkg/copyright files

I assume you meant debian/copyright files.

Duh, yes. cme dpkg implementation details have leaked in this issue 😕