Bobulate

The IFOSSLR — the International Free and Open Source Software Law Review — has published issue #3. The IFOSSLR is the only journal dedicated exclusively to Free Software legal issues. While I was the FTF-Coordinator at the FSFE it was great to see the careful legal thought put into all kinds of issues (from trademarks to license assignment to risk assessment). It’s important to have an understanding of the legal issues around Free Software (both development and deployment) that is business compatible. That’s not to say that the interpretation is adapted to suit the desires of business — no, it means that the understanding is formulated in a way that businesses understand. It’s quite important to state cause and effect or obligations and rights carefully so that businesses understand what to do and how to do it right. After all, most Free Software developers want everyone to play by the rules set out in the license.

Sometimes what’s necessary from a business standpoint isn’t what we’d like from a Free Software perspective, but there’s no basis for real complaint. The licenses say what they say (which is why you should be careful in picking a license!), and with a good understanding of what they actually mean, both developers and business using the fruits of that development can get on with what they do. See for instance this bit on the Freecom Music Pal (I have one of those too; it’s OK for listening to Country 105 but the author is right that it’s rather difficult to hack and the firmware is wretched).

The IFOSSLR is available gratis as a PDF, or you can get a printed copy via LuLu. I’d suggest the latter, because legal journals just look really impressive on paper.

As a collaborative publication, the IFOSSLR is always looking for submissions, too. See the Call for Papers for issue #4 for more information. It’s not just for lawyers — the perspective of community and developers on legal issues is really important. The practice of Free Software licensing is an interesting area because there are four (no, wait, six) parties involved: the drafter of the license, the developer using the license, the user of the software released under that license, the community (c.q. peanut gallery) of users of the license, the lawyers for each of the aforementioned parties and the courts. Getting all that to align in harmony is a big task: a task that requires communication and publication. So throw your thoughts into the fray.

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.

Fell quiet for a bit there. After ferreting out some anti-blogging quotes written fourty years or more ago, I headed off to the UK. Lincoln, which does have a very nice cheese shop as well as a cathedral. There was ale and innuendo — and a blind taste test to see if Stella Artois is actually different from Beck’s — as well as some planning of interesting Free Software things. I have another research paper to wrestle with now, for one thing. Returned home to sad news in the KDE community. I will remember Matthew as the guy who inexplicably got me not one, but two horse whips — which I take to most conferences ever since.

I didn’t take the whips to OSiMWorld, though, because that didn’t seem like the right kind of event. More suits and ties, less silliness. Although Lefty tried, with his pub quiz. Last year, the Roaming GNOMEs won, this year it was the “Intelligents” — big Intel / Atom presence at the show. The European Legal Network team came in third, which is reasonable. The available knowledge on the team was dramatically skewed: sports were clearly our worst category.

For the OSiMWorld conference itself, I must say it was fun to meet some more Trolls and troll-alikes, chat with a bunch of people from GCDS, like the Igalia guys. Saw some very nice Linpus desktops. What impressed me most was the attention to detail — the visual feedback on user actions, the clear organization of the desktop. Something that comes from understanding the target audience and the limitations of the device. Similar efforts at polishing the user experience are the hundred paper cuts. Chatted a bit with the Canonical folk about that. But the attention to detail and tailoring for more specific uses is something that takes a way a bit from the general purpose computing model, and moves towards appliances. When I was shown a nice Atom-based MID (mobile Internet device), my response was “ooh! cluster of x86 build machines!” which is very much not their purpose. Pointing to Lefty again, he summarizes arguments against the Desktop, some of which were presented at the conference itself.

One of the things that surprised me at the conference was the number of people who “get it” from a Free Software and business perspective. Free Software asks you to play by the rules (that’s a link to the GPLv3, but of course there are other rules you can agree on: MIT/X11 rules, or APLv2, or others). Many of the people I spoke with at the conference understood the importance of licensing and of working with — or at least not against — the communities that produce the Free Software they use. It struck me that there is an increase in what I’ll call “business-led Free Software” alongside “community-led”, and that the management styles and processes of the two are quite different. Heck, talking about management in a community context always makes me a little queasy, call it leadership instead.

I had a nice chat with Peter Vescuso of Black Duck about license compliance and processes. We seem to have a common desire for understanding of licenses and license interactions and working with the implications of license terms for projects and businesses. For Free Software projects — community-led — the desire is for long term safety and stability and protection of the principles that the members of the community around a project want. Pragmatism is necessary to understand how people in multiple fields of endeavour interact. Idealism is needed to start the ball rolling.

It’s planned to be a busy week or three for me with conferences and articles, so somewhere in between I hope to write about some of the other interesting technical and legal stuff that is happening.

I suppose pointing out deficiencies in /. articles is like pointing out that someone is wrong on the Internet, i.e. it are sadness, i.e. just don’t get started, but when there’s two stories on there in one day that tremendously misrepresent legal or licensing issues, it gets my goat. And my goat is gruff.

SCO: The first is relates to a recent development in the long-running case between SCO and Novell, where the /. summary points to NetworkWorld and to the Salt Lake Tribune (which stories largely overlap). No link to GrokLaw’s commentary (although it shows up in one of the early comments on the story). The /. summary contains the finely misleading sentence

… Court of Appeals said it was reversing the 2007 summary judgment decision by Judge Dale Kimball of the US District Court for the District of Utah, which found that Novell was the owner of Unix and UnixWare copyrights.

I’ll call that finely misleading because of the way in which it represents what is reversed and what is not. Yes, there was a summary judgement. And in this new one, the court says We affirm the judgment of the district court in part, reverse in part, and remand for trial on the remaining issues. Essential, then, to report accurately on what is reversed and what reversal means in this context. So you actually need to read the text of the judgement (e.g. through Groklaw) to find that the court finds the following:

Because we conclude summary judgment is inappropriate on the question of which party owns the UNIX and UnixWare copyrights, we must likewise reverse the district court’s determination that “Novell is entitled to summary judgment [on SCO’s claim] seeking an order directing Novell to specifically perform its alleged obligations under the APA by executing all documents needed to transfer ownership of the UNIX and UnixWare copyrights to SCO.”

(p. 34 of the judgement) So an accurate summary would be more along the lines of “the court finds that the earlier decision to award summary judgement was inappropriate”: Avoiding the word “reversal”, especially in conjunction with a statement about who owns the copyright, is important in presenting the result. Indeed, one might have written “remanding to trial” instead of “reversing” and made the actual impact clear instead of implying some reversal regarding the actual copyrights.

License Wars: My second gripe comes from the /.-frontpage-promoted article FOSS Licences Wars by Shlomi Fish. He thanks dazjorz for comments on drafts — personally I would have thought dazjorz knew better after getting through CodeYard. I think the article starts off on the wrong foot with the word “wars” already. Especially if you are trying to present some kind of reasoned argument for one particular license or one particular model of licensing. I won’t quibble with numbering the four freedoms from 1, as I usually make the numbering out to be a bit of a joke myself. And it’s factually correct that using the definitions of Free Software and those of the Open Source Initiative leave space to have software that is one but not the other. However, because “open source” is misused as a marketing term (though, granted, searching for free software will point you at warez) the FSF and the FSFE talk only about Free Software — because it is the freedom of the recipient and all future recipients that must be preserved, not the economic or development model.

A copyright is in a sense always proprietary, because it is a monopoly granted by the government to an entity to control the copying of a work. There is a proprietor who holds the rights; the trade-off (social contract, if you will) between the rightsholder and society is that eventually the protected work is no longer protected, and at that point the original rightsholder no longer has any say for a published work. Note “published” there, or “made public”; there is a strong notion that the public — “we the people” — eventually get to use freely creative works works originally made available under a monopoly. A license is a means for the rightsholder to grant a licensee additional rights — rights which the licensee does not automatically have. Hence we need to grant a license to actually use software (instead of hanging the software on the wall, although even that might not be allowed under stringent interpretation of the copyright conventions). To call BSD-style licenses “public domain licenses” is misleading, because public domain as a legal notion doesn’t apply everywhere, but even if it did, the fact that there is a license means by definition that the work is still a protected work under copyright; the monopoly still exists, but you are given a license to do things with the work in addition to what the social contract allows. A more accurate term would be “non-restrictive Free Software licenses” or “very permissive”.

I’m actually grateful for the reference to “copycentre” to describe BSD licenses — I had never heard that one before. The linked Wikipedia article oddly characterizes BSD as sitting between public domain and copyright, which is like saying that a member of a soccer team plays on the field (somewhere). Dang it, I’m no good with sports analogies, am I. Every license is somewhere between those two extremes of fully proprietary control and no control at all. Again, using the term “restrictive” would make more sense as one axis of distinguishing software licenses.

On the restrictiveness axis, it goes something like (from no restrictions to many) public domain, BSD-style, weak and strong Copyleft, proprietary software licenses, monopoly.

I can’t argue with the sections on weak and strong copyleft licenses from Shlomi (I don’t need do be curmudgeonly about everything, there’s some other guy for that). In fact I quite like them. One issue I would point out is that linking is a grey area, because it is a technical one with many different implementations; indeed the fuzzy nature of what constitutes linking is one reason that members of the European Legal Network, supported by the FSFE’s FTF, are working towards documenting best practices understanding of what linking is. And that turns out to be quite tricky, because it is all about functional dependency and an understanding of what constitutes a derived work and a composed work — concepts which vary by jurisdiction.

It’s in the “curious licenses” that things derail again. The Affero GPL tries to close the “distribution loophole”, which is a way of using GPLed software without providing source: one need not provide source code (of a GPL or GPL-derived work) unless one distributes it to another party; by providing access to the in- and output of a piece of GPL-derived software one does not distribute it — and hence a whole chunk of the GPL meant to preserve users’ freedoms does not get triggered. The Affero GPL closes that loophole (calling it a loophole implies that it’s a bad thing, which is not an opinion widely held) by triggering the clauses requiring the availability of source code in more cases. I think there might just be some words missing in this paragraph, particularly in the parenthetical “because I may wish to run it on my publicly accessible web-server and modify it” — perhaps the author dropped “and not publish the changes“, but it is difficult to guess. It’s either that or the tension between the AGPL and Freedom 1 (2 in the numbering used in the article) doesn’t exist. The closing sentence about killing web-services is a complete red herring; the AGPL applies to far less that 0.24% of all projects and at most 1% of all GPL-family licenses (statistics from Black Duck’s license overview).

Well. So I find fault in much of the characterizations of licenses and license terms in that article, and I haven’t even gotten to the contentious bits yet. I guess the point of the whole article comes down to: Shlomi chooses an MIT/X11 style license because it allows maximum use of the software, and this makes sense because there are plenty of Free Software implementations of the specific technology the license is being applied to.

That’s ok. As copyright holder, you get to choose. And if you want to choose a less restrictive license which allows people to do non-Free things with your code, go ahead. But please don’t frame it as a “war” between different licenses. Because it’s not. It’s a difference in emphasis and a difference in choice by the author about what the author allows other parties to do.

Bad ideas 1 and 3 I can agree with: don’t go proprietary, don’t go custom. That way madness lies. Bad idea 2 — choosing something non-GPL-compatible, is indeed a bad idea, but the explanation is a little fuzzy. Remember, when you run a computer program you are doing so under a specific set of license terms. That means that running program M even under a “GPLv2 or later” kind of grant means you have to pick one (metaphysically) at runtime — and M still cannot mix and match GPLv2-only and GPLv3-only code or components. Keeping your options open — and also the options of people who use your code and who thus must operative within the license that your grant them — is often a good idea.

Bad idea #4 is about referring too loosely to the license of something else; that makes sense as you want a license to be clear and not lead to too much pointer chasing. The only exception I can think of quickly is examples distributed with a piece of software, where something useful may be derived from the examples (eventually).

When we get to bad idea #5 (make it public domain) I’m left confused again; public domain is the situation you end up in when there is no monopoly right on a creative work anymore. Traditionally one disclaimed copyrights and assigned to the public domain (in the US where this is possible). Calling this a license is a bit misleading, and throwing it in as a bad idea when you’ve already discounted the possibility of using public domain much earlier in the article is .. a bad idea in itself. The advice in this bad idea — to use the MIT/X11 license if your interest is primarily in providing the code as a product with as few restrictions as possible — is good advice, though. You make available and do not control what happens with the code. A fine choice!

Naturally (?) I think bad idea #6 (don’t choose the GPL or LGPL) contains some of the worst advice in the entire article. The GPL is one of the few Free Software licenses that has actually been tested in court; it serves as the basis for ongoing enforcement of rights (by people who care about the rights they retain under their licensing within the framework of copyright); while it is full of politics, it is much-studied and therefore relatively well understood. I took a look at the Sleepycat license and can only come to the conclusion: “interesting, I wonder when all those undefined terms will come into play?” License interpretation is best left to the FSF, though, and I’m glad to do so. I wouldn’t use the Sleepycat license, myself.

The conclusion that the GPL is at fault for forcing things to be re-implemented is one built on shaky foundations; we could similarly conclude that it is BSD-style licenses at fault for being incompatible, and indeed if all Free Software licenses were compatible then there would be no issue at all, because you could mix and match regardless of the terms of the license. If the entire Free Software world re-licensed tomorrow to PHK’s Beerware license (he’s Danish, he can probably handle an infinite supply of beer) with no modifications, then .. huzzah! Compatibility and no problem ever needs to be solved twice.

Actually, I’ll challenge the idea that a BSD-style license means that each problem only has to be solved once. Those problems that are solved and then released under the license need to be solved once; related problems that are solved by modified versions might need to be solved multiple times as each implementation goes proprietary. A strong copyleft license ensures that a problem is solved once and derivative problems are also solved once and made available (subject to the terms of the license triggering and requiring source code release). In case of common human decency break glass, release code — that is, most individual developers I know wouldn’t dream of proprietizing BSD-licensed code because it wouldn’t be right, but that isn’t to say that everyone is therefore decent.

So what would I do? Well, after all this disagreeing with Shlomi on the analysis of licenses, on the wording of many things and the examples given, I do agree that MIT/X11 is a sensible license to use — and I have used it on many occasions in writing and releasing my own software. The SQO-OSS project decided on the (2-clause) BSD license, and hence could only use BSD-compatible software; that did mean skipping over some GPL-licensed solutions. And I remember we found other non-standard licenses applied to some useful technology, which we therefore left behind as well. Again: if everything was MIT/X11 licensed, we would have no issues, but differences in the license terms inherently mean that there’s incompatibility possible, and it’s not one side’s fault or the other. I’ve worked on a number of GPL-licensed (both GPLv2+ and GPLv3-only) projects as well; usually not as the initiator of the project, though, and here I respect the choice of the original author that keeping the source available for everybody is a valid choice as well. It’s a choice that I would make when implementing something entirely new — if people want the same functionality but do not want to contribute long-term to the public good, then it is up to them to put in the duplicate effort.

So, 2300 words later, we conclude: reporting on licenses and license terms and legal issues is tricky, because you need to be very careful in the choice of words and aware of the audience. Words like “reverse” should be avoided when presenting court orders to the public, because the colloquial understanding and the legal meaning differ. And when using Free Software from other contributors, be aware of the license; when choosing your own license, be aware that you must choose between relying on good faith or imposing restrictions. I dunno .. maybe next time I should just leave it to the /. commenters.