project creation page should encourage common licenses

Just to be completely unambiguous: when I say "project creation page", I mean:

   https://launchpad.net/projects/+new

As I understand it, there are three possible reasons for asking for a license at all:

(1) To help discourage registration of things that aren't software-related. This would be catered for just as well by a single-choice menu of half a dozen items than it is by a multi-choice list of twenty-something items (no matter how they're presented).

(2) To let people search for projects matching a particular license, for the purpose of sharing code. It seems unlikely that this would ever be sophisticated enough to be useful, though: Launchpad will never understand, for example, that code licensed under GPLv2-or-later-with-the-font-exception can be used in a project licensed under GPLv3-only but that the reverse isn't true.

(3) To allow recording and presentation of statistics on how license choice is changing over time. This would be fun, but not particularly useful, and you'd probably be more interested in the relative popularity of the common licenses anyway.

If that's an accurate summary, the license selection could be just a single-choice menu, containing only the ~10 most common licenses (as requested by this bug), and ending with the catch-all option "Multiple/Other OSI-Approved".

Note that the license choice is the place where we steer some projects toward our commercial offering. So the "Proprietary/Private..." option has to be there; the single "Other" catch-all isn't enough.

Re (2): Launchpad doesn't have to understand what the licenses mean -- searching is still useful if just the humans understand, or can write their own code that understands (i.e., since we have APIs, it can be useful to record data that Launchpad itself doesn't do much with).

But I think the real issue is automation of project approval. If we have just a generic Other/OSI-Approved option, some percentage of people are going to use it for licenses they made up, or for licenses that aren't actually OSI-approved. Even if we have "Other OSI-Approved: [text field here]", so they could type in the name of the particular license, we'd still have to review it, since every license can be spelled and abbreviated in a myriad different ways. Whereas with a set list, we know that if they checked that radio button, then that's the exact license they meant, and we don't have to spend human time making sure.

By the way, we could handle the "multiple licenses" situation by making them checkboxes instead of radio buttons (if they're not already).

License selection is currently done through checkboxes so a registrant can select as many as appropriate.

Currently registering through the normal means requires selecting *something*. Often we see 'Other/Open source' with "I don't know yet" as the additional information. So I agree people would just default to the Other OSI-approved.

The existence of "Other/Open Source" means that, if people want to register a project with a made-up or unsanctioned license while telling the truth, they already can. And since you already need to review every project for other reasons, collapsing the more obscure options into "Multiple/Other OSI-Approved" (with the text field) wouldn't introduce any new review requirement. It would, though, make project registration less daunting.

I want to address this issue with the new project guided workflow.

Here's a thought, based on the guided project registration stuff. The pull down for licenses can have the top 7 or 8 (whatever looks best in the u/i), then there would be an "Other open source" choice. This latter would prompt you for a url to www.opensource.org which should be the only arbiter of "what is an open source license" that we care about. If the url you enter doesn't 404, then we accept it as an open source license.

Otherwise, you can use "Proprietary license..." and enter in a text field what the license is.

Bug 174661 tracks the database/enum backend work of adding the new CC licenses. This bug now tracks just the ui work to expose those to projects (along with the other ui changes). The branches for these two bugs will land separately.

From bug 326308:

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