Bobulate

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.

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!

I want them to stop explaining my browser options to me. I don’t want to know my browser options. The more I know about my browser options, the more I feel like a fool.
…
So I feel like a real consumer fool about my money, and now I have to feel like a fool about my browser, too. I liked it better back when we all had to belong to the same Browser Company, and browsers were browsers — black heavy monolithic boxes, that were routinely used in the movies as murder weapons (try that with todays browsers!). Also, they were permanently attached to your computer and only highly trained Browser Company personnel could “install” them. … It was as close as most people came to experiencing what heroin addicts go through, the difference being that heroin addicts have the option of going to another supplier.

All that is taken directly from a column by Dave Barry (he still writes for the Miami Herald) which I stumbled across recently. It’s in “Dave Barry’s Greatest Hits”, published in 1988. I’ll admit to minor editing: I replaced “phone” with “browser”. There were no web browsers in 1988.

Not much changed, eh, in twenty-one years?

It’s just a matter of serendipity that I was flipping through this tatty old humor book in the weeks following the European Union’s anti-trust decision around browsers. You can see the EU decision (PDF, 1.1MB) and the FSFE’s reaction — the latter can be summed up as “yes, this is one problem sort-of out of the way, but there’s more issues to be dealt with.”

I like choice. But I suspect Dave’s missive on the phone still largely applies and that people don’t want a browser. They want a tool with which to order pet food from the comfort of sitting in a cardboard submarine in their basement. There’s another angle on the topic as well: encouraging installation click-through. I hadn’t considered that — although recommendations that all the balloted browsers be available in some (fairly) recent version on-disk were made. That would change the issue from downloading and installing software to activating software. However, if you follow Adrian’s train of thought (that zdnet link), you end up disabling all change to the device, returning to the era of fixed-function machines that nobody can change.

Except by the Browser Company, of course.

In the past two installments, I suggested a basic icon theme to describe the important points of a variety of Free Software licenses, applied those icons to the top ten most popular Free Software licenses and found that several of them are “the same” in terms of icons — which suggests that either what the two licenses does is roughly the same (so we can consider them equivalent) or that there is a distinguishing characteristic that hasn’t been taken into account yet. The second installment took a close look at two licenses that were “the same” and illustrated a third option: that I’d applied the icons wrongly.

One question left over from the first installment is whether the Artistic and LGPLv2.1 licenses are different in a meaningful fashion. I won’t try to answer that here, but instead I’ll carry on with the next top 10 most popular licenses, as enumerated by Black Duck Software again (bear in mind that these licenses apply to less than 1 percent of all Free Software projects):

• Common Public License
  
  This license has been superseded by the Eclipse Public License, but remains more popular than its successor. It looks a lot like the Apache license, although there’s a subtlety in the patent grant (“at the time”) and a designation of jurisdiction (New York). It is weak copyleft, because it requires source to be made available in a reasonable fashion, but certain additions to the program are excluded.
• Eclipse Public License
  
  It is very difficult to see what the difference is between the CPL and EPL. I don’t feel like running diff right now.
• zlib
  
  The zlib license adds to the basic 1-clause or 2-clause MIT / BSD licenses a requirement to mark changed files and to represent the origin (and modification) of the software accurately. I consider that a common courtesey and basic honesty, but it might be good idea to add it to the list of icons; a kind of “label the provenance” image (but I can’t think of one right now).
• LGPLv3
  
  The LGPLv3 is interesting because it is relatively short: it is explicitly a “GPLv3 with these additional permissions and modifications to the conditions”.
• Academic Free License
  
  Interpreting Larry’s licenses leaves me a little scared: it is, after all, his specialty to write licenses. I don’t see how this is copyleft, since there is no obligation to provide source downstream — unless I’m totally misunderstanding the meaning of “contradicts” in clause 1.d. The license itself allows non-contradictory re-licensing; that probably deserves an icon of its own, although I suspect that relicensing is going to be possible only within the group of licenses with the same set of icons (I’d hope so). There is some specific patent and retaliation language here, but the troll in the “patent grant included” icon should make everyone read twice.
• Open Software License
  
  Another Larry Rosen product, and the only difference I can quickly spot is that this one requires licensing derived works and copies under the same license (where AFL allows a different but non-contradictory license). More evidence for the need for a “allows relicensing” badge.
• CDDL
  
  Largely the same as the Mozilla license.
• Mozilla Public License 1.0
  
  Largely the same as the Mozilla license. Oh, wait, this is the Mozilla license, just an earlier version. I don’t feel like breaking out diff just now.
• PHP
  
  The PHP license looks at first glance like a BSD-style license; and then you realize it has six clauses instead of 2 or 3 (four thou shalt not count; five is right out). These have to do with the use of the name PHP and as far as I’m concerned would justify a kind of warning badge saying “surprise conditions here”. I’m not going to draw one just right now.
• Ruby
  
  This is an unusually permissive license because it allows relicensing or public domain distribution and allows binary distribution while pointing only to the original.

That wraps up the tour of the top 20 most popular Free Software licenses, good for pver 90 percent of all software licenses in the Free Software world (though apparently there’s about 1800 variants out there). Today’s list suggests that we need an additional badge for relicensing, one for “watch out!” and perhaps a “represents” badge as well.

So, to return to the original reasons for doing this exercise: provide a quick overview of what the licenses mean that we use regularly in the form of an iconic representation, and to illustrate where the essential points of licenses agree. Tomorrow: wrap-up, table presentation, and a general request for better artwork.

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.

ComputerDruid 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:

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

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

Mozilla Public License v.1.1

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

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.

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

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

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

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

I’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
  
  “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
  
• Artistic
  
  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
  
• GPLv3
  
  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
  
• MIT
  
• 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
  
  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
  

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.

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.

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

Here we have some of the brains behind FSFE. It’s just who we have at the office today, Alina, Hugo and myself. Matthias has run off for now.

That’s one of the things about FSFE people: always busy with new projects (like learning to cook), new bits of information to get out into society (Hugo does that), new applications to promote (like yacy). They don’t stand still. Some of them don’t stand still long enough for me to draw a silly picture of them or get a picture of their hair. Henrik Sandklef, for instance, was at FSCONS but didn’t get a caricature in a previous flashcard because he didn’t stand still all weekend, he was so busy organizing things and making sure that things worked out right at the conference. You can see Henrik in the GHM photo, right in the center.

There’s also the FSFE people whom I haven’t seen since I started my artistic career (ten days ago). The formal composition of the FSFE as an association and the core team of the FSFE shows that I’ve missed more than half of them. So do not think that my set of drawings is complete — far from it, given that Gareth (UK), Shane (FTF), Georg (Founding President), Pablo (Spain), Reinhard (Finance), Patrick (Italy), Bernhard (Germany), Henrik (Sweden) and Fernanda (Vice President) are all missing from my portfolio. Come to think of it, I should really boot up my Apple //c and type in the old “Animals” program to create a taxonomy of all 15 members of the association. In theory four yes/no questions should suffice.

Who is that masked man woman looming green thing? This is just a shot of Matthias at his desk. The Plussy on the wall behind him is the mascot of the Fellowship of FSFE. You can support FSFE — and perhaps save Matthias from a terrible fate and get a dinner in the process — by donating time or money.

FSFE shares an office with KDE e.V., and this evening I’m switching hats from blue (KDE e.V. board meeting) to green (FSFE FTF work on cataloging the legal situation for Free Software around Europe). But first .. Berlin! (Cue Leonard Cohen).