Bobulate

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

I was surfing around — you know, the usual sequence of Slashdot, Groklaw, random linked articles — and encountered the LLVM license (actual license text). I thought I would take a moment to look at this one and compare it to other permissive Free Software licenses. Broadly speaking, the LLVM license is one that allows everything, and requires: retaining copyright notice and disclaimers, in source or in documentation, and disallow using authors names for endorsement. Compare it to the 3-clause BSD license , 2-clause FreeBSD license or the 1-clause MIT license.

A couple of comments on this license family is in order; one is that I find the MIT license a tad unclear(!) because I don’t understand how to include a copyright and permission notice that is part of a comment in a source file in the software. The intention is clear enough, I guess: put the notice in a README or at the end of the software manual, and you’re clear. It seems to me that some mention of binary distribution vs. source should have been done, if only to clarify that point.

The second is that the header of the LLVM license invites a form of poor copyright management; this isn’t the license’s fault per se, but it contains language that suggests to other developers to do things sub-optimally [[ gosh, it’s hard to pick just the right words here; “wrong” sounds more pithy, but is also more likely to annoy people into not listening at all; the point is there are best-practices ways of doing things and anything else isn’t, well .. , the best ]]. It’s the inclusion of a group of developers at the top — the “Developed by” line, as well as the “Copyright <Owner organization name>”. These are tempting to developers of community-led projects to put in non-existent organizations or poorly-defined groups like (and I’m culling these examples exclusively from KDE because I happen to have a KDE SVN source checkout here)

(c) 1996-2008 The KDE System Monitor Developers
(c) 1999-2008, The KDE Developers
(c) 2003, The KHelpCenter developers
(c) 1998-2000,2003 The KFM/Konqueror Developers
(C) 1999-2008, The Konqueror developers
Program copyright 1997-2001 The KInfoCenter Developers

The problem lies in the fact that these groups are defined if and only if you have access to information outside the sources themselves — e.g. mailing list archives or version control system history. Putting these non-existent groups in a copyright header weakens the copyright (just a little — after all, each original author is a rightsholder, regardless of whether he or she puts her name to it) and makes compliance engineering just a little more difficult. Note that putting an existing organization there that actually holds the rights is just fine: my own code in KDE SVN should read “Copyright 1999-2008 KDE e.V.” because I used a Fiduciary License Agreement to assign the rights. Again, none of this is the license’s fault per se, it’s just an easy-to-misconstrue example.

So here it would be better — for everyone, and KDE coders in particular — to follow an example that said “Copyright <year> by <name of actual author> <email address>” because that is safer from a governance standpoint in the long run. There’s no fictitious entities involved, and complete documentation of who might be a holder of copyright in the file (besides, clause 2a of the GPLv2 wants you to do this as well).

Finally, the last bit of commentary goes not to the license text but to the explanation given by LLVM for their reasons for choosing this license over the GPL — except for llvm-gcc, which is necessarily GPL-licensed because it is a derived work of gcc, which is GPL licensed itself. And it’s the use of the word “viral” that bugs me here. It’s bolded on the LLVM license webpage, and is wholly unnecessary since they manage to explain what the GPL does pretty darn well; it’s just adding a typical FUD-word to an otherwise fine page explaining a license choice (a legitimate license choice for a Free Software license done by the original authors, and hence one to be respected). A better line for that particular web page would be “any code linked into llvm-gcc (which is GPL licensed) must also be released under the GPL, as per clauses 2 and 3 of that license.” (This assumes it’s GPLv2-licensed).

Anyway, an interesting (for me, but then I like to read licenses and the reasoning behind license choices) jaunt into non-copyleft licensing territory. [[ PS. And yes, there is a 4-clause BSD license, which has the Advertising Clause; I’m not aware of a 5-clause one, but there is a 3′-clause license, the Sleepycat license, which is formatted like a BSD-style license but has a strong copyleft component. ]]

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.

The GPL version 2 was written back in 1991, in some sort of “plain english”. At least the intention was to write a clear document that allows recipients of a copyrighted work (e.g. a compute program in source code form) the four freedoms,

• 0: The reedom to use, for any purpose;
• 1: The Freedom to study the program;
• 2: The Freedom to make modifications to the program;
• 3: The Freedom to distribute the program, either in modified form or verbatim, either as source or as a compiled object./li>

(This is not the canonical form of the four freedoms, heck no). There are restrictions on when you may exercise those freedoms. In particular, when you distribute the program, you need to give the recipient the source code. If we boil it down to its syrupy goodness, this becomes “you can have this to do what you like, but anyone you give this to gets that same right.”

Well, that’s the intention. And under normal use, this is how it works. The GPL gives you permission to use the software (you must have a license to even run a piece of software you have, because of the way copyright law interacts with software). If you violate the terms of the GPL, then you can’t use the software. Simple.

The GPL version 2 has some extra text outside of the legal parts; for instance, one bit tries to clarify the intention of the license:

This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.

However, intentions come into play to only a limited extent in licenses. There is the text of the license, which is .. well, suffice to say it was written in 1991 with plain English in mind.

The Register is reporting on a webcast hosted by Black Duck Software with Karen Copenhaver and Mark Radcliffe. The Register article starts out with the misleading paragraph:

Two prominent IP lawyers have warned that the all-pervasive General Public License version 2 (GPLv2) is legally unsound.

Unsound doesn’t mean broken, and unsound doesn’t mean that the main use of the GPL version 2 is unsound. There’s a great deal of ambiguity in the license; I saw a talk by Sean Hogle at OSiMWorld with similar points. In particular this ambiguity exists around “derivative work”, although “distribution” is also not watertight. One illustration that “distribution” doesn’t cover everything that might be intended is the existence of the Affero GPL (AGPL).

Note that the analysis presented (in the webcast and summarized on the Register and then summary-summarized here) applies to the GPL version 2 only, and the GPLv3 is a great deal clearer (from a legal point of view, although it’s a lot more words).

As far as the Register article goes, the first comment finishes with “Rocket science it is not.” No, it’s not rocket science, but the gap between what you want (or what you have been led to believe) and what the text actually says — let alone what it does when subjected to scrutiny — may be very great. And that’s the different between landing on the moon, crashing into the moon, and exploding on the launch pad (which is AGPLv3, BTW).