Add support for the Artistic License 2.0

Hi bac, I guess this is yours :) Thanks!

We do not have explicit support between the versions 1 and 2 of the Artistic License. We can change "Artistic License" to "Artistic License v 1" and add "Artistic License v2". Doing so will require we contact the maintainers of the 48 projects that currently have the Artistic License and let them know of the change so they can select the appropriate one for their project.

Or we could simply change it to be "Artistic License v1" and ask owners to accept the migration or change to "Other/Open source" with "Artistic License v 1" specified in the license info field. Version 1 of the license seems to be pretty well superseded so only supporting v 2 makes sense.

In the interests of lessening the maintenance burden, would it be possible to keep "Artistic License" as meaning any version of the license (or as meaning v1), and then add "Artistic License v1" and "Artistic License v2" for package maintainers who want to specify the version?

Artistic License v1 is still used by Perl 5, and by most projects on CPAN, so I would recommend against supporting only v2.

Or maybe

   1. migrate all current "Artistic License" projects to "Other/Open source -> Artistic License v1 or v2"

   2. from now on only offer the specific-version choices

   3. send those package maintainers an automated email asking them to please update their license to one of the specific-version options when they get a chance.

I like Karl's suggestion. Thanks Allison for pointing out the need to keep 'v 1'.

Also, please note I have a typo in my original response where I typed "v1" when I meant "v2" in the first occurrence in the second paragraph. Sorry if that added to the confusion.

A benefit from Karl's migration strategy is that it prevents the skew between code that lands on edge for beta testers and the production code. During that time the licenses we display will be different on the two systems. I propose we do the migration before the new descriptions land on edge but wait to send out the notification until after it lands on production.

In terms of percentages, you'd be safe migrating all existing "Artistic License" projects to "Artistic License v1". AFAIK, there's only one project currently in launchpad under Artistic 2.0, and that's Parrot.

Thanks, Allison! I guess that means the mitigation strategy is unnecessary; we can just set the correct licenses right now.

This license request will be handled at a later date when we do a comprehensive review of the licenses we offer.

We can do this as part of guided project registration license rework.

After further research and discussion, here's what we propose to do.

Artistic v1 is not OSI approved, however it appears to be the most common interpretation of "Artistic License". We will keep the enum and rename this to Artistic v1 for display purposes, but we will also suppress this as a choice moving forward.

Artistic v1 probably doesn't violate our licensing policy, but we think we still want to discourage its use by hiding it in the license selection widget. If people really want to use Artistic v1, they can select "Other Open Source" and enter the v1 there.

We'll add a new enum for Artistic License 2.0 and display this in the license selection widget.

We'll email all the owners of the 66 current projects using the Artistic License and inform them of this change, encouraging them to either select v2 or Other+description.

Brad says: if we're keeping v1, and projects want to continue to use it, they don't need to do anything.

Artistic v1 is OSI approved (has been for a long time). They don't put it on the main page because we're encouraging people to upgrade to v2. Perl 5 and all of CPAN still use v1, and aren't likely to change anytime soon. Speaking with my "Perl Foundation Director" hat on, we'd appreciate if you didn't send out an email message asking them to stop using v1.

Renaming "Artistic License" to "Artistic License 1.0" (keeping the same enum), and adding "Artistic License 2.0" makes sense. You'll get a lot of complaints if you drop v1 from the selection widget.

Allison, thanks very much for the information! I will consult with Brad and Karl, but based on your feedback, I agree we should just rename "Artistic License" to "Artistic License v1" and add an enum for "Artistic License 2.0". I think we should still send an email to projects using the current Artistic, so they are aware of the addition and would be free to switch if they want (I'm thinking about Parrot here). I agree we should leave Artistic v1 as an option in the selection widget.

In bug 382901 I plan to add links to all license options we present. Most will be linked to their OSI page. Can you verify the canonical location of the Artistic v1 license should be: http://dev.perl.org/licenses/artistic.html ?

Your feedback has been invaluable!

Agreed, much thanks to Allison!

The one question I have is: with only 48 projects using it, is it worth offering Artistic License (1 or 2) as a top-level choice? UI wise, it might make more sense to convert them all to "Other / Open Source" and just put the name of the license explicitly.

Definitely agree that we should do the _same_ thing for both v1 and v2, whatever that thing is.

I think it's worth supporting them. The license checkbox grid will get less cluttered as work on bug 333932.

However, I'm now confused again. What specifically do we mean when we offer "Perl License" and how does that differ from the Artistic License (either 1.0 or 2.0)?

I believe "the Perl license" just means "the particular dual-licensing scheme of Perl", as in:

http://dev.perl.org/licenses/

Does it? Why would we support that when people can click on both the Artistic and the GPL? It seems terribly ambiguous to me.

We've agreed that we should remove 'Perl License' from our license selection widget while keeping the enum for existing projects under that "license".

Aye, removing "Perl license" makes sense. Anyone who knows what it means can translate it to Artistic + GPL. (And anyone who who doesn't know can ask.)

On the link to v1, if you're using the OSI links for most licenses, go ahead and use the OSI link for v1 also:

  http://opensource.org/licenses/artistic-license-1.0.php

(That page includes the OSI approval notice and a link to the v2 page too, which is good.)

After thinking about this, I'll handle the Perl License issue as part of bug 333932. That bug will entail reorganizing the license selection widget into sections to reduce clutter. I'll move the Perl License to a "legacy" section and hide that during project registration. During project edit, you'll see that choice only if your project's chosen it, mostly so you can de-select it :).

Fixed released in Launchpad 2.2.6.