Bobulate

Spurred by Henrik’s comment on FSCONS (and I intend to go to FSCONS to talk about licensing, but need to get that together), I thought I’d post an update on some conferences.

I’ll be at ELCE later this week to talk about licensing compatibility (and possibly machine architecture). I’m looking forward to it, because the embedded and mobile industry is one that mostly “gets it” when it comes to Free Software (it’s also the source of most violations). I’m honoured to be on a conference programme with so many real hackers, and looking forward to hearing about non-x86 architectures in particular.

Later this month, the NLUUG conference on the Open Web will be held in Ede, the Netherlands. Support for openness — in all the meanings of open standards, open access, open content — is still of growing importance. You can find me at that conference with my green and purple hats on (FSFE and NLUUG). Arnoud Engelfriet will be providing the legal and licensing angle at that conference (speaking of whom, I was very surprised to see him on TV a week or two ago explaining about copyright and how it was possible to download things without violating copyrights).

If you don’t want the Open Web, you might want to go to Linux Kongress, 600km to the east. You can attend a talk about Ede, though. From my point of view, though, the most interesting talk is probably about Open Source ERP (I wonder about that, actually, since the OEPL looks like it is a restrictive license that will probably fail the Free Software criteria and might fail the Open Source Initiative criteria — but this is not the spot for lengthy license examination). My interest there is sparked (if I can call it that) by the relative lack of Free Software in that space. It is apparently neither an itch that people want to scratch, nor a market where business has found a way to work with Free Software in its business model. At least, that’s the impression I got from OpenExpo two weeks ago, and I’d be happy to be shown otherwise.

The Free Software Foundation Europe (FSFE) has got an infestation of interns. Under Matthias Kirschner’s lead, they should be blogging and denting away — as well as getting actual work done instead of exchanging witty banter on IM networks. Welcome to Hugo and Lena. If you look closely you can see the current chaotic status of the new FSFE office in Berlin with, as Lena puts it, wires all over the place and no comfy chairs. Maybe you need to be staff to have a comfy chair, eh.

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

The Free Software Foundation Europe (FSFE) is an organization that does a lot of behind-the-scenes things, mostly policy and legal, which can be a little hard to see at times. Of course we are always happy to support Free Software projects manage the legal and organizational aspects of, um, projecthood — that means supporting copyright consolidation (or supporting copyright management, don’t let me suggest that consolidation is necessary in all situations), asset management (as a project you have a domain and a name and possibly a brand and trademark, make sure those are protected), and other fiddly bits that aren’t everyone’s cup of tea.

After all, in the long list of contributors to Free Software projects: artist, translator, coder, writer, supporter, forumista you rarely see “legal” except when it comes to the largest of projects. As a consequence, the FSFE’s work is often a little bit hidden. The FSFE newsletter (under the general news part of the site) gives a view of what the association is doing in an official capacity.

The human face of the FSFE — the people behind it, as it were — are members of the Fellowship of FSFE, supporting the work of the FSFE financially as well as organizationally (e.g. booths) and doing fun stuff at the same time (e.g. fellowship meetings, get-togethers of Free Software people who work on different projects, different places). Some of the Fellowship groups are not all that active — here in the Netherlands we’re largely dormant, even though we live fairly close together and I even think we could agree on a pub to meet at.

There is an interview series with Fellows — Smári McCarthy, Timo Jyrinki, Myriam Schweingruber are the last three — that illustrates really well the range of people involved in Free Software across Europe.

The person who does most (all?) of the interviews is Stian Rødven Eide, who can’t exacly interview himself to talk about the cool things he does, so I’ll just point to his own blog and in particular the entry on Gnutiken, the Free Software boutique. Basically a cafe that caters to the Free Software crowd, it seems, with a hardware and consulting business co-located. I hope that’s a good description, anyway.

This kind of boutique strikes me as a kind of ideal sprint location, bringing together a relaxed atmosphere with fanatical devotion to results. I used to fantasize about buying an orchard in the middle of Sweden and converting it to a campground / chalet-huts area for Free Software development, hacking and relaxation, but that never went farther than surfing some real-estate sites. There’s the Linux Hotel which can provide that. Most of the sprints I have been to — KDE sprints, that is — were short, just a (long) weekend, and I wonder what would be achieved if we could hold a group together for an entire week, working not only on new features but also putting concrete effort into “papercuts” type fixes and stability improvements.

Anyway, the human face of FSFE: the fellows. See the Berlin group on the 10th of September, Wien or Helsinki or one of the other groups — or start one up yourself. Heck, I’m going to have to arrange something in the Netherlands now. How does October 28th sound?

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.

As noted elsewhere (for instance Ars Technica or OsNews or the EU itself) the European Commission has reached a conclusion with Microsoft about Internet browser choice for consumers. The proposed remedy is a browser ballot, from which users of new (and possibly also old) installations of the Windows operating system will be able to select a browser to use.

The devil is, of course, in the details, and the Free Software Foundation Europe is on the case. The (well, one) thing to watch out for is freezing the browser market in much the same way that it is now; that is, suppose the browser ballot says “Arora, Firefox, IE, Opera” then we have replaced a monopoly by an oligarchy and continue to frustrate innovation and choice on the desktop. So details include questions like “how do we determine which browsers are on the ballot at any given time?” That ties in to the dynamic nature of the browser market (well, that part outside of the monopoly) where new versions are released regularly and there’s a whole forest of Free Software alternatives to the “Big Three” (IE, FF, SafOpera). Designing a ballot that prevents leveraging the existing monopoly position is another issue — of the big three browsers, only one has the word “Internet” in the name, which may skew the ballot.

So the coming months have an interesting mix of social and technical work upcoming in order to provide a remedy that is, in fact, a remedy and not a placebo. The FSFE will continue to follow the case and press for Freedom in browser selection, and supports fair access, competition and innovation in the browser market.

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.

Today closes out my first week of working “for” the Free Software Foundation Europe; the word “for” is in quotes because there is still some formalization left to do. Still, the FSFE — and more particularly the Freedom Task Force — is what occupies my time during the week. In terms of response times, that means I’m on call for FTF things during working hours in western Europe. “FTF things” includes planning and executing educational services around Free Software licensing, facilitating infrastructure activities and managing FSFE’s legal affairs; as a whole this is aimed at the promotion of proper use of Free Software.

At the same time, this has an effect on the other Free Software work that I do. My day job is the FSFE, and KDE issues (primarily the OpenSolaris porting work) are going to move more strongly to the evening hours, something like 9-11pm. So do not necessarily expect responses to KDE things, especially bug reports or requests for testing, during the day or while I’m traveling on business. It’s just so easy to get distracted by, say, fiddling around with Qt creator. KDE legal affairs may be compatible with business hours, depending on the topic. What I really need is a green, a purple and a blue hat to indicate what thing I’m working on at any given moment. Maybe I should file a feature request for KMail, disallowing access to certain mail folders during the work day; that would help enforce discipline for me quite a bit.

This first working week was mostly filled with the IFOSSLR launch in London; the journal is independent, but the FTF is keenly interested in high-quality legal opinion on topics around Free Software. I think this is the beginning of a beautiful friendship.

There’s a new legal journal out, and it is all about (and by) us. “Us” in the wide sense of the word, those people that are concerned with legal issues around Free Software communities, projects, organizations. You can find it on boing boing as well, where Andrew Katz, one of the editorial team, is quoted as “even lawyers can adopt a collaborative model and create something both free as in freedom, and as in beer.” This collaboration is in part thanks to the Freedom Task Force of the Free Software Foundation Europe, which has created a neutral ground for exactly this kind of collaboration and sparring around Free Software law questions. You’ll see that positive, constructive dialogue is our main weapon.

If you were to look in the journal, you’d find a piece by me commenting on some topics that were active in march and april, basically a blog on paper. I like it that way, and I feel my role both as a columnist for that journal and within the FTF as a whole is to push the technical and community aspects. In other words, make sure that the topics that are relevant in Free Software communities are taken up by the legal experts that write for the journal. In the meantime, I’m learning about the practice and interpretation of law. It’s fun to get lost in the twisty passages of esoteric interpretations of licenses, but far more useful in the medium term to provide services aimed at projects and businesses involved with Free Software. The journal, I think, provides a means to communicate interpretations of the law to all involved — also people in the projects, not on the bench.

One might get one’s knickers in a knot over the title of the journal, which contains either a redundancy (Open Source software is Free Software, and there’s no need to expand upon Free Software) or is missing several additional terms like Libre and Liberal. I like the latter, but that’s because the opening keynote of GCDS was by Robert Lefkowitz; it was a wonderful display of showmanship and rhetorical skill. The upshot of the talk was that we use Free Software because we are lawyers (or pretend to talk to them) and gentlemen.

So be it. I will go find my monocle and take the first train to London, there to consult with Sherlock Holmes on the case of the licentious liberal.

The Fiduciary License Agreement (FLA) between KDE contributors and KDE e.V. is one that assigns those assignable rights derived from authorship from the original author to the fiduciary (i.e. KDE e.V.) and then assigns, non-exclusively, the rights on that work to (0) use, (1) study, (2) modify, (3) distribute and (4) authorize third-parties for the same, back to the original author.

Ugh, that’s a lot of legalese, but that is also why my slogan for the KDE project is “I talk to lawyers so you don’t have to.” It’s a wonderful thing that Sebas has been talking to KDE contributors at LinuxTag and has obtained a number of signed FLA documents. That means that a good chunk of important KDE code is now actually owned — in the sense of copyright — by KDE e.V. Sebas quotes our friend Carlo Piana (he received the pineapple fortune cookie award for Coolest Lawyer, once) describing an FLA as follows:

The fiduciary licence aims at simplifying this process, by assigning the copyright to an entity as KDE e.V. which is not “scalable” and therefore provides sufficient safeguards as to the possible hijacking of the project for nefarious reasons.

Now, I’m not entirely sure about that “scalable” there. KDE e.V. is scalable, in the sense that with individual donations and supporting members we have the resources to support the growing developer and contributor communities as well as serve users in general though efforts like UserBase. I think what Carlo meant is “saleable”, in the sense of “you can’t buy a community.” I’ll have to ask him, next time we meet.

So you can’t buy a community and you can’t buy a non-profit association with strong checks and balances in its constitution. This is good, and having a strong copyleft Free Software license applied to the software as well ensures its long-term availability (don’t let that link fool you, though: the KDE platform libraries are LGPL licensed, so you can, if you really feel it is necessary, write proprietary applications on top of it — but consult your local counsel for license advice). The main issue that the FLA tries to solve is really one of license and responsibility fragmentation.

When multiple authors work on something, then each author has a share of the copyright on the creative work — at least, each author who contributes something original and creative enough to be considered a creative work. This leads to multiple authors and the requirement to agree on copyright matters between all the authors in a particular work. This fragmentation can consume considerable resources if ever there is a particular need to deal with all the rightsholders for one particular work.

Note that KDE contributors — all of them — have traditionally been rather lax in maintaining the copyright headers in our sources. We do not maintain a comprehensive list of authors in each file, nor do we follow GPLv3 article 5.a very well, in general. Figuring out exactly when 5.a applies is something I’ll leave for the real lawyers and another blog post. In any case, a consequence of the signing of the FLA’s by a number of authors is that for their work the copyright header should be changed to

Copyright [years] KDE e.V. <kde-licensing@kde.org>

Ideally we would include a postal address (of KDE e.V.) as well; the whole point of this exercise is to make it really darn clear who to contact for licensing information and to make sure that we clearly claim the copyright on these files.

Note also that the KDE licensing policy is lacking in some details and allows poor licensing hygiene by potentially mixing incompatible licenses: we have had license checks (Tom Albers has now and in the past been instrumental in moving that forward). Just because we’re not doing things optimally now doesn’t mean we can’t move forward and improve things (this applies in many fields of endeavour).

The FLA used by KDE e.V. has a big blank where you can fill in which works are covered by the FLA. There is also a pre-filled form (PDF, 50kB) which identifies the works using standard language referring to your SVN account name. That should make filling things in easier. If you didn’t sign up at LinuxTag, you could print that, fill it in, and mail the form to the KDE e.V. office. We maintain a list of signed FLA’s as well, to keep track of who has done so — let me emphasize that the signing of an FLA is optional and the choice to do so rests entirely with the individual whose creative work is covered (or would be covered) by such an FLA.

So, by concentrating the copyrights held we reduce fragmentation; given that we have a strong basis to build on with careful checks and balances in the consitution of KDE e.V., this is an improvement for the currently-hypothetical case that we would want to (or have to) relicense large parts of KDE to some other Free Software licence.

There are additional checks placed on any relicensing attempt on the part of KDE e.V. They were added as a sort of backup guarantee that KDE e.V. cannot do evil in relicensing code. However, at the same time these relicensing restrictions (written down in the Fiduciary Relicensing Policy) reduce the effectiveness of the FLA itself, because the FRP says that we at least have to try to get permission from the original author before relicensing. However, it does mean that we get to judge “reasonable effort” ourselves instead of letting someone else do it. So in the end we (as in KDE e.V., representing the KDE community as a whole) do have a stronger grasp of the code in order to be able to defend it if needed.

And, since the rights are transferred back in a non-exclusive license to the original author, the original author may fork or relicense if that’s really absolutely necessary. I should point out that that should be a real last resort and that working with the rightsholder (i.e. KDE e.V.) should be preferred. Remember, KDE e.V. exists to support (“we exist only to serve”) the development of KDE software, including the KDE workspace, KDE platform, and KDE applications. If there is some perceived need to fork, then somewhere there’s a misunderstanding of what the constitutional aims of the association are.

But I digress. There is an FLA, and it is signed by many people. Perhaps many more will do so at Akademy this year.

So where do we go from here? Maybe next weekend, we can take over the world.

The answer to this question actually depends on which hat I’m wearing. The KDE hat says: continue to consolidate licensing, pursue license checking and accuracy across the entire codebase and behave as an exemplary community software project with regards to legal matters.

My FSFE hat says that we need to take the concrete experience with KDE and with Bacula and introduce other projects in Europe and the rest of the world to this kind of lightweight legal housekeeping. The FLA has been translated into many languages, but I feel that having used it in KDE it could use a little extra precision. Also, any legal document intended for use by non-lawyers probably needs an implementation guide and HOWTO. And most importantly, those need to be well-known to projects who might need such documentation.