ZDNet: Have you considered offering some guidance on Google Code, perhaps on a wiki page that people could tweak and fight about endlessly :), about which license a new project should choose? Believe it or not this kind of comprehensive and objective info is hard to find.
Stein: Yup. We have thought about this one already. Our reduced list is a start on helping provide some guidance, but we recognize more that can be done."Don't even get me started on dual licensing" This falls into one of those categories of needing to get a Round Tuit. And frankly, it falls at a lower priority than bringing a Download feature to the site (unfortunately, this isn't a topic to just pass to a tech writer).
ZDNet: How about an "Other" category in the new project form so that people who insist on using Google Code hosting at least won't have to fill in misleading information. This will also allow you to go back in a year ago and study the usage patterns to make informed adjustments in the officially supported list.
Stein: While I see where you're going, that just wouldn't be workable. That provides an escape hatch to disable our (ahem) heavy-handed efforts at anti-proliferation.
It might be possible to glean this from a poll/survey or analysis of crawled code. The real problem is that that data does not support trend analysis.
ZDNet: A stats page, like the one on freshmeat showing current license usage, but also show trends (up/down arrows, last week, last month, whatever) would be useful.
Stein: I do like this idea in concept. Note that we'd probably just display percentages since we don't like the numbers game. (we have many many thousands of projects, but I believe that is irrelevant to the community/public)
But sure... we could quite easily create a graph showing trends and percentages. I'll ask the team to see if anybody wants to try this out.
ZDNet: One idea is to move towards using broad categories instead of lists of specific licenses. Something like:
- Free/fully reciprocal (GPL)
- Partly reciprocal (LGPL, MPL, CPL, EPL, CDDL)
- Permissive (Apache, BSD, MIT)
- Other/misc. (Artistic)
I'm sure these categorizations would be the subject of much interesting debate, but this would be even simpler and easier for the average person to understand than having 6 or 9 or 50 choices.
Stein: Fully agreed. We currently have 7 license options rather than 50 so dropping to four would be even better.
In the talks that I give about open source, and "pressure" to move towards more permissive licenses, I use pretty much that breakdown. As I mentioned in my other note, that is also why we have MPL rather than the others: it fills in the partly-reciprocal philosophy.
That said... I think we would organize our "which license should you use?" page around those groups. It is shorter than you'd think though:
- GPL
- MPL (or if we ever replace this with CDDL or EPL)
- Apache
That's it (with documentation on "what and why" for each). One from each, and I wouldn't recommend Artistic. Perl folks use that, and I think they'd know to use it. But even the Perl people are thinking about a new license, from what I understand, so it is kind of hard to recommend an "old generation" license (which is also your argument re: MPL).
[If this list sounds vaguely familiar, check out my article from last year titled "Three licenses to rule them all" --Ed]
ZDNet: I'd almost say cutting it down to the choice of 3 wouldn't be all bad. The current sprawl of the licensing issues is one of the discouraging factors on getting people to start new things.
Stein: Right. It is the crap introduced by the huge number of licenses (the combinatorics of combining / remixing them) which is a serious drag on the community. And don't even get me started on dual licensing (let alone (gawd) triple licensing... *hork*). The Apache Software Foundation spent a TON of time trying to figure out and take a stand on use of LGPL'd Java code within its projects (result: not allowed). And I hate to think what happens in corporate legal departments across the world who are not familiar with IP and open source licensing....
It is because of this mess that Google Code has taken its stand. We want to help the community, and actually taking a position on anti-proliferation is one way that we think we can help.
ZDNet: Can you go into more detail on 3 OSI "tier-1" licenses you don't currently support, and on the Artistic license, which isn't on their list?
Stein: Here are my thoughts regarding the licenses you mentioned:
- CDDL: this is a license primarily used by Sun projects. It does not really see widespread use, other than projects tightly associated with Sun. We'd like to see a broadbase usage before including a license on Google Code. Freshmeat lists just 27 projects using this license.
- CPL: this license is a bit more popular, and is not tied strongly to any vendor. However, it is still not that popular. The characteristics of this license, like the CDDL and EPL, are very much like MPL, so our recommendation is simply that people use the MPL. These other licenses don't add much value. (note that in terms of philosophical similarity, I'd toss BSD and MIT in favor of Apache, but the popularity of the two former... no can do).
- EPL: similar to the CDDL: not very popular, and not really used outside of the Eclipse community.
- Artistic: used by the ENTIRE Perl community. yes, this is community-specific, but um... it's Perl. There is a TON of code here, and a lot of activity. This license is used by more projects that the above three combined. Actually, more than triple the combination of the above. That said, I am personally not in favor of this license (it is very "wiggly"), and the dual license is dumb. But it is in widespread use today, so we will accommodate that. I believe Perl is reviewing their licensing, and I would hope they move to a single, tighter license.
So what does Greg really think about GPL and the FSF? Find out in part 3 of the series, available now. See also part 1.
[poll id=3]