Home [ade] cookies

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

Tags: ,

22 Responses to “Understanding licenses, bit by bit”

  1. ComputerDruid Says:

    I think you’d need another icon for AGPL, although that might fit in with tivoization, although I think it’s mostly intended for websites

  2. adridg Says:

    Yep, AGPL is copyleft-over-network or something like that. I didn’t need to introduce it yet while looking at only the top 10 licenses because it doesn’t appear there. I’m not aware of any other licenses (than AGPL2 and AGPL3) that require copyleft over network, though.

  3. Tweets that mention Understanding licenses, bit by bit « Bobulate -- Says:

    [...] This post was mentioned on Twitter by Glyn Moody, Thierry Hermann. Thierry Hermann said: Understanding software licenses, bit by bit: [...]

  4. Aurélien Gâteau Says:

    Nice post! I was a bit skeptical when I started reading it, but this “icon-ification” really helps to get a birds-eye view of the license landscape. (Oh, and your Kolourpaint skills rock :D )

  5. Andrea Diamantini Says:

    Fantastic post, really clear and interesting. Many thanks for :)

  6. uberVU - social comments Says:

    Social comments and analytics for this post…

    This post was mentioned on Twitter by glynmoody: Understanding licenses, bit by bit – interesting attempt to provide cc-like symbols #licensing #freesw #cc…

  7. Mike Arthur Says:

    Ade, brilliant post. I really think the icon guide is something that should be done professionally and perhaps by the FSF. It will hugely, hugely help the world to understand open-source icons when they are distilled down like this.

    Great work!

  8. adridg Says:

    Well, this is me blogging with my FSFE hat on, Mike. So yeah, you might say we’re on the case :) It was more of a simple experiment when I threw it together, but the response has been pretty good, so I will probably expand its scope.

  9. A. N. Tsiolkovsky Says:

    I think something like this is really helpfull for normal people to quicly see what the license means in essence. Maybe you could get some great artist like Nuno Pinheiro from KDE/Oxygen to create some very nice design for this new Licensing cheat sheet and some cool looking icons.

  10. Patrick Says:

    So the most free licenses (the BSD/MIT style ones) end up with the least number of icons — giving the casual observer the impression that they are not as good/free as more restrictive ones like the GPL?

    This alone almost guarantees update of this idea by the likes of the so-called FSF… :&

  11. adridg Says:

    The FSF is called the FSF. No so-called about it. You’re seeing these as “Freedom badges” which is exactly the kind of short-sighted reaction that we need to *avoid* when iconifying licenses. You seem to see them as “more is better” — like achievements in video games. Maybe you should put on the glasses that let you see them as “obligations to fulfil” or — and this is the most subtle of them all — “important points to be aware of when choosing this license.”

  12. Paul Boddie Says:

    The source icon always appears along with some kind of copyleft icon – not surprising, since the source underpins what copyleft is all about. Maybe the source icon could refer to weak copyleft (or “some source included”), and another icon could strengthen it to “full” copyleft (or “all source included”) – together this would be a lot like “share alike” in the CC world, where I think the sharing covers the whole work, although definitions of “the source” probably aren’t very rigid.

    When the GNU SFDL was being tabled, which is more of a content licence, I advocated that “the source” be the actual original materials used to produce other content, so that if vector artwork were used to produce bitmaps, it wouldn’t be sufficient to merely distribute such bitmaps.

  13. anon a mouse Says:

    The license list at says MS-PL is a copyleft, but not a strong copyleft, so it should probably have your weak copyleft symbol.

  14. Open Source, Foss, Floss – 2009-12-18 | - GNU/Linux, Open Source, Softwareentwicklung, Methodik und Vim. Says:

    [...] Understanding licenses, bit by bit [...]

  15. Alberto Barrionuevo Says:

    Adriaan, please, which is the license of the article, that I’m not able to see it and I would like to create and publish translations to a pair of languages…
    Btw, congrats, so interesting! :-)

  16. LPĮ #4 | geko Says:

    [...] daugiau sužinoti apie populiariausias LPĮ licenzijas, vertėtu paskaityti išsamų straipsnį “Understanding licenses, bit by bit” bei jo antrąja [...]

  17. Marcus D. Hanwell Says:

    Great post Ade, it would be good to have something like this as a page I can refer to when trying to at a glance assess what rights a particular license does and does not give me.

    I think having all of them, red for yes green for no, or something like that, would be great as you could scan the columns. Very interesting, and so much more condensed than trying to decipher multiple license texts.

  18. Randal L. Schwartz Says:

    Your interpretation of Perl’s Artistic License is backwards. Its closest cousin is BSD, where first contributor has the same rights as first author, not GPL, where first author retains rights that no contributor can have. I think by your badging, it’d get only the “Free Software” symbol.

  19. adridg Says:

    I’m not sure which rights you think the GPL reserves for the first author? In a system of distributed .. er .. distribution, A writes stuff (and releases it), B modifes it (and releases it), C onbtains that modified version with: (1) a license from A for the version A gave to B (GPLv2 clause 6) and (2) a license from B for B’s version (GPLv2 clause 2b).

  20. adridg Says:

    The Artistic license reserves for the original author the “artistic control” over the software. Looking more closely, Artistic 2.0 would get FS, patent, and a WARNING badge. Using 4.c.ii makes it copyleft; using 4.a isn’t Free Software anymore, and 4.b is .. maybe Free Software, but then very liberal. The thing about Artistic is that it has so many choices that are possible, so it’s hard to say if the license is one or the other.

  21. » Blog Archive » Some Reading about FOSS Says:

    [...] more here: [Translate] English Deutsch ελληνική español [...]

  22. Randal L. Schwartz Says:

    “I’m not sure which rights you think the GPL reserves for the first author?”

    The GPL reserves the right to use it *as you wish* to the first author. All subsequent contributors must use it in a way that makes them equivalent to the next contributor in the chain. So it makes the first author “special” in that they can do what they want. Contrast that with the BSD license, which allows any contributor to take the role of “first author”, and lock up their contributions. Thus, all authors are equal under the BSD license.