Bobulate

This weekend is Software Freedom Day — a chance to celebrate the idea that you, the owner of a computing machine, should be in control of the computations done on that machine. As the owner, you should be able to run what ever you want on the machine — or be able to prevent running someone else’s software on your device. This is a notion best served by Free Software.
The SFD events are global and organized in a decentralized fashion. I see there are six events in Nigeria, for instance, including one in Bauchi state and one in Sokoto. There are two events in the Netherlands, one on the 18th in Den Haag (the Hague). Karsten Gerloff, president of the FSFE, will be speaking there, among others. The other event is on the 17th in Amsterdam at the CWI.
Also don’t forget that the 19th is Talk Like a Pirate day.

Do you get this as well? A PDF delivered along with a message that you can use Adobe Acrobat Reader (r) to open that file?

PDF is a (relatively) open standard. It is an ISO standard (19005-1), for one thing. This also means that there are alternate implementations of the standard. And you might have good reasons to avoid the Adobe implementation. For instance the number of exploits against their implementation, or because it doesn’t run on your hardware / software platform. Most of the time I’m at a computer which is perfectly capable of dealing with PDF files through a Free (both as in speech and in beer) PDF reader, and the "download Reader" just strikes me as weird. I get these PDF files from travel agencies, hosting providers, financial advisors and local governments. I often reply asking them to update the text accompanying the file to say something like "You need a PDF reader to view this file. Get a free one or use something else." The PDF Readers (.org) site is a good place to point people and organizations. The site points out the available options and how to get a Free PDF reader.

The Free Software Foundation Europe (FSFE) has started a campaign to promote the use of Free PDF readers by local governments. The idea is to point out where your local government is pointing only to the proprietary software solution and to get them to adapt the text to offer more choice. There’s a contest involved, as well.

As far as the PDF readers site goes, it points to muPDF; that’s one I would personally avoid for semi-technical reasons: the code is terrible and utterly undocumented. Maybe the application works — but it’s not something that satisfies my code-readability test. Not one of the files has a license header, although the thing as a whole is licensed under the GPL version 3 or a commercial license.

Turning to the more popular — or rather, the recommended readers on Free Software operating systems — selections, there’s Okular and Evince. I use both of them fairly regularly — Evince is my fallback on OpenSolaris during those times that I’m compiling KDE. Following the links from PDF Readers to the two web pages for Okular and Evince shows a pretty big difference: the latter is focused on packages and contains a link to a how-to-compile page, while the former is all about building the software from scratch with a comment that there’s probably packages available. Neither of these strike me as a particularly good user experience. I wonder if there’s any feasible (technically and privacy-preserving) way to detect the OS so as to improve the download suggestions.

Two upcoming (in the fall, that is) conferences of note whose calls for papers are still open.

FSCONS: the Call for Papers is open until June 30th. FSCONS is a tremendously fun conference because it’s not just software technology, but Free Culture and other things. That means that there is more scope for learning (well, this is important for me) things outside of software. The compressed earth brick machine made a lasting impression on me last year, for instance.

NLUUG fall conference: the topic this (half) year is Security in all its aspects. You could talk about security from a systems administration perspective (for KDE, for instance, managing trust in a global distributed project with only occasional face-to-face contacts) or programmatically (for KDE again: what to do with Plasmoids and mitigating whatever security risks they might bring). This CfP is open until July 12th.

The IFOSSLR — the International Free and Open Source Software Law Review — has published issue #3. The IFOSSLR is the only journal dedicated exclusively to Free Software legal issues. While I was the FTF-Coordinator at the FSFE it was great to see the careful legal thought put into all kinds of issues (from trademarks to license assignment to risk assessment). It’s important to have an understanding of the legal issues around Free Software (both development and deployment) that is business compatible. That’s not to say that the interpretation is adapted to suit the desires of business — no, it means that the understanding is formulated in a way that businesses understand. It’s quite important to state cause and effect or obligations and rights carefully so that businesses understand what to do and how to do it right. After all, most Free Software developers want everyone to play by the rules set out in the license.

Sometimes what’s necessary from a business standpoint isn’t what we’d like from a Free Software perspective, but there’s no basis for real complaint. The licenses say what they say (which is why you should be careful in picking a license!), and with a good understanding of what they actually mean, both developers and business using the fruits of that development can get on with what they do. See for instance this bit on the Freecom Music Pal (I have one of those too; it’s OK for listening to Country 105 but the author is right that it’s rather difficult to hack and the firmware is wretched).

The IFOSSLR is available gratis as a PDF, or you can get a printed copy via LuLu. I’d suggest the latter, because legal journals just look really impressive on paper.

As a collaborative publication, the IFOSSLR is always looking for submissions, too. See the Call for Papers for issue #4 for more information. It’s not just for lawyers — the perspective of community and developers on legal issues is really important. The practice of Free Software licensing is an interesting area because there are four (no, wait, six) parties involved: the drafter of the license, the developer using the license, the user of the software released under that license, the community (c.q. peanut gallery) of users of the license, the lawyers for each of the aforementioned parties and the courts. Getting all that to align in harmony is a big task: a task that requires communication and publication. So throw your thoughts into the fray.

Compliance engineering as a topic covers those activities that make it possible to ship a (consumer electronics) product that complies with the license(s) of the software contained in that product. That includes things like: figuring out what software actually is in the product (you’d be surprised how often vendors don’t even know); ensuring that you know what configurations and versions were chosen to put in the product; finding out what the licenses on those versions of the software are; finding out out what the obligations under those licenses are; and finally actually doing what those obligations demand. Hence, comply.

Comply or explain (to one of the organizations that look into enforcing software license obligations, like the BSA or gpl-violations.org).

The FSFE has long had a brief article on how to report and fix violations and Armijn Hemel at Loohuis Consulting has written a fairly lengthy compliance engineering guide (also some articles on LWN).

One popular license for software that tends to end up in consumer electronics products is the GPL. Either version 2 or version 3. It has some specific obligations that make compliance both important and sensitive. Those are the clauses requiring the complete corresponding source code, which means you need to know what the code is and how to provide it. It also means that for every binary release you need to provide the sources that can be used to create exactly that binary release. Not every company does that consistently.

Heck, I’ll name names: Conceptronic, a Dutch consumer electronics company, tries hard to comply. It delivers source code for the firmware shipped with the original release of devices, and it sometimes updates the available source tarballs. But not always. Dennis, the guy responsible, knows this is a problem. He tries, but time pressure and the upstream don’t always make it possible to do the right thing.

So there’s a company technically in the wrong where I’m willing to believe that they could be in the right if there was a little less effort involved, or a little better support in the compliance engineering process.

Enter, once more, Armijn and Shane, in their business guises of Loohuis Consulting and Opendawn Consulting. They work, shall we say, both sides of the fence: both in helping people improve their compliance processes and in tracking down violators later. For both sides, knowing which sources should have been supplied with a given binary release is of paramount importance.

So Shane and Armijn — supported by the Linux Foundation and Stichting NLnet — have produced a tool that helps in identifying what software has gone into a binary firmware image. It’s still in its infancy, but it can usefully detect Linux kernel versions, Busybox versions and configurations. That means it can be used — for products containing those pieces of software — to answer questions like “what sources and configuration files and scripts should be delivered with this product?” And that’s important because of the requirement in the GPL to provide (when necessary as defined by the other license obligations) the complete corresponding source code. Not just a bunch of tarballs and a “figure it out” notice; not just the upstream code, but whatever patches went into the device as well; and preferably not a whole bunch of extraneous cruft, either.

The tool makes it easier to do compliance checking from the outside, and easier and cheaper (as in Free beer) to do basic checking on the inside. It’s no replacement for a dedicated compliance engineer, but it does help a lot in answering questions about “what’s in here?” before firmware goes out the door.

I should add that the tool understands some common firmware packaging styles, so it will find and unpack and check things in a squashfs image. Upcoming features will add more filesystems, like concatenated squashfs filesystems, which will save a lot of time compared to running od -c, grepping for magic numbers, dd-ing things apart and then loopback mounting parts individually — that will become automatic.

You can find the tool (which is Free Software under the Apache license) at BinaryAnalysis.org. BA to the rescue. Man, I love it when a plan comes together.

The third edition of the FTF’s Amsterdam Legal Workshop is behind us. Two days of excellent weather (for Amsterdam in April, anyway), good food and in-depth legal wrangling on a variety of to pics. Like patents and how to work to defuse them for businesses and Free Software projects. Canonical kindly provided the nicest lawyer in Europe and a speaker who could rush 168 slides in 20 minutes, so their input is greatly appreciated as well. It was good to see friends from HP as well for the engineers-and-lawyers perspective.

Each year the event brings in new faces and new topics, and we’ve grown to the point where we have traditions and can afford a little bit of silliness amongst the serious talks and the networking and the hashing-out-of-issues-left-hanging-elsewhere. So near the end of the conference I got to hand out custard cream cakes of merit and one attendee asked me “so where’s your pink whip?” That, though, would mean spilling too much KDE over into the FSFE, which is something that’s not going to happen.

That picture over there is the group photo — at least, the one I can publish, because I haven’t cleared the publishing rights to pictures of the conference participants nor the (potentially copyrighted) images on their T-shirts. And of course, even a room full of happy lawyers should not be provoked.

Planning is getting underway for next year already — that was my big failure this year, to get started early enough, so this is overcompensating a little — and we’re aiming for the same week of April, 2011 (say the 7th and 8th). Next year Easter is much later, so the workshop and the holiday clash less. Location to be decided — if we’re ever going to break free of Amsterdam, it needs to be done now.

Today is the first day of the Amsterdam Legal Workshop — in full I suppose that’s called the Free Software Foundation Europe’s Freedom Task Force European Legal Network yearly workshop in Amsterdam. As in 2008 and 2009, we have a room full of the top lawyers and technologists in the Free Software legal field. Thanks to the organizational efforts of Shane, Karsten, Hugo and Rainer we’ve got a full two days of talks and demonstrations. As in past years, new relationships develop as we bring different parties to a neutral, private conference. We also take stock of where we are on a global scale with respect to Free Software licensing and legal issues. Glyn Moody was kind enough to open up the conference with a talk on the (singular) conversion from analogue to digital which — as is Glyn’s wont — ties together the past and future and fields of law, biology and computer science. And from there, we’ve gone off into deep legal territory which I won’t write about, but it’s an education.

Today (yesterday? timezones are confusing) the jury in the long-long-long-running case of SCO vs. Novell returned a verdict. on the question whether the copyrights (to UNIX) were transferred to SCO. The jury answered “no”, which bring to a sort-of-close the whole lawsuit. You can find more coverage at Groklaw (kind of gloaty, though), Ars Technica (annoying with Konqueror though) or The Register.

I say it’s sort-of-closed, simply because the decision and final verdict belongs to the judge, not the jury (as the parties in the suit had requested — see Groklaw). So things could still change around. In any case, this means (modulo final decision, appeals, and whatnot) that the copyrights to UNIX still reside with Novell and SCO has no case to bring copyright infringement suits against contributors to Linux. Novell has the copyrights, so it would be Novell’s prerogative to do so if such claims had any merit.

To put it more simply still: the spectre of suits “against Linux” on the basis of copyright infringement from UNIX is now banished. That’s a form of freedom.

[[ Another case, Palm vs. Artifex, has its first hearing today if I read the court schedules right a ways back; that’s the suit brought by Artifex against Palm for Palm using the mupdf (GPL) libraries but not shipping the sources of the PDF viewer application. A suit that, to me, exemplifies yech, gross on both sides of the suit: Palm for not doing the usual compliance move, Artifex for shipping wretched source for mupdf and bringing suit from a licensing rather than compliance angle. ]]

Today, March 31st, is Document Freedom Day. It’s a day in which we (for some fuzzy meaning of “we”, but including at least Free Software developers) stress the importance of Open document formats. Those are formats which are documented as an Open Standard, which is to say that their syntax and semantics are both described in a fashion that is available to the public and well understood. Plain text is such a format, and it works well for certain kinds of unstructured documents — stories, essays, etc. Well, assuming you know what character encoding is used and that the hardware encoding is understood as well. If you want a little more structure, then something like LaTeX can get you markup and layout and whatnot. However, LaTeX can be a terrible mess and understanding just what a given document does can’t really be decided except by running LaTeX over it and waiting for output.

A really Open document format has a standards document attached to it, one that defines exactly what the syntax and semantics are. Preferably a standards document that is controlled by a trustworthy standards body — one in which procedures are documented and followed and where the public interest is served. That way, you end up with a document standard that is stable, well-defined and useful.

In theory, anyway.

So of course this is all hinting at ODF (OpenDocument Format), which has a specification (v.1.1) and a process for updating the specification when needed. I believe the specification itself has its issues — it really is difficult to specify syntax and semantics with rigor — but it gets the job done and, most importantly, is written in good faith and available for everyone to implement on a royalty-free basis. The latter is important because we want to play by the rules but also need to enable current and future implementations of tools that use the document format without restrictions.

Document Freedom Day focuses on ODF, but it’s about all Open document formats. And about implementations — for ODF, we have OpenOffice.org and KOffice and the GNOME office tools. There are also command-line tools and applications that process ODF files without being WYSIWYG editors. Or consider OfficeShots, the side-by-side comparison tool for ODF applications. Again something that is enabled by royalty-free use of the standard.

As I’ve been writing this, Document Freedom Day celebrations have been kicking off in various places — for instance, in Baarn, not 80km from where I live (but I’m in no state to travel there) or Slovenia.

You can find other (brief) comments on DFD from Julia Klein or Carlo Piana.

A software license lets you do something that you otherwise would not be allowed to do, given the limited permissions granted by Copyright law. That is, it changes the “all rights reserved” into “some permissions granted and all other rights reserved.” Which permissions those are depends on the license; which exceptions to “all rights” exist depends on the jurisdiction under which you’re operating (e.g. while “Fair Use” is something you can do in the United States, that concept doesn’t exist everywhere).

There’s lots of software licenses. There’s even lots of Free Software licenses. The Free Software licenses all grant you permission to do at least four things: use, study, modify and share. Sometimes they allow more. The BSD license allows proprietization. The Apache license allows the use of patents embodied in the software (important in jurisdictions with patents). The GNU General Public License allows you to format shift (e.g. you may publish a GPL licensed program as a T-shirt).

The flip side of permissions is that of conditions: often the permissions are granted provided that you do something else. For instance that you pay for the permission (a proprietary, commercial license would require that). Or that you give the source code of the program to recipients of the binary (as the GPLv2 says). Or that you send your modifications to the original author if you distribute the code in modified form.

The conditions may also include a condition that the same license applies to derivative works. The GPLv2 has such a condition. The EUPL has such a license (plus an escape clause). The CDDL has one. This kind of condition creates an “species” around a single license of like-licensed software. Such a species has software individuals that can be freely combined and modified and shared, since it all falls under the same license.

This kind of condition also creates a division, one between species, because you can’t “breed” between species. The conditions of licenses of two different species cannot be satisfied simultaneously, so you can’t do it. As a consequence, we see that the same functionality is developed multiple times under different licenses. Some might call that wasteful. It’s out in the open, though, and reimplementation only needs to happen once for each species, so the waste of effort is limited. Who knows how much sloth and useless duplication occurs behind closed doors? In any case, we find that a license with conditions creates its own species and that most software combination works within that species.

So-called “permissive” licenses can cross the species divisions, simply because they do not have any conditions that prevent them from being integrated into another species.

If you’re a software developer who is combining pieces of software which are under different licenses, you need to be aware of the species differences. Indeed, sorting out which code can be combined with which can be a considerable effort. The FSF lists dozens of Free Software licenses and whether they’re compatible with the GPLv2 and the GPLv3 — and even the GPLv2 and GPLv3 are different species.

So we have two problems with having lots of species: that of duplication of implementation effort (yes, I too have had to ignore an available Free Software component that did what I needed and had to re-implement it badly because of license incompatibility) and of effort involved in checking for compatibility.

The underlying problem — that of having many license species — is what we call license proliferation: there’s lots of licenses, and more show up all the time. Black Duck software identifies some 1200 of them. The OSI has 60-odd licenses. That’s a lot of extra effort.

So when people ask the FSFE about software licenses, in particular about creating a license with new conditions or that varies an existing one, we say “don’t do it.”

That bears repeating:

Do not write a new (Free) software license. Just don’t. Really. Pick an existing license that does what you need. And if there isn’t one, then what you want is probably not a good idea.

I’m aware that’s an argument from authority. That’s not always a good kind of argument to use. However, you need to be aware that in creating a new species (by creating a new license) you’re committing yourself to the whole rigamarole of re-implementation, and excluding people from outside the species.

Now, as with almost every rule (except rule 34), sometimes the rule is just a guideline. People who know what they’re doing can bend the rules.

There can be really good reasons to bend the rules. For instance, new dangers show up that threaten the Free Software ecosystem. These dangers may be a reason to introduce a new license to counter them — patents, for instance. Who would have though, too, of valuable trademarks in Free Software? They’re explicitly mentioned in the more modern licenses. A simple permissive license that disclaims warranty might not be sufficient if regulatory frameworks change. And in some areas of business, existing regulations might require things of a software license that the existing ones do not provide.

So there can be good reasons to change. And in spite of my position that license proliferation is bad, I’m going to applaud the Mozilla Foundation for choosing to look into updating the MPL (coverage from the Register here).

The MPL is a file-based license, not a work-based license, so it creates species in a different way. Clause 6.2 of the existing MPL allows a transparent upgrade procedure, so I think the proliferation aspect of this license update doesn’t need to be stressed. They’re doing the right thing. The content of the license change isn’t firmly fixed yet: Mozilla is still in the comment phase. Results are expected later in 2010. I’m looking forward to meeting some of the people driving the process in Mozilla next month, for a chat over a glass of wine as to which bits of compatibility are the most important.

So here’s to licenses; let a thousand choices bloom.

PS. Ideally, I think that each license would make a clear statement about what it means in each of the essential areas of licensing. Unfortunately, those “essential areas” have changed over the years, so many do not do so. I hope for a clear new world where we have a small collection of modern licenses (say, Apache v2, GPLv3, MPLv2 and a new permissive license) that define the main species of Free Software.

PPS. Although I think that this applies to every blog post, I think I should add explicitly here: this post does not reflect an official FSFE position on the Mozilla license.