Bobulate

My newspaper — the NRC — contains an item de uitspraak on page two once a week that deals with some recent court ruling. This week it is a copyright-related item, probably spurred on by last week’s controversy about rights payments on embedded videos on personal websites.

I’ll translate and quote parts of the column here, because it is of interest. This is transformative in nature and thus creates a derived work. Let’s think that this particular derivative work falls under “fair use” (which doesn’t exist as such in Dutch copyright law).

To start off, it’s not actually a copyright item; a 15-year old posted a copyrighted photograph which he had found with image search on his own website. He did this twice. An earlier case awarded the rightsholder (the photographer) EUR 4000 in damages. That seems a bit excessive to me, but .. in any case, the kid did not pay, and now the rightsholder is suing the parents for the same damages.

So this case actually is about claiming damages from parents, in particular because of the responsibility that parents have for the actions of their children. Dutch law says “Responsibility for damages caused to third parties by a child, 14 or 15 years old, lies with those who exercise parental control, except if they cannot be blamed for not preventing the actions (causing the damage) by the child.” Ugh, that’s convoluted, and “parental control” is something called “ouderlijk gezag,” which may be exercised by natural parents or foster parents or in some cases an institution.

According to de uitspraak, the considerations in this case were that a 15-year old has a reasonable expectation of autonomy and that non-stop surveillance is not to be expected (heck, I don’t watch non-stop over my kids when they’re surfing, and they are 5 and 6 — but then I do try to start them in a safe place of the net). So letting kids do “stuff” on the net is not a reason in itself a reason to expect surveillance. The judge also states that it need not be considered unusual for kids to maintain a website. As a result the parents are not held responsible for the damages.

Note that this says nothing about the damages awarded earlier: presumably the kid still owes 4k from the original case. It does, however, say something about where parental oversight is expected for kids doing things on the net.

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

I’ve said it before, the devil is in the details. Last week the European Commission, by way of its Commissioner for Competition Policy Neelie Kroes, decided to accept a test proposal from Microsoft regarding the browser selection on its Windows operating system. Incidentally, the Register has a more readable form of the same thing.

Now, Karsten Gerloff, president of the FSFE, has written a good overview of what is wrong with the proposal. Basically, all the details are wrong. You can also find some comments by Carlo Piana on the subject.

Let me summarize: the browsers are not all shipped in the same state — there is one special pre-installed one — and the mechanism for choosing browsers is not flexible enough. It’s still not clear what the presentation order will be, which may skew the selection as well. I’ll say one good thing, and that is that there’s space for 12 browsers in the browser selection screen (umm .. no technical reason to limit it like that if the selector is a webpage, or anything else really). The big five plus space for specialized or less popular ones. It’s not clear what the criteria are there. Still, one might imagine a whole family of WebKit-based browsers being included.

While I was having a weekend meeting — over a week ago now in Frankfurt — there was FrOSCon going on just one or two ICE stops down the line. The overall programme seems (seemed?) pretty interesting, and Michael had a good time (you mean Rainer will let people try to drive his car!?), but there seems to have been very little report out of the conference.

From a research point of view (i.e. the hat I put down when I left the university) I’m somewhat curious about the PHP Quality Assurance Tools and The State of Test in Open Source talks. Writing enough tests is always tough, unless the culture of a project really encourages it; that’s basically where discipline and a desire to write the very best code have to win out over “let’s get it out there quick.” (Note that this is a use of “Open Source” that I’m not going to complain about: it’s about a development model which offers source for viewing — which enables the creation of tests, but does not necessarily enable any of the other Freedoms.) Of course, within a quality measurement framework (yes, I’m talking about the EBN which is in dire need of some hobby-time love from me) processing large amounts of data is important, so I suppose large scale analysis tools would be interesting as well.

Turning to legal issues (my work hat), I’m pleased to see a Free Software conference with an explicit legal track. One of the more interesting talks (from a licensing perspective) wasn’t filed under legal, though: Freie Software und SaaS, which seems to have talked about the AGPL. That’s interesting because the AGPL tries to close the “distribution” loophole in the GPL — for those authors who feel that that is a loophole that they do not want their code to pass through. Patents and e-mail regulation show up in the legal track as well — remember that business communication needs to be stored and tracked. The most intriguing talk of them all is the Opensource in der Praxis talk, where Open Source as a term is used badly, but let’s let that go.

I’ve got to admire a talk with slides made in TeX. Absolutely.

Unfortunately, my German isn’t good enough to construct a coherent talk based on just the slides, and the talk seems to have touched on a couple of potential issues when it comes to the applicability of Free Software licenses in Germany; that’s a topic I like to think is well-understood, so I’m curious if anyone who attended the talk can give me a summary — or put me in touch with the author (yay lazyweb!).

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.

The Freedom Task Force is a project of the Free Software Foundation Europe that:

… help[s] people understand Free Software licensing and the opportunities it presents. The FTF offers educational services, facilitates infrastructure activities and manages FSFE’s legal affairs. Its work focuses on the promotion of the proper use of Free Software.

“Proper” use here refers to license compliance; Free Software is, after all, free to use for any purpose. I’ve created a new category in my own blog to file FTF-specific entries (as opposed to, say, KDE-Solaris specific, or just bla-bla). Still, blog entries in that category shouldn’t be considered official pronouncements of the project — there are other avenues for that.

It strikes me as a little odd that the things I do all day are harder to write about than an hour of mucking about that I do late at night. I have something about Qt font rendering on Solaris lined up, and a bit on getting SRSS on OpenSolaris (summary: read the manual) and then I can finally post screenies related to SRSS work done at GCDS — but that is definitely hobby. Daily things are maintaining the FTF website (where I still have to get used to the workflow), list maintainence, and I’m reading a lot of documentation left to me by Shane Coughlan, the previous FTF-coordinator. It’s hard to do a daily item on that kind of work, because it does happen largely in the background. The legal work that the FTF does has a fairly long incubation time. Once it’s done, then you can see, for instance our GPL violations reporting guide (even if it’s short, it takes time to work these things out). Unlike a Free Software project, the process is largely invisible.

Transparency is an interesting beast. At GCDS I spoke with some who would put every person’s medical history (in some open format) in a publicly accessible place; I spoke to others with a strong security and privacy background who would find that a tremendously bad idea. Openness can be used well, or abused — Glyn Moody has a pointer to an interesting project building on the open data provided by a government. There are actually interesting legal topics around combining public domain data and freely-licensed content; this is similar to the old difference between the BSD license family (where widespread use is the most important) and the GPL license family (where maintaining freedom is primary), and something I hope the FTF can look at in future. My point? There’s a huge range of opinions on what constitutes healthy transparency, and I can live with both a terribly open project and one where the process is hidden and the results open. So forgive me if FTF news is infrequent — there’s enough going on.