Bobulate
Home [ade] cookies
Misinformation Tuesdays
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.
Tags: licenses