Bobulate

It took a little while, but I wrapped up the licenses-as-icons with a summary in tabular form. It’s not on this blog, because I don’t know how to pull in fancy CSS and tables into wordpress. Instead, it lives on one of my personal sites for now. It will move to the FSFE pages in due course, once I’ve had some of the other people in the Freedom Task Force look over it. The page is largely auto-generated now by a little python program that understands the labels given to the different licenses. There is plenty of room for improvement: links to the license texts, better explanations of what the badges mean, etc.

One thing I’m quite happy with is the family overview: it shows which licenses are the same when compared using only the qualities reflected in the badges. So it shows MIT and BSD 2-clause as the same — which I’m willing to accept. Unfortunately, due to the granularity of the badges, it also shows some things together (or at least indistinguishable based on the badges) that do not belong together.

There’s one badge missing: “allows relicensing”, which would for instance distinguish between OSL and AFL (as I pointed out when reading them previously). And it might make sense for every license that gets a warning marker to be excluded from the family groupings entirely, so as to avoid the possibility of confusion there.

Thanks: I’d like to thank Mignon Engel and Egon Elbre for providing icons that can be used to symbolize the different badges. You can switch between the different style sheets in your browser’s View menu (unless you’ve got Safari, which doesn’t support that feature as far as I can tell).

Copyright: Some folks have asked about the license on the icons, the text, these blog entries. Since this is work I do as part of my job for the FSFE, it is copyrighted by my employer — the Free Software Foundation Europe (an independent sister organization representing Free Software in Europe). Most of the materials produced by the FSFE are released under a liberal license, for instance allowing unlimited verbatim copies as long as the copyright notice is preserved (otherwise it wouldn’t be verbatim, right?). However, this material hasn’t been licensed that way yet, so I’d have to answer that right now, it’s “All Rights Reserved.”

Next Steps: Refine the meaning of the badges. Add a relicensing badge. Add another dozen licenses (for instance there’s no Affero versions here yet). Clean up the text. Turn it into a nice booklet. Publish. …? Profit!

In the past two installments, I suggested a basic icon theme to describe the important points of a variety of Free Software licenses, applied those icons to the top ten most popular Free Software licenses and found that several of them are “the same” in terms of icons — which suggests that either what the two licenses does is roughly the same (so we can consider them equivalent) or that there is a distinguishing characteristic that hasn’t been taken into account yet. The second installment took a close look at two licenses that were “the same” and illustrated a third option: that I’d applied the icons wrongly.

One question left over from the first installment is whether the Artistic and LGPLv2.1 licenses are different in a meaningful fashion. I won’t try to answer that here, but instead I’ll carry on with the next top 10 most popular licenses, as enumerated by Black Duck Software again (bear in mind that these licenses apply to less than 1 percent of all Free Software projects):

• Common Public License
  
  This license has been superseded by the Eclipse Public License, but remains more popular than its successor. It looks a lot like the Apache license, although there’s a subtlety in the patent grant (“at the time”) and a designation of jurisdiction (New York). It is weak copyleft, because it requires source to be made available in a reasonable fashion, but certain additions to the program are excluded.
• Eclipse Public License
  
  It is very difficult to see what the difference is between the CPL and EPL. I don’t feel like running diff right now.
• zlib
  
  The zlib license adds to the basic 1-clause or 2-clause MIT / BSD licenses a requirement to mark changed files and to represent the origin (and modification) of the software accurately. I consider that a common courtesey and basic honesty, but it might be good idea to add it to the list of icons; a kind of “label the provenance” image (but I can’t think of one right now).
• LGPLv3
  
  The LGPLv3 is interesting because it is relatively short: it is explicitly a “GPLv3 with these additional permissions and modifications to the conditions”.
• Academic Free License
  
  Interpreting Larry’s licenses leaves me a little scared: it is, after all, his specialty to write licenses. I don’t see how this is copyleft, since there is no obligation to provide source downstream — unless I’m totally misunderstanding the meaning of “contradicts” in clause 1.d. The license itself allows non-contradictory re-licensing; that probably deserves an icon of its own, although I suspect that relicensing is going to be possible only within the group of licenses with the same set of icons (I’d hope so). There is some specific patent and retaliation language here, but the troll in the “patent grant included” icon should make everyone read twice.
• Open Software License
  
  Another Larry Rosen product, and the only difference I can quickly spot is that this one requires licensing derived works and copies under the same license (where AFL allows a different but non-contradictory license). More evidence for the need for a “allows relicensing” badge.
• CDDL
  
  Largely the same as the Mozilla license.
• Mozilla Public License 1.0
  
  Largely the same as the Mozilla license. Oh, wait, this is the Mozilla license, just an earlier version. I don’t feel like breaking out diff just now.
• PHP
  
  The PHP license looks at first glance like a BSD-style license; and then you realize it has six clauses instead of 2 or 3 (four thou shalt not count; five is right out). These have to do with the use of the name PHP and as far as I’m concerned would justify a kind of warning badge saying “surprise conditions here”. I’m not going to draw one just right now.
• Ruby
  
  This is an unusually permissive license because it allows relicensing or public domain distribution and allows binary distribution while pointing only to the original.

That wraps up the tour of the top 20 most popular Free Software licenses, good for pver 90 percent of all software licenses in the Free Software world (though apparently there’s about 1800 variants out there). Today’s list suggests that we need an additional badge for relicensing, one for “watch out!” and perhaps a “represents” badge as well.

So, to return to the original reasons for doing this exercise: provide a quick overview of what the licenses mean that we use regularly in the form of an iconic representation, and to illustrate where the essential points of licenses agree. Tomorrow: wrap-up, table presentation, and a general request for better artwork.

Thanks to all those who commented on my recent proposal to “iconify” licenses. That is, representing the essential terms of various Free Software licenses as icons so you can quickly get a feel for their meaning. This is, in the current state of software licensing, no replacement for actually reading and understanding the licenses, but as a mechanism for quick (as opposed to deep) understanding it seems to work well enough.

ComputerDruid pointed out that we’d need an icon for the network-copyleft effect of the Affero-style licenses (AGPLv2 and AGPLv3). The salient point of the GNU Affero General Public Licenses is that the requirement to distribute source is also triggered by interacting with the program over a network. The license text has an addition (in version 3) to clause 13:

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network … an opportunity to receive the Corresponding Source of your version …

None of the licenses examined so far has such a clause, so that’s why I hadn’t drawn one up yet.

The “Free Software” icon is the only one that grants permissions. It says “this license grants you the Four Freedoms”. The other icons all describe conditions on the license. Copyleft, network effect. The patent grant is both a permission outside the scope of copyright, as well as a condition related to downstream use of those patents and your own patent rights (if any) in the program (in those jurisdictions where there are software patents). In this sense, fewer icons means fewer conditions, and hence more free to use — but at the cost of not guaranteeing the Four Freedoms downstream, for the most part. Compare, for instance:

• This program is Free Software; you have at least the Four Freedoms, but copyright notices must be preserved and the license text distributed with the program.
• This program is Free Software; you have at least the Four Freedoms, but copyright notices must be preserved and the license text distributed with the program. In addition, you are required to provide source (under some circumstances). The source provision applies to your own code as well that is added to the program (strong copyleft). The source provision applies also if you provide access to the program over a network (Affero). There is an explicit patent grant involved.

Whoo. That’s quite some text, but still a great deal shorter than the GPLv3.

Paul Boddie points out that the “weak copyleft” symbol is probably redundant (I agree). That would make the number of source-related icons three (and the number of the counting shall be three). There would be “provide source” (i.e. weak-copyleft), and then two modifying icons for strong and network copyleft. I like it — something to take into account in the wrap-up to this series.

See, by now we’re almost getting into a grammar of these things, which is something I would like to avoid. Keep it simple, keep an overview that allows selection and understanding at a high level, and then look at the relevant license texts in detail.

So, let’s move on to the license texts in detail for a moment. Yesterday I wrote up that the Apache license, version 2.0 and the Mozilla license, version 1.1 were roughly the same. Both got the same set of icons based on my quick reading of both licenses. So let’s take a closer to see if there are relevant differences in the licenses. If there are, we may need to add a distinguishing badge.

General remarks: Apache has a notion of “contribution” spelled out in the license; I think this is intended to clear up what happens when you send a patch to a mailing list — is that intended for inclusion under the same license or not? In my experience, people do submit patches that they do not want to have included — on public mailing lists, no less — but it is very rare. I don’t think this is a crucial difference. The Apache license explicitly excludes linking as a means of creating a derivative work. The Mozilla license defines “commercial use” in a surprising way that includes many things I would consider non-commercial: namely, if I give my friend a USB stick with the source, that’s commercial use according to the license. Mozilla has a concept of “Initial Developer”, which I think is compatible with the Apache notion of “Licensor” — they’re both licenses that are directed at centralized projects with a clear central copyright holder.

Using the software: Mozilla clause 2.1a allows you to use, sublicense and distribute the code and modifications. Apache clause 2 allows the same, but makes explicit that object code distribution is allowed.

Patent grant: Mozilla clause 2.1b grants a license to those patents embodied in the Original Code. Mozilla excludes patents covered by code deleted from the original code — so you can’t re-implement something covered by a patent, it seems. Apache clause 3 does the patent grant and adds explicit termination conditions to that patent grant. Termination in Mozilla is covered in section 8.2. The termination in Apache applies to the relevant patents, while the Mozilla license terminates on any patent. That’s an important distinction when it comes to litigation; I’m not sure it has a place in this iconic scheme, though.

Trademarks: Neither (software, copyright) license grants a trademark license. Apache makes this explicit.

Distribution: Mozilla clause 3.1 and Apache clause 4.1 both require distributing the license text. Both require a notice of modifications made to the original source, but Mozilla wants that in a separate file while Apache allows you to annotate the files themselves. This is similar to the GPLv2 clause 2a, and is something that I very rarely see people (or Free Software projects) do systematically. I don’t think it’s a crucial difference.

Copyleft: Ha, I’m such a moron. How could I have missed this? See, Mozilla clause 3.1 and 3.2 say that the Mozilla license applies to the source code and that the source must be available, also for modified versions. While you may distribute executables under a different license, they must have corresponding source code available under the Mozilla license. So that’s a copyleft license, and the source for executables is available. But … and this is a pretty darn big but … the Apache license does not require this. Clause 4 says a number of things about distribution as source, and allows distribution in object form, but places no restrictions on the distribution of object forms except that the license needs to be included. In other words, you can use the Apache license and distribute binaries without providing source. With Mozilla, you can’t.

So it’s a good thing that the similarity in the reduced representations of the licenses (i.e. the row of icons) has led to a re-examination of the licenses, because it leads to the understanding that the licenses are not the same, by a long shot. Of course, I could have just looked it up in the FSF license list: Mozilla (copyleft, not GPL compatible) and Apache (no copyleft, GPL compatible). If I were a professor I’d claim I’d made the error intentionally in order to spur closer examination of both licenses.

Mozilla Public License v.1.1

Apache License v.2

Tomorrow I’ll carry on with the next 10 licenses in the top-20 list to see if any interesting new features show up, and then on Saturday I can wrap up with a table showing the 10-mile view of all those licenses.

An idea that is suggested every now and then is to look at software licensing and give it a kind of “Creative Commons” feel; that is, present the terms of the license in a pleasant and orderly way by means of icons. Now, we’ve already come to the realization that calling something “Creative Commons licensed” is vague to the point of being useless (just “some rights reserved“). Calling something “Free Software” is also vague, but there is a rock-solid guarantee at the bottom: the term guarantees you, the recipient of the software, at least the Four Freedoms. Any Open Source software you receive usually means at least the Four Freedoms as well. So you need to say which CC, which Free Software license, which Open Source license.

CC has six licenses; they are split neatly and orthogonally along the commercial / non-commercial and yes / share-alike / no axes.

The thing is, CC is a much simpler system because it applies to work where there are no patent concerns, where embedded systems don’t have a place, where share-alike has a simpler meaning. I have trouble bringing this same simplicity to software licensing, but I thought I would give it a try.

First off, every Free Software license gives you the right to run (presumably also to compile and then run), study, and modify the work; it must be possible to (re)distribute the (modified) work. So those are the basic permissions. We could put them under a basic “Free Software” symbol, like I’ve done here.

Now we get to modifiers of the basic license. What is allowed by one Free Software license, and not allowed by another? Where do the licenses differ on essential points? Going through such an exercise opens up the debate on what constitutes an essential point of difference between licenses. Still, I think we can agree that many licenses ask you to deliver the complete corresponding source along with a binary. Details (written offers, etc.) differ greatly though. In the interest of simplicity, though, we’ll just lump it all together as “publish the source”. The BSD License allows binary distribution without publishing the source, so it doesn’t get this symbol.

Now to distinguish strong copyleft from weak copyleft — that’s really important when you want to know what the effect is on your own code and own license choices if you are going to incorporate another piece of Free Software into yours. I suppose, actually, that we don’t need to distinguish this dimension from the previous “publish the source” dimension: I think every “publish the source” license is also one of the two kinds of copyleft (although I can imagine a license that says you must re-publish the original source, but not necessarily your modifications).

So how about Tivoization? Or in other words, embedding into a device and then selling, renting or lending the device instead of delivering the software sec? It’s a real difference between GPLv2 and GPLv3. It’s explicitly mentioned in some faux Free Software licenses that allow use except when embedded. I call them faux (fake) because Freedom 0 is the Freedom to use, for any purpose, and clauses 5 and 6 of the Open Source Definition do much the same. So let’s add that dimension into the mix.

I’ll throw in patent grants as another factor. This is an over-broad blanket, because the subtleties of patent licensing are devilish. The Apache License, version 2 for instance contains a patent grant with a termination clause. So does the CDDL.

So, let’s take a look (squinting through this rather imperfect telescope) at the big picture. We’ll take the top 10 licenses (according to Black Duck Software) and for each, label it with icons like these and comment on what’s been missed out by the icon scheme. Note that these are not necessarily all Free Software licenses, and not all of them are widely used across the Free Software ecosystem.

• GPLv2
  
  “The original and best” Most widely used license, apparently applied to nearly 50% of all Free Software projects. I imagine that 50% also comes from things like “v2 or (at your option) any later version” licensing.
• LGPLv2.1
  
• Artistic
  
  Artistic is applied to a huge number of Perl modules, which are counted individually, which is why Artistic shows up as a significant license force, even if it is almost unused outside of the Perl community.
• BSD 2-clause
  
• GPLv3
  
  The Tivoization clause (part of section 6) can be disabled in the GPLv3 by granting additional permissions in accordance with section 7, if you really want.
• Apache 2.0
  
• MIT
  
• Code Project Open 1.02
  
  The CPOL is a strange license. It is not OSI approved, as near as I can tell. It seems to disallow the distribution of modified works, certain uses are disallowed by the license (immoral ones), there’s a no-sale clause, indemnity, and some other bits that make this license difficult for me to place anywhere in the world of Free Software.
• MS-PL
  
  The MS-PL is kind of strange; I’ve never seen it in practice. It looks roughly — very roughly — like BSD plus a patent clause. This is a Free Software license, but GPL-incompatible.
• Mozilla
  

Comments on my artistic icon skills should be addressed to Nuno Pinheiro. You may be able to hire him to do very nice icons for this set-up, and Björn Balazs can do usability testing on them. Kolourpaint FTW. Now, as for the accuracy of this table, I’ll say it’s a best-effort one-morning overview, so there may be plenty of errors in there. The point is the principle of reducing the licenses to a sequence of icons. The icon for patent is a patent troll (notice the glowing red eyes) because I couldn’t think of anything better.

So, errors and omissions aside — I welcome corrections in the comments on this blog — we need to ask the question: does this scheme of badges highlight any (all?) of the essential differences between the different licenses? If not, what additional discriminatory characteristic should we add to distinguish them?

Based on this list, we see that BSD 2-clause and MIT are “the same”. Are they really? Well, it depends on how you interpret the second clause of the BSD 2-clause license and whether the single MIT clause implies it. In a world of good faith, you could satisfy the MIT license by doing what the BSD 2-clause license asks you to do. So I think I could be satisfied that this is a same-difference identification of two licenses.

But we could look at some others — is Apache equivalent to Mozilla in all meaningful ways? How about LGPLv2.1 and Artistic? That, however, will have to wait for another day. Where I set out to demonstrate that you can’t reduce licenses to blurbs and icons, I haven’t done so yet — and still, such a reduction might be useful from a license selection standpoint, because you can pick and choose based on broad categories of license behavior.

Ah, the Powder Blues band. Apologies, mostly.

I know a place on the wrong side of town,
Where the band width is cookin and they’re loading on down,
Joe compiles like his souls on fire,
Baking a new firmware for a telephone wire,
Rev up the sources, compliance comes down,
Doin it right on the wrong side of town!

In these troubled times, I thought I’d share some tales of companies doing it (relatively) right. Thanks to the quiet pressure and diplomacy of gpl-violations.org and their (and FSFE, too) desire to work on dialogue and long-term solutions, it’s possible to find consumer electronics in Europe that are compliant (within the wriggle room that is left in the notion of “compliance”).

In September I picked up a Lacie Network Space drive. 1TB, I think, UPnP server, black, glossy. So of course the first thing I did was go looking for GPL violations. This ended up with a half dozen folks standing around a table, red wine in hand, an improvised network on the floor. The manual of the product doesn’t mention the GPL. If you boot it up, you can get the syslog:

Jan 1 00:00:28 syslogd started: BusyBox v1.1.0 (2006.11.03-14:53+0000)
Jan 1 00:00:29 kernel: klogd started: BusyBox v1.1.0 (2006.11.03-14:53+0000)
Jan 1 00:00:29 kernel: Linux version 2.6.12.6-arm1 (jrichefeu@grp-horus) (gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2)) #3 Tue Feb 3 14:04:45 CET 2009
Jan 1 00:00:29 kernel: CPU: ARM926EJ-Sid(wb) [41069260] revision 0 (ARMv5TEJ)

I should add it’s really quiet a nice piece of kit, except it never spins the disk down. And of course, the manual doesn’t mention the GPL. But the support section of the website does, and it’s not difficult to find the source downloads section. I haven’t verified that these are the complete and corresponding sources. It looks reasonable, though.

More recently I bought a Conceptronic Media Giant Plus, which is a HDD plus codecs and a bunch of A/V plugs, so it goes right into the TV — and then videos and whatnot go on the HDD, and play from there. The UI is a little clunky, but it works well enough, and if it saves having to go through and find the right DVD for the kids all the time, that’s fine by me. I don’t know what the hardware inside is exactly; it’s been on only once so far to copy the Eefje Wentelteefje TV Show onto it.

The box comes with a thin leaflet of license compliance statements. “Great!” I thought, but it turns out to be MPEG-4 compliance, and Fraunhofer, and all kinds of commercial licenses, patent licenses, consortium licenses, etc. No mention of the GPL. No mention of the software actually running on the machine. “Drat!” thought I. I don’t rub my hands together and cackle evilly then, though.

So my surprise was a little greater when I leafed through the (thick and comprehensive) user manual and found, at the back, a chapter “Licensing Information”.

This Conceptronic product (Media Giant) includes copyrighted third-party software licensed under the terms of the GNU General Public License. .. the following parts of this product are subject to the GNU GPL: (list including busybox, xine, Linux kernel). … Conceptronic as eposed (sic – exposed?) the full source code of the GPL licensed software, including any scripts to control compilation and installation of the object code. All future firmware updates will also be accompanied with their respective source code. For more information on how you can obtain our open source code, please visit our web site.

That text is followed by the full text of the GPL version 2, the LGPL version 2.1 and the FreeType license, 2006-Jan-27.

So, that’s pretty thorough except that a “visit our website” isn’t all that specific. I couldn’t find any links to the source on the product page, but some searching turned up the source at last.

So here’s two cases of “yeah, that’s ok, could be better, keep trying” — it’s like dealing with my son learning to ride a bicycle, they need some encouragement and support, because they’re still learning.

Wednesday I was at the European Parliament building for the EOLE. The event is a medium-sized (say 60 attendees) legal oriented event around Free Software; this year it featured a track full of definitional goodness — let’s try to formulate words commonly used in Free Software (in licenses, but also other writing) in terms that lawyers can understand.

This kind of event is useful because it works towards normalizing the vocabulary used by practitioners in this area: in other words, we end up calling a spade a spade. If we can agree on what “source code” means exactly in the context of the GPL (actually, version 3 has a fairly lengthy definition, which is something we can work with), then it becomes much easier to consistently advise projects and businesses on how they can best engage with Free Software.

Any get-together of people with a strong legal background in Free Software is sure to bring out some more interesting interpretations or corner cases. There’s always another jurisdiction or recent ruling to take into account, and of course every now and then another new license rears its ugly head (like the Jiggy Wanna license, which is basically Sleepycat if I read it right, but still different). In many ways the resulting discussion “dude! if you squint just like so and read the GPLv2, it turns into a dinosaur!” is a lot like a Free Software technology conference “dude! if you hold your breath and do this DBus call, dinosaurs come out of the firewire port!” Fun corner cases, even when we realize that the core values and meaning in uncomplicated cases (read: situations entered into in good faith by all parties) are well understood.

For me — and just how many times have I read the darn GPL, anyway? — the best insight of the day was the proviso of the GPL that says that the written offer of source code availability (if you don’t deliver the source with a binary distribution) must be valid for any third party. So that has a definite effect on your obligations under the GPL; it also affects some GPL-related advice I’ve given in the past to people, as I thought that the written offer applied only to those who have obtained the (binary) distribution. In a license, every letter counts (which is, in a sense, also unfortunate, because that’s why we have so many).

Yesterday I rattled on about change processes for open standards; or at least, tried to suggest I’d done some thinking on the topic. This post is a little more “meta” because I’m going to point to some articles describing how the standards up to which standards are held, change — in non-open ways.

First off, the Free Software Foundation Europe (FSFE) has a definition of Open Standard. Like I said, it’s one of many; it is based on the European Interoperability Framework (EIF) definition, strengthened a little for Free Software. The Dutch government agency for software, NOiV has a Dutch definition, again directly derived from the EIF one.

There is an update coming to the EIF, described in (among others) ArsTechnica’s “EU waffles” article. The update is still in draft form; the draft was leaked to Brenno de Winter. Since the update was supposed to have been published by now, the fact it’s still in draft suggests that the (non-open) process for updating it is not going too well. Ryan Paul picks out many of the key problems with the new (draft) definition, in particular changing the language from fairly clear, fairly forward thinking, to one that is muddled and unclear. Replacing clarity with confusion does not, to me, constitute a valuable change in a standard (a meta-standard, describing how other standards should work: in other words, muzziness here is damaging across a far wider scope than just one badly-written standard elsewhere).

In a sense, you could say “closed is the new open.” Or maybe “closed is just a kind of open, at the 0.0 mark on the sliding scale of openness.” Yes, and slavery is just 0.0 freedom, and broken is just 0.0 functioning. Indeed, on scales like that, you can make almost anything mean anything at all (lemons just taste 0.0 sweet).

Karsten Gerloff has the FSFE’s response, and points to an article by Glyn Moody (where I see Keith Jones has added a comment that pre-dates this entry, with the same gist — I think he misses the point where the new EIF says “for interoperability, we need open standards, and open standards are ..”; relatively good comments thread there, anyway.)

Two days of LinuxWorld have left me tired by happy. I ended up giving two talks, because Karsten and I made it a double on wednesday and then on Thursday I had another one on best practices in license selection for Free Software projects (one-line summary: pick one that is consisten with your business strategy). The Open Source pavilion at LW isn’t all that large, so 14-20 people as an audience fills it.

Besides giving some talks on licensing topics (FSFE hat), I sometimes stood around the NLUUG booth and handed out posters for the next NLUUG conference — spring 2010, topic “System administration.” Very traditional for an Open Systems and Open Standards organization. And aside from that, wandering around a trade fair with four themes — Linux, Storage, Security and Business Tools — is an education in itself. I try to make clear at the start of every conversation that I’m not a sales opportunity, as that seems to avoid wasting time for both of us if I run into a hard-sell booth (still, the one stand that asked “How many workplaces does your company have?” and then “Well, you have less than five hundred desks, you’re not interesting, goodbye!” — I never even found out what they were selling at all.) You can still get conference goodies though, so I got home with a nice collection of peppermints and flashlights for the kids.

It is possible for software to be Free Software (in the sense of GPL version 2 compatible), and yet not satisfy the requirements of the Open Source Initiative for being an Open Source license. This is an obscure corner case in the GPL, because people usually (not always) mean Free Software when they say “Open Source” — stressing a technical detail that is a prerequisite for Freedom over Freedom itself.

The relevant bit of the GPLv2 is clause 8:

8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.

You could write GPLv2 licensed software whose distribution to the United States is prohibited, for instance. This clause allowing additional restrictions based on geography has not survived in the GPL version 3.

In any case, for a GPLv2 plus geographical restriction license, the problematic requirement is requirement 5, No Discrimination Against Persons or Groups, formulated as: The license must not discriminate against any person or group of persons. Clearly restricting a GPLv2 licensed product to a certain geographical area discriminates against a specific group (i.e. those outside that area).

I’m told — but have not verified — that there are also two Open Source licenses that are not Free Software (i.e. the converse of the compatibility issue pointed out here). I’m also told that they are used by one project each, so it’s not a huge burden on the Free Software community.

This week I was in Grenoble for the Embedded Linux Conference Europe. On the seond day of the conference — Friday — I was one of the few people wandering around in a suit. Even the guys who normally wear suits had dressed down to deal with the nitty-gritty of kernel threads, time sources, and boot time optimization.

So I talked about licenses. And license obligations. And interesting bits of the GPL version 2. There’s one clause of the GPL version 2 that I’d like to single out because it’s one that is surprising to me — and rarely mentioned. Clause 6.

6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients’ exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

So, let’s suppose you (Bob) receive a program under the GPLv2 from the original author (licensor, called Alice), and pass it on unmodified to a third party, Charles. Clause 1 of the GPL applies, because it is verbatim. You just need to give Charles a copy of the license, and Charles receives a license from Alice automatically. There is in my reading no license, no relation whatsoever between you and Charles. Now if Charles distributes the program, the only license he could violate is Alice’s, and it is Alice who would need to enforce any violation.

This is actually how it works, too — suppose Alice wrote a part of the Linux kernel, she grants a license to any recipient (Charles) even though there are second parties involved (Bob); Alice can enjoin Charles to satisfy the requirements of the license. (For Alice perhaps read ‘Arald)

Now suppose you, Bob, modify the program before distributing it. In that case, clause 2b comes into play and the resulting work (based on the program) is also covered by the GPL version 2. When you distribute it, Charles receives a license from you to the modified work, and Charles receives a license from Alice to the original program. This is powerful, because Charles now has two licenses and two licensors that he must satisfy — but also weak, it seems to me, because Charles could violate one of the licenses and still keep the other. So if Bob sues Charles over compliance, Charles could just switch to the original Alice version (unless Alice enforces compliance issues as well).

It’s unlikely that would work in practice, because Charles wants the modifications done by Bob. Probably.

PS. Thanks to Saul Goode for some very careful and relevant comments to my previous writing on the GPL version 2; in particular pointing to the US Copyright Code and how it doesn’t restrict running the program at all — as indeed the GPLv2 itself writes “The act of running the program is now trestricted.”