On Copyright Assignment

A little while back, Michael Meeks published a lengthy piece about copyright assignment (not nearly as lengthy as the articles he links to on untangling Wittgenstein’s net). Go on, read it (Michael’s stuff, not the net). It’s worth your time. When you get to the bottom, follow the link to Dave Neary’s take on assignment as well.

I’m going to take the time to respond to Michael and Dave with two different hats on: my FSFE hat (work-work, where I do legal and licensing stuff in the Freedom Task Force) and my KDE hat (volunteer work, where I have hacked on various bits and pieces for over a decade). This isn’t an entirely independent article on assignment, but looks at their comments on it. First off: there’s no right answer. Just like I say during my licensing talks at conferences: it (licensing or copyright assignment) is a choice that needs to be made, and that choice needs to be compatible with your goals, your morals, your business needs (if any), your sense of community (if any) and your desire to deal with administrative details.

One or two points of fact, though: the FSF does not require assignment — not for all GNU projects, at least. For some, yes. I made this exact same mistake at the GNU hacker’s meeting in Gothenburg last month. After all, it’s easy to find articles stating that the FSF requires assignment — even on the FSF site — and not so easy to find ones that do not. After all, it’s hard to search for the absence of a document. Andy Wingo can probably point out some.

Qt is still subject to a contributor agreement, but it is not a copyright assignment, but rather a license — in other words, the original author retains the copyright but grants the Qt organization (that is, Nokia Oy) a very broad copyright license (including sublicensing) and a patent license (for patents covered by the contribution). There’s some pretend remuneration. There’s little in the way of protection offered to the contributor, but I think it would take some far-fetched scenarios to find a patent danger in there (but do comment on their existence).

Michael’s examination of assignment forms (including Sun’s SCA) is missing one form that is used in Europe (and elsewhere), and that is FSFE’s Fiduciary License Agreement (FLA). This is a copyright assignment form — no patents involved, which makes some sense because there’s no software patents as such in Europe — that assigns those assignable rights to a Fiduciary, and then licenses those rights back. The assignable rights vary a little by jurisdiction (and Europe has lots of them), so that makes the form a little bit longer than it might otherwise be. In addition, there are variations as to whether you can assign future work or not — things like that.

(1) Subject to the provision of § 2, Beneficiary assigns to FSFE the Copyright in computer programs and other copyrightable material world-wide, or in countries where such an assignment is not possible, grants an exclusive licence, including, inter alia:

Here the FSFE is the Fiduciary. The Fiduciary is a party you trust to handle the copyright responsibly. By default you own the copyright — and I assume you trust yourself to do the right thing with licensing on the work you do for yourself — and the rights (most of them, anyway) are assigned to your estate. Presumably you trust your executors to do the right thing as well.

That actually leads into one of the reasons that you might want to think about copyright assignment — or at least about what happens with your code and the rights to your code when you’re no longer actively involved with the Free Software projects you contribute to. It happens — people drop out, no longer want to participate, or indeed pass away. Copyright assignment is one way to manage the risk (and possibly administrative burden) attached to something long-lasting like copyright.

Back to the FLA: the effect of clause 1 is that the Fiduciary gets control over the rights to display, reproduce, distribute, create modified or derived works and to allow third parties to do so. While re-licensing isn’t explicitly in there, the authorization to third parties implies it. There needs to be an exclusive license so that the Fiduciary knows they are the one party who may act as if they hold the rights. So once the Fiduciary has the rights, what happens?

(2) FSFE grants to Beneficiary a non-exclusive, worldwide, perpetual and unrestricted licence in the Software. This right’s [and licence’s] scope shall encompass and include all the rights [and licences] specified in § 1. Furthermore, FSFE grants to Beneficiary additional nonexclusive, transferable license to use, reproduce, redistribute and make available the Software as needed for releases of the Software under other licences. This re-transfer shall not limit the scope of FSFE’s exclusive licence in the Software and FSFE’s rights pursuant to §1.

You get it all back and can continue to license, sublicense, modify, etc. the work. In other words, you can continue to behave almost as if it were still your copyright. This is important because the Fiduciary wants to support the use of the software as much as possible. So you’re even free to create a derivative work and make it available under another license. I have not considered whether it would be possible to release it under a proprietary license — there might be some tricky interactions between the assignment and the re-assignment.

This FSFE FLA is available under a license that allows modification, so you can take the FLA and modify it for your own purposes. KDE has done so. The KDE FLA adds some restrictions to what the Fiduciary is allowed to do in terms of relicensing, but these clauses were added after some lengthy deliberation.

In any case, an FLA is an adaptable mechanism for assigning copyright to a Fiduciary — some party you trust. Just having the tool available doesn’t mean much, though: there are issues of policy as well. To return to the beginning: some projects / organizations have a policy of requiring assignment (though some instrument). Others do not. KDE is unusual in that it makes it possible to assign copyright to the organization, but does not require contributors to do so.

So let’s carry on with Michael’s comments.

To whom are you assigning it? This is a very important question — because you need to trust the fiduciary. Michael points out that a non-profit (association or foundation, with a constitution written to support particular goals) is probably a better Fiduciary than a corporation. The reason for that is relatively straightforward: money. You can buy a company, buying a non-profit is much more difficult. Not impossible, mind you. The FSFE acts as Fiduciary for a few projects. KDE e.V. acts for its own project. When asked, I tend to advise finding an existing trusted party (like FSFE or KDE e.V. or perhaps the Linux Foundation) who is willing to act as Fiduciary (FSFE takes it case-by-case, KDE e.V. is probably most interested in KDE-technology related projects, and I can’t speak for the Linux Foundation but they strike me as a potential partner). Setting up your own organization is possible, but has some costs. Those are costs in filing and administration, in setting up meetings, and providing long-term viability to the organization.

An assignment document should have an escape clause if the Fiduciary turns out not to be faithful (fides is Latin for faithful, more-or-less). The FSFE assignment has such a termination (or auto-revert) clause. So does the KDE one. So does the FSF’s assignment. Michael points out a few others, and such a clause should be seen as an additional form of risk-mitigation

Benefits and risks: Note well that “single owner” and “re-licensing” are listed as both a benefit and a risk. Which is as it should be: a single copyright holder also means a single point of failure (in terms of a take-over) while multiple holders means many points of failure (in terms of necessary re-licensing or negotiation). But a single copyright holder means success because it can manage negotiations, sublicensing, re-licensing and assets (in the sense of “your software has value to its users” even if not monetized) and multiple copyright holders is a success because of its resilience in the face of take-overs and flexibility in accomodating different viewpoints.

Again, it depends on what you think is most important and how you weigh the risks. I like the KDE e.V. approach with a non-profit association that holds a fair amount of the rights — but nowhere near all of them, on any part of the code — and then multiple individual (and corporate) rightsholders. That makes it both resilient and possible to go to court saying “we (KDE e.V.) represent a 30% stake in the copyright in this work”.

That last item relates to “defending the code.” There simply haven’t been enough cases of license enforcement to say whether a centralized copyright holder is useful or not. Harald (through gpl-violations.org) is very successful in enforcement in Europe, but he has rights (including assigned copyright!) to some well-defined and popular pieces of the Linux kernel which are fairly easy to detect. Besides which, not every developer wants to get involved in this stuff, so it might be difficult to find any individual developer to enter into a copyright enforcement suit.

On re-licensing I would add that “license tourism” by a Fiduciary should be avoided, perhaps by wording in the FLA, perhaps in the constitution of the Fiduciary. You don’t want to start with (say) the GPL and end up with the code under something totallylargely incompatible (Artistic). So once again: you need to trust the Fiduciary and set up some policy to make sure it all works.

Barriers to entry: This is, in fact, a biggie. It depends on the community creating the software whether asking or requiring assignment will be a barrier or not. I can imagine that in an established loosely-knit community of individual developers (read: the KDE community) introducing assignment is both scary and seen as a barrier to entry. That’s why you could choose the optional-assignment route, for partial centralization. In a corporate led project, assignment may be much less of a barrier. In mixed settings, I think optional-assignment or a really darn good explanation is needed (an explanation that I won’t be able to provide here, as it depends very much on individual circumstance).

Dave writes very briefly: he refers to assignment as a “superfluous barrier to entry”. I disagree with that — it can be superfluous, or, given explanation and circumstances, can be quite necessary. For a project with a community of individuals with no monetization of the software itself planned and an established brand and a broad scope (e.g. desktop projects) it probably is the former.

It’s at this point — in listing items under barriers to entry — that I feel Michael is lacking clarity. There’s a number of problems listed, in the moral, social and organizational spheres, all of which may influence the influx of contributions and affect user uptake of the software. However, I don’t see how these are specific to copyright assignment. When thinking of participating in a project, “the paralysis of uncertainty” can strike for any of a number of reasons. Licensing? Trademarks? Maybe the project is run by complete jerks only I haven’t realized it yet? Perhaps Mr. Knightly does feel affection for Jane Fairfax, and merely dissembles to poor Harriet Smith as a cover? [Sorry, I’ve been reading Jane Austen’s Emma and it will lead to any number of conspiracy theories.] The same applies to corporate unwillingness and scarcity: these are not issues that are particularly brought to a head by copyright assignment, but always exist in open collaborative projects.

The “death of trust” (gosh, isn’t that a melodramatic title) touches on two issues: the trust expressed (or lack thereof) by demanding an agreement beforehand and the issue of recognition when rights have been assigned. The former can be a real barrier to entry — but that was Dave’s point. The latter is easy to deal with, and indeed should be dealt with, by identifying individuals where that makes sense. For instance, my contributions to KPilot (since deceased) should be administered like so in the copyright header in the source files:

Copyright [year] KDE e.V. [contact email]
Author: Adriaan de Groot

The reason for still listing individual authors even after assignment is because of moral rights — pesky non-assignable, non-transferrable, non-heritable (I think) rights. Plus, it’s a means of giving recognition (if so desired) while correctly stating where the copyright (or exploitation rights) resides.

Carrying on to the end — from here until the Recommendations at the end of Michael’s piece I have trouble understanding what the problem is, unless it’s “do not assignments to untrusted parties who have an incentive to proprietize” — we find the Recommendations. Sensible recommendations, by and large. I especially appreciate the suggestion of a proxy for approving license updates — I had not seen that before. But all in all, it comes down to a very old Dilbert punchline: “try identifying the problem, then solving it.” That means considering the role you play (contributor, manager) and the style of contributions to the software and intentions for future growth.

On removing GPL code

Last week, Diego Iastrubni asked removing GPL code, prompted by MonoDevelop’s announcement that it had removed all the GPL code in its codebase, thus opening the road to proprietary plugins.

Well Diego, there’s an app organization for that. Depending on your jurisdiction, you could ask the Free Software Foundation in the United States, the Free Software Foundation Europe in Europe, the Free Software Foundation Latin America in Latin America (are you seeing a pattern here?). The FSF in the United States is the steward of the GPL (all versions) and the organization in charge of interpreting the intent of the GPL. Of course, certain matters on interpretation will end up in courts — because it is not only about the intent of the license, but also what it actually says.

There are also national centres of competence regarding licensing issues and the use of Free Software. In Finland you might want to ask COSS; in Spain, CENATIC or ASOLIF; in the Netherlands, NOiV; in the United States, the Linux Foundation. Any of those might be able to help out with this kind of question. I won’t pretend that they definitely will: it depends on the context and workload and whether the question makes sense in their context.

Fortunately, an organization like FSFE has education and information provision written into its constitution (but not its budget: support the FSFE to help it continue to help you and the rest of the Free Software world). So here’s an attempt at an answer — which does not constitute legal advice and which does not constitute an interpretation of the GPL.

So let’s follow through Diego’s question:

I have this application which I license under the terms of BSD, and I saw a GPL library (lets call it libbar ) which might help me. I incorporate the library by dinamic linking. Now my application is effectly a GPL binary, sweet.

It is vitally important to distinguish between source and object forms of the software here, as well as keeping track of mechanisms of linking. Let’s try to strip this down to a bare minimum number of components. A program A written entirely by you using no external (third-party) components and released by you under the terms of the 2-clause BSD license. That’s fine. Now suppose you modify your application to use an interface provided by a GPL library (like libbar, in Diego’s example). Does that make your program a work that must be licensed under the GPL? Maybe. Does that make the object form of the program linked to GNU readline a work that can only be distributed under the terms of the GPL? Yes. So you must ship the object with the text of the GPL, with a source code offer (either the complete source or a written offer, as usual). Still, the sources retain the license that you originally put on them (BSD 2-clause, which is GPL-compatible, so this is possible).

Now you replace libbar (the GPL library) with a newly written, 2-clause BSD-licensed, libbar_bsd. It might implement the same API as libbar, or it might implement a slightly different one and you modify your application A accordingly. Does that change the licensing possibilities that you have? Yes. you can release A under the 2-clause BSD license — again, keeping in mind other obligations you might have. If you were forced to re-license the source under the GPL (see Maybe, above), then there may be issues. If you are the sole copyright holder, then of course you can re-license. But you need to double-check any contributions you may have received to the codebase. With the new A, you can release object versions including libbar_bsd, under the 2-clause BSD license.

Lets assume, my application uses (derives classes, whatever) code from libbar. If I remove the GPL code and change it by BSD code – my work even though it does not contain GPL code – it’s a derived work, due to compile time constrains. Am I correct?

I think this scenario has two different interpretations: if A uses functions from the library then — like I said previously — the object is definitely GPL licensed and the source might need to be. But if you actually have derived classes and modified code from libbar, then it’s going to be a great deal more difficult, because your source is in itself a derived work. I’m not sure how to understand the “remove the GPL code” here: if there is no GPL source code in the application and it doesn’t link to any GPL libraries in object form then there’s no reason that the GPL need apply.

Let’s look at Diego’s other scenario:

Lets assume that libbar, uses abstract classes/methods from libfoo (which is BSD). Lets assume that my application uses the interfaces exposed in libfoo, then libbar extends those interfaces, and I am not directly using libbar. When I use my new BSD library, my application is not compiled against any GPL code (just linked to) and it never used it directly. My old code was GPL by run-time constrains and, and the new one is BSD. Am I correct?

In this scenario, application A uses libfoo (presumably unrelated, although it apparently provides functionality to libbar), so there’s no GPL code involved at all. The parenthetical comment “(just linked to)” I don’t understand: why would the application A link to libbar at all if it doesn’t use it and libbar is en independent development?

So that leaves us with that dreaded “Maybe” from earlier. Paul Pacheco commented on Diego’s blog with exactly the right bits of the GPL — the trailer to clause 2 of the GPLv2; GPLv3 doesn’t have the same language. But perhaps even more important, the GPLv2 says:

Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

In other words, distributing your work which is both an identifiable part of the whole work and which is not derived from the GPL library (and I’ll claim that using an interface is not in itself sufficient to create a derivative work), then the source continues to be licensable however you like, but the object must be distributed under the GPL. The sources you provide that correspond to that object form must be distributed under the terms of the GPL — strange but true.

Understanding Licenses, bit by bit (4)

It took a little while, but I wrapped up the licenses-as-icons with a summary in tabular form. It’s not on this blog, because I don’t know how to pull in fancy CSS and tables into wordpress. Instead, it lives on one of my personal sites for now. It will move to the FSFE pages in due course, once I’ve had some of the other people in the Freedom Task Force look over it. The page is largely auto-generated now by a little python program that understands the labels given to the different licenses. There is plenty of room for improvement: links to the license texts, better explanations of what the badges mean, etc.

One thing I’m quite happy with is the family overview: it shows which licenses are the same when compared using only the qualities reflected in the badges. So it shows MIT and BSD 2-clause as the same — which I’m willing to accept. Unfortunately, due to the granularity of the badges, it also shows some things together (or at least indistinguishable based on the badges) that do not belong together.

There’s one badge missing: “allows relicensing”, which would for instance distinguish between OSL and AFL (as I pointed out when reading them previously). And it might make sense for every license that gets a warning marker to be excluded from the family groupings entirely, so as to avoid the possibility of confusion there.

Thanks: I’d like to thank Mignon Engel and Egon Elbre for providing icons that can be used to symbolize the different badges. You can switch between the different style sheets in your browser’s View menu (unless you’ve got Safari, which doesn’t support that feature as far as I can tell).

Copyright: Some folks have asked about the license on the icons, the text, these blog entries. Since this is work I do as part of my job for the FSFE, it is copyrighted by my employer — the Free Software Foundation Europe (an independent sister organization representing Free Software in Europe). Most of the materials produced by the FSFE are released under a liberal license, for instance allowing unlimited verbatim copies as long as the copyright notice is preserved (otherwise it wouldn’t be verbatim, right?). However, this material hasn’t been licensed that way yet, so I’d have to answer that right now, it’s “All Rights Reserved.”

Next Steps: Refine the meaning of the badges. Add a relicensing badge. Add another dozen licenses (for instance there’s no Affero versions here yet). Clean up the text. Turn it into a nice booklet. Publish. …? Profit!

Understanding licenses, bit by bit (2)

Thanks to all those who commented on my recent proposal to “iconify” licenses. That is, representing the essential terms of various Free Software licenses as icons so you can quickly get a feel for their meaning. This is, in the current state of software licensing, no replacement for actually reading and understanding the licenses, but as a mechanism for quick (as opposed to deep) understanding it seems to work well enough.

network copyleftComputerDruid pointed out that we’d need an icon for the network-copyleft effect of the Affero-style licenses (AGPLv2 and AGPLv3). The salient point of the GNU Affero General Public Licenses is that the requirement to distribute source is also triggered by interacting with the program over a network. The license text has an addition (in version 3) to clause 13:

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network … an opportunity to receive the Corresponding Source of your version …

None of the licenses examined so far has such a clause, so that’s why I hadn’t drawn one up yet.

The “Free Software” icon is the only one that grants permissions. It says “this license grants you the Four Freedoms”. The other icons all describe conditions on the license. Copyleft, network effect. The patent grant is both a permission outside the scope of copyright, as well as a condition related to downstream use of those patents and your own patent rights (if any) in the program (in those jurisdictions where there are software patents). In this sense, fewer icons means fewer conditions, and hence more free to use — but at the cost of not guaranteeing the Four Freedoms downstream, for the most part. Compare, for instance:

  • free softwareThis program is Free Software; you have at least the Four Freedoms, but copyright notices must be preserved and the license text distributed with the program.
  • free softwareprovide sourcestrong copyleftnetwork copyleftpatentThis program is Free Software; you have at least the Four Freedoms, but copyright notices must be preserved and the license text distributed with the program. In addition, you are required to provide source (under some circumstances). The source provision applies to your own code as well that is added to the program (strong copyleft). The source provision applies also if you provide access to the program over a network (Affero). There is an explicit patent grant involved.

Whoo. That’s quite some text, but still a great deal shorter than the GPLv3.

Paul Boddie points out that the “weak copyleft” symbol is probably redundant (I agree). That would make the number of source-related icons three (and the number of the counting shall be three). There would be “provide source” (i.e. weak-copyleft), and then two modifying icons for strong and network copyleft. I like it — something to take into account in the wrap-up to this series.

See, by now we’re almost getting into a grammar of these things, which is something I would like to avoid. Keep it simple, keep an overview that allows selection and understanding at a high level, and then look at the relevant license texts in detail.

free softwaresourcecopyleftpatent grantSo, let’s move on to the license texts in detail for a moment. Yesterday I wrote up that the Apache license, version 2.0 and the Mozilla license, version 1.1 were roughly the same. Both got the same set of icons based on my quick reading of both licenses. So let’s take a closer to see if there are relevant differences in the licenses. If there are, we may need to add a distinguishing badge.

General remarks: Apache has a notion of “contribution” spelled out in the license; I think this is intended to clear up what happens when you send a patch to a mailing list — is that intended for inclusion under the same license or not? In my experience, people do submit patches that they do not want to have included — on public mailing lists, no less — but it is very rare. I don’t think this is a crucial difference. The Apache license explicitly excludes linking as a means of creating a derivative work. The Mozilla license defines “commercial use” in a surprising way that includes many things I would consider non-commercial: namely, if I give my friend a USB stick with the source, that’s commercial use according to the license. Mozilla has a concept of “Initial Developer”, which I think is compatible with the Apache notion of “Licensor” — they’re both licenses that are directed at centralized projects with a clear central copyright holder.

Using the software: Mozilla clause 2.1a allows you to use, sublicense and distribute the code and modifications. Apache clause 2 allows the same, but makes explicit that object code distribution is allowed.

Patent grant: Mozilla clause 2.1b grants a license to those patents embodied in the Original Code. Mozilla excludes patents covered by code deleted from the original code — so you can’t re-implement something covered by a patent, it seems. Apache clause 3 does the patent grant and adds explicit termination conditions to that patent grant. Termination in Mozilla is covered in section 8.2. The termination in Apache applies to the relevant patents, while the Mozilla license terminates on any patent. That’s an important distinction when it comes to litigation; I’m not sure it has a place in this iconic scheme, though.

Trademarks: Neither (software, copyright) license grants a trademark license. Apache makes this explicit.

Distribution: Mozilla clause 3.1 and Apache clause 4.1 both require distributing the license text. Both require a notice of modifications made to the original source, but Mozilla wants that in a separate file while Apache allows you to annotate the files themselves. This is similar to the GPLv2 clause 2a, and is something that I very rarely see people (or Free Software projects) do systematically. I don’t think it’s a crucial difference.

Copyleft: Ha, I’m such a moron. How could I have missed this? See, Mozilla clause 3.1 and 3.2 say that the Mozilla license applies to the source code and that the source must be available, also for modified versions. While you may distribute executables under a different license, they must have corresponding source code available under the Mozilla license. So that’s a copyleft license, and the source for executables is available. But … and this is a pretty darn big but … the Apache license does not require this. Clause 4 says a number of things about distribution as source, and allows distribution in object form, but places no restrictions on the distribution of object forms except that the license needs to be included. In other words, you can use the Apache license and distribute binaries without providing source. With Mozilla, you can’t.

So it’s a good thing that the similarity in the reduced representations of the licenses (i.e. the row of icons) has led to a re-examination of the licenses, because it leads to the understanding that the licenses are not the same, by a long shot. Of course, I could have just looked it up in the FSF license list: Mozilla (copyleft, not GPL compatible) and Apache (no copyleft, GPL compatible). If I were a professor I’d claim I’d made the error intentionally in order to spur closer examination of both licenses.

free softwaresourcecopyleftpatent grantMozilla Public License v.1.1

free softwaresourcepatent grantApache License v.2

Tomorrow I’ll carry on with the next 10 licenses in the top-20 list to see if any interesting new features show up, and then on Saturday I can wrap up with a table showing the 10-mile view of all those licenses.

Understanding licenses, bit by bit

An idea that is suggested every now and then is to look at software licensing and give it a kind of “Creative Commons” feel; that is, present the terms of the license in a pleasant and orderly way by means of icons. Now, we’ve already come to the realization that calling something “Creative Commons licensed” is vague to the point of being useless (just “some rights reserved“). Calling something “Free Software” is also vague, but there is a rock-solid guarantee at the bottom: the term guarantees you, the recipient of the software, at least the Four Freedoms. Any Open Source software you receive usually means at least the Four Freedoms as well. So you need to say which CC, which Free Software license, which Open Source license.

CC has six licenses; they are split neatly and orthogonally along the commercial / non-commercial and yes / share-alike / no axes.

The thing is, CC is a much simpler system because it applies to work where there are no patent concerns, where embedded systems don’t have a place, where share-alike has a simpler meaning. I have trouble bringing this same simplicity to software licensing, but I thought I would give it a try.

free softwareFirst off, every Free Software license gives you the right to run (presumably also to compile and then run), study, and modify the work; it must be possible to (re)distribute the (modified) work. So those are the basic permissions. We could put them under a basic “Free Software” symbol, like I’ve done here.

publish sourceNow we get to modifiers of the basic license. What is allowed by one Free Software license, and not allowed by another? Where do the licenses differ on essential points? Going through such an exercise opens up the debate on what constitutes an essential point of difference between licenses. Still, I think we can agree that many licenses ask you to deliver the complete corresponding source along with a binary. Details (written offers, etc.) differ greatly though. In the interest of simplicity, though, we’ll just lump it all together as “publish the source”. The BSD License allows binary distribution without publishing the source, so it doesn’t get this symbol.

copyleftstrong copyleftNow to distinguish strong copyleft from weak copyleft — that’s really important when you want to know what the effect is on your own code and own license choices if you are going to incorporate another piece of Free Software into yours. I suppose, actually, that we don’t need to distinguish this dimension from the previous “publish the source” dimension: I think every “publish the source” license is also one of the two kinds of copyleft (although I can imagine a license that says you must re-publish the original source, but not necessarily your modifications).

embeddedSo how about Tivoization? Or in other words, embedding into a device and then selling, renting or lending the device instead of delivering the software sec? It’s a real difference between GPLv2 and GPLv3. It’s explicitly mentioned in some faux Free Software licenses that allow use except when embedded. I call them faux (fake) because Freedom 0 is the Freedom to use, for any purpose, and clauses 5 and 6 of the Open Source Definition do much the same. So let’s add that dimension into the mix.

patentI’ll throw in patent grants as another factor. This is an over-broad blanket, because the subtleties of patent licensing are devilish. The Apache License, version 2 for instance contains a patent grant with a termination clause. So does the CDDL.

So, let’s take a look (squinting through this rather imperfect telescope) at the big picture. We’ll take the top 10 licenses (according to Black Duck Software) and for each, label it with icons like these and comment on what’s been missed out by the icon scheme. Note that these are not necessarily all Free Software licenses, and not all of them are widely used across the Free Software ecosystem.

  • GPLv2
    free softwaresourcestrong copyleft
    “The original and best” Most widely used license, apparently applied to nearly 50% of all Free Software projects. I imagine that 50% also comes from things like “v2 or (at your option) any later version” licensing.
  • LGPLv2.1
    free softwaresourcecopyleft
  • Artistic
    free softwaresourcecopyleft
    Artistic is applied to a huge number of Perl modules, which are counted individually, which is why Artistic shows up as a significant license force, even if it is almost unused outside of the Perl community.
  • BSD 2-clause
    free software
  • GPLv3
    free softwaresourcestrong copyleftembeddedpatent grant
    The Tivoization clause (part of section 6) can be disabled in the GPLv3 by granting additional permissions in accordance with section 7, if you really want.
  • Apache 2.0
    free softwaresourcecopyleftpatent grant
  • MIT
    free software
  • Code Project Open 1.02
    sourcecopyleftpatent
    The CPOL is a strange license. It is not OSI approved, as near as I can tell. It seems to disallow the distribution of modified works, certain uses are disallowed by the license (immoral ones), there’s a no-sale clause, indemnity, and some other bits that make this license difficult for me to place anywhere in the world of Free Software.
  • MS-PL
    free softwarepatent
    The MS-PL is kind of strange; I’ve never seen it in practice. It looks roughly — very roughly — like BSD plus a patent clause. This is a Free Software license, but GPL-incompatible.
  • Mozilla
    free softwaresourcecopyleftpatent grant

Comments on my artistic icon skills should be addressed to Nuno Pinheiro. You may be able to hire him to do very nice icons for this set-up, and Björn Balazs can do usability testing on them. Kolourpaint FTW. Now, as for the accuracy of this table, I’ll say it’s a best-effort one-morning overview, so there may be plenty of errors in there. The point is the principle of reducing the licenses to a sequence of icons. The icon for patent is a patent troll (notice the glowing red eyes) because I couldn’t think of anything better.

So, errors and omissions aside — I welcome corrections in the comments on this blog — we need to ask the question: does this scheme of badges highlight any (all?) of the essential differences between the different licenses? If not, what additional discriminatory characteristic should we add to distinguish them?

Based on this list, we see that BSD 2-clause and MIT are “the same”. Are they really? Well, it depends on how you interpret the second clause of the BSD 2-clause license and whether the single MIT clause implies it. In a world of good faith, you could satisfy the MIT license by doing what the BSD 2-clause license asks you to do. So I think I could be satisfied that this is a same-difference identification of two licenses.

But we could look at some others — is Apache equivalent to Mozilla in all meaningful ways? How about LGPLv2.1 and Artistic? That, however, will have to wait for another day. Where I set out to demonstrate that you can’t reduce licenses to blurbs and icons, I haven’t done so yet — and still, such a reduction might be useful from a license selection standpoint, because you can pick and choose based on broad categories of license behavior.

Doing it right (on the wrong side of town)

Ah, the Powder Blues band. Apologies, mostly.

I know a place on the wrong side of town,
Where the band width is cookin and they’re loading on down,
Joe compiles like his souls on fire,
Baking a new firmware for a telephone wire,
Rev up the sources, compliance comes down,
Doin it right on the wrong side of town!

In these troubled times, I thought I’d share some tales of companies doing it (relatively) right. Thanks to the quiet pressure and diplomacy of gpl-violations.org and their (and FSFE, too) desire to work on dialogue and long-term solutions, it’s possible to find consumer electronics in Europe that are compliant (within the wriggle room that is left in the notion of “compliance”).

In September I picked up a Lacie Network Space drive. 1TB, I think, UPnP server, black, glossy. So of course the first thing I did was go looking for GPL violations. This ended up with a half dozen folks standing around a table, red wine in hand, an improvised network on the floor. The manual of the product doesn’t mention the GPL. If you boot it up, you can get the syslog:

Jan 1 00:00:28 syslogd started: BusyBox v1.1.0 (2006.11.03-14:53+0000)
Jan 1 00:00:29 kernel: klogd started: BusyBox v1.1.0 (2006.11.03-14:53+0000)
Jan 1 00:00:29 kernel: Linux version 2.6.12.6-arm1 (jrichefeu@grp-horus) (gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2)) #3 Tue Feb 3 14:04:45 CET 2009
Jan 1 00:00:29 kernel: CPU: ARM926EJ-Sid(wb) [41069260] revision 0 (ARMv5TEJ)

I should add it’s really quiet a nice piece of kit, except it never spins the disk down. And of course, the manual doesn’t mention the GPL. But the support section of the website does, and it’s not difficult to find the source downloads section. I haven’t verified that these are the complete and corresponding sources. It looks reasonable, though.

More recently I bought a Conceptronic Media Giant Plus, which is a HDD plus codecs and a bunch of A/V plugs, so it goes right into the TV — and then videos and whatnot go on the HDD, and play from there. The UI is a little clunky, but it works well enough, and if it saves having to go through and find the right DVD for the kids all the time, that’s fine by me. I don’t know what the hardware inside is exactly; it’s been on only once so far to copy the Eefje Wentelteefje TV Show onto it.

The box comes with a thin leaflet of license compliance statements. “Great!” I thought, but it turns out to be MPEG-4 compliance, and Fraunhofer, and all kinds of commercial licenses, patent licenses, consortium licenses, etc. No mention of the GPL. No mention of the software actually running on the machine. “Drat!” thought I. I don’t rub my hands together and cackle evilly then, though.

So my surprise was a little greater when I leafed through the (thick and comprehensive) user manual and found, at the back, a chapter “Licensing Information”.

This Conceptronic product (Media Giant) includes copyrighted third-party software licensed under the terms of the GNU General Public License. .. the following parts of this product are subject to the GNU GPL: (list including busybox, xine, Linux kernel). … Conceptronic as eposed (sic – exposed?) the full source code of the GPL licensed software, including any scripts to control compilation and installation of the object code. All future firmware updates will also be accompanied with their respective source code. For more information on how you can obtain our open source code, please visit our web site.

That text is followed by the full text of the GPL version 2, the LGPL version 2.1 and the FreeType license, 2006-Jan-27.

So, that’s pretty thorough except that a “visit our website” isn’t all that specific. I couldn’t find any links to the source on the product page, but some searching turned up the source at last.

So here’s two cases of “yeah, that’s ok, could be better, keep trying” — it’s like dealing with my son learning to ride a bicycle, they need some encouragement and support, because they’re still learning.

Back from EOLE

Wednesday I was at the European Parliament building for the EOLE. The event is a medium-sized (say 60 attendees) legal oriented event around Free Software; this year it featured a track full of definitional goodness — let’s try to formulate words commonly used in Free Software (in licenses, but also other writing) in terms that lawyers can understand.

This kind of event is useful because it works towards normalizing the vocabulary used by practitioners in this area: in other words, we end up calling a spade a spade. If we can agree on what “source code” means exactly in the context of the GPL (actually, version 3 has a fairly lengthy definition, which is something we can work with), then it becomes much easier to consistently advise projects and businesses on how they can best engage with Free Software.

Any get-together of people with a strong legal background in Free Software is sure to bring out some more interesting interpretations or corner cases. There’s always another jurisdiction or recent ruling to take into account, and of course every now and then another new license rears its ugly head (like the Jiggy Wanna license, which is basically Sleepycat if I read it right, but still different). In many ways the resulting discussion “dude! if you squint just like so and read the GPLv2, it turns into a dinosaur!” is a lot like a Free Software technology conference “dude! if you hold your breath and do this DBus call, dinosaurs come out of the firewire port!” Fun corner cases, even when we realize that the core values and meaning in uncomplicated cases (read: situations entered into in good faith by all parties) are well understood.

For me — and just how many times have I read the darn GPL, anyway? — the best insight of the day was the proviso of the GPL that says that the written offer of source code availability (if you don’t deliver the source with a binary distribution) must be valid for any third party. So that has a definite effect on your obligations under the GPL; it also affects some GPL-related advice I’ve given in the past to people, as I thought that the written offer applied only to those who have obtained the (binary) distribution. In a license, every letter counts (which is, in a sense, also unfortunate, because that’s why we have so many).

Looking at Licenses – LLVM

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

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

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

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

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

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

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

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

Free Software but not Open Source

It is possible for software to be Free Software (in the sense of GPL version 2 compatible), and yet not satisfy the requirements of the Open Source Initiative for being an Open Source license. This is an obscure corner case in the GPL, because people usually (not always) mean Free Software when they say “Open Source” — stressing a technical detail that is a prerequisite for Freedom over Freedom itself.

The relevant bit of the GPLv2 is clause 8:

8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.

You could write GPLv2 licensed software whose distribution to the United States is prohibited, for instance. This clause allowing additional restrictions based on geography has not survived in the GPL version 3.

In any case, for a GPLv2 plus geographical restriction license, the problematic requirement is requirement 5, No Discrimination Against Persons or Groups, formulated as: The license must not discriminate against any person or group of persons. Clearly restricting a GPLv2 licensed product to a certain geographical area discriminates against a specific group (i.e. those outside that area).

I’m told — but have not verified — that there are also two Open Source licenses that are not Free Software (i.e. the converse of the compatibility issue pointed out here). I’m also told that they are used by one project each, so it’s not a huge burden on the Free Software community.

Sounds like GPLv2

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