Bradley M. Kuhn's Blog

2010

August

• 2010-08-27: The Saga of Sun RPC

  I first became aware of the Sun RPC license in mid-2001, but my email archives from the time indicate the issue predated my involvement with it; it'd been an issue of consideration since 1994. I later had my first large email thread “free-for-all” on the issue in April 2002, which was the first of too many that I'd have before it was all done. In December 2002, the Debian bug was filed, and then it became a very public debate. Late last week, it was finally resolved. It now ranks as the longest standing Free Software licensing problem of my career. A cast of dozens deserve credit for getting it resolved.

  Tom “spot” Callaway does a good job summarizing the recent occurrences on this issue (and by recent, I mean since 2005 — it's been going long enough that five years ago is “recent”), and its final resolution. So, I won't cover that recent history, but I encourage people to read Spot's summary. Simon Phipps, who worked on this issue during his time as the Chief Open Source Officer of Sun, also wrote about his work on the issue. For my part, I'll try to cover the “middle” part of the story from 2001-2005.

  So, the funny thing about this license is everyone knew it was Sun's intention to make it Free Software. The code is so old, it dates back to a time when the drafting of Free Software licenses weren't well understood (old-schoolers will, for example, remember the annoying advertising clause in early BSD licenses). Thus, by our modern standards, the Sun RPC license does appear on its face as trivially non-Free, but in its historical context, the intent was actually clear, in my opinion.

  Nevertheless, by 2002, we knew how to look at licenses objectively and critically, and it was clear to many people that the license had problems. Competing legal theories existed, but the concerns of Debian were enough to get everyone moving toward a solution.

  For my part, I checked in regularly during 2002-2004 with Danese Cooper (who was, effectively, Simon Phipps' predecessor at Sun), until I was practically begging her to pay attention to the issue. While I could frequently get verbal assurances from Danese and other Sun officials that it was their clear intention that glibc be permitted to include the code under the LGPL, I could never get something in writing. I had a hundred other things to worry about, and eventually, I stopped worrying about it. I remember thinking at the time: well, I've notes on all these calls and discussions I've had with Sun people about the license. Worst case scenario: I'll have to testify to this when Sun sues some Free Software project, and there will be a good estoppel defense.

  Meanwhile, around early 2004, my friend and colleague at FSF, David “Novalis” Turner took up the cause in earnest. I think he spent a year or two as I did: desperately trying to get others to pay attention and solve the problem. Eventually, he left FSF for other work, and others took up the cause, including Brett Smith (who took over Novalis' FSF job), and, by that time, Spot was also paying attention to this. Both Brett and Spot worked hard to get Simon Phipps attention on it, which finally happened. But around then began that long waiting period while Oracle was preparing to buy Sun. It stopped almost anything anyone wanted to get done with Sun, so everyone just waited (again). It was around that time that I decided I was pretty sure I never wanted to hear the phrase: “Sun RPC license” again in my life.

  Meanwhile, Richard Fontana had gone to work for Red Hat, and his self-proclaimed pathological obsession with Free Software (which can only be rivaled by my own) led him to begin discussing the Sun RPC issue again. He and Spot were also doing their best negotiating with Oracle to get it fixed. They took us the last miles of this marathon, and now the job is done.

  I admit that I feel of some shame that, in recent years, I've had such fatigue about this issue — a simple one that should've been solved a decade and a half ago — that, since 2008, I've done nothing but kibitz about the issue when people complained. I also didn't believe that a company as disturbing and anti-Free-Software as Oracle could ever be convinced to change a license to be more FaiF. Spot and Fontana proved me wrong, and I'm glad.

  Thanks to everyone in this great cast of characters that made this ultimately beneficial production of licensing theater possible. I've been honored that I shared the stage in the first few acts, and sorry that I hid backstage for the last few. It was right to keep working on it until the job was done. As Fontana said: Estoppel may be relevant but never enough; software freedom principle[s] should matter as much as legal risk. … [the] standard for FaiF can't simply be ‘good defense to copyright infringement likely’. Thanks to everyone; I'm so glad I no longer have to wait in fear of a subpoena from Oracle in a lawsuit claiming infringement of their Sun RPC copyrights.

  

  Posted on Friday 27 August 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-08-16: Considerations For FLOSS Hackers About Oracle vs. Google

  Many have already opined about the Oracle v. Google lawsuit filed last week. As you might expect, I'm not that worried about what company sues what company for some heap of cash; those sort of for-profit wranglings just aren't what concerns me. Rather, I'm focused on what this event means for the future of software freedom. And, I think even at this early stage of the lawsuit, there are already a few lessons for the Free Software community to learn.

  Avoid Single-Company-Controlled Language Infrastructure

  Fourteen months ago, before the Oracle purchase of Sun, I wrote about the specific danger of language infrastructure developed by a single for-profit patent-holding entity (when such infrastructure is less than 20 years old). In that blog post, I wrote:

  [Some] might argue that with all those patents consolidated [in a single company], patent trolls will have a tough time acquiring patents and attacking FaiF implementations. However, while this can sometimes be temporarily true, one cannot rely on this safety. Java, for example, is in a precarious situation now. Oracle is not a friend to Free Software, and soon will hold all Sun's Java patents — a looming threat to FaiF Java implementations … [A]n Oracle attack on FaiF Java is a possibility.

  I'm sorry that I was right about this, but we should now finally learn the lesson: languages like Java and C# are dangerous. Single companies developed them, and there are live, unexpired patents that can easily be used in a group to attack FaiF implementations. Of course, that doesn't mean other language infrastructures are completely safe from patents, but I believe there is greater relative risk of a system with patent consolidation at a single company.

  It also bears repeating the point I made on Linux Outlaws last July: this doesn't mean the Free Software community shouldn't have FaiF implementations of all languages. In fact, we absolutely should, because we do want developers who are familiar with those languages to bring their software over to GNU/Linux and other Free Software systems.

  However, this lawsuit proves that choosing some languages for newly written Free Software is dangerous and should be avoided, especially when there are safer choices like C, C++, Python, and Perl⁰. (See my blog post from last year for more on this subject.)

  Never Let Your Company File for Patents on Your Work

  James Gosling is usually pretty cryptic in his non-technical writing, but I think if you read carefully, it seems to me that Gosling regrets that Oracle now holds his patents on Java. I know developers get nice bonuses if they let their company apply for patents on their work. I also know there's pressure in most large companies to get more patents. We, as developers, must simply refuse this. We invent this stuff, not the suits and the lawyers who want to exploit our work for larger and larger profits. As a community of developers and computer scientists, we must simply refuse to ever let someone patent our work. In a phrase: just say no.

  Even if you like your company today, you never know who will own those software patents later. I'm sure James Gosling originally never considered the idea that a company as revolting as Oracle would have control of everything he's invented for the last two decades. But they do, and there's nothing Gosling can do about what's done with his work and “inventions”. Learn from this example; don't let your company patent your work. Instead, publish online to establish prior art as quickly as possible.

  Google Is Not Merely a Pure Free Software Distributor

  Google has worked hard to cast themselves as innocent, Free-Software-producing victims. That's good PR because it's true, but it's also not telling the whole truth. Google worked hard to make sure Android was completely Apache-2.0 (or even more permissively) licensed (except for Linux, of course). There was already plenty Java stuff available under the GPL that Google could have used. Sadly, Google was so allergic to GPL for Android/Linux that they even avoided LGPL'd components like uClibc and glibc (in favor of their own permissively-licensed C library based on a BSD version).

  Google's reason for permissive-only licensing for “everything but the kernel” was likely a classic “adoption is more important than software freedom” scenario. Google wants Android/Linux in as many phones as possible, and wants to eliminate any “barrier” to such adoption, even if such a “barrier” would defend software freedom.

  This new lawsuit would be much more interesting if Google had chosen GPL and/or LGPL for Android. In fact, if I fantasize about being empowered to design a binding, non-financial settlement to the lawsuit, the first item on my list would be a relicense of all future Android/Linux systems under GPL and/or LGPL. (Basically, Google would license only enough under LGPL to allow proprietary applications, and license all the rest as GPL, thus yielding the same licensing consequences as GNU/Linux and GNOME). Then, I'd have Oracle explicitly license all its patents under GPL and/or LGPL compatible licenses that would permit Android/Linux to continue unencumbered, but under copyleft. (BTW, Mark Wielaard has a blog post that discussed more about the issue of GPL'd/LGPL'd Java implementations and how they relate to this lawsuit.)

  I realize that's never going to happen, but it's an interesting thought experiment. I am of course opposed to software patents, and I certainly oppose companies like Oracle that produce almost all proprietary software. However, I can at least understand the logic of Oracle not wanting its software patents exercised in proprietary software. I think a trade off, whereby all software patents are licensed freely and royalty-free only for use in copylefted software is a reasonable compromise. OTOH, knowing Oracle, they could easily have plans to attack copyleft implementations too. Thus, we must assume they won't accept this reasonable compromise of “royalty-free licensing for copyleft only”. That brings me to my next point of FaiF hackers' concern about this lawsuit.

  Never Trust a Mere Patent Promise; Demand Real Patent Licenses

  I wrote after Bilski that patent promises just aren't enough, and this lawsuit is an example of why. I presume that Oracle's lawyers have looked carefully as the various promises and assurances that Sun made about its Java patents and have concluded Oracle has good arguments for why those promises don't apply to Android. I have no idea what those arguments are, but rarely do lawyers file a lawsuit without very good arguments already prepared. I hope Oracle's lawyers' arguments are wrong and they lose. But, the fact that Oracle even has a credible argument that Android/Linux doesn't already have a patent license shows again that patent promises are just not enough.

  Miguel de Icaza used this opportunity to point out how the Microsoft C# promises are “better” by comparison, in his opinion. But, Brett Smith at FSF already found huge holes in those Microsoft promises that haven't been fixed. In fact, any company making these promises always tries to hide as much nasty stuff as it can, to convince the users that they are safe from patent aggression when they really aren't. That's why the Free Software community must demand simple, clear, and permanent royalty-free patent licenses for all patents any company might hold. We should accept nothing less. As mentioned above, those licenses could perhaps require that a certain Free Software copyright license, such as GPLv3-or-later, be used for any software that gets the advantage of the license. (i.e., I can certainly understand if companies don't want to accidentally grant such patent licenses to their proprietary software competitors).

  Indeed, it's particularly important that the licenses cover all patents and those possibly exercised in future improvements in the software. This lawsuit has clearly shown that even if patent pools exist for some subsets of patents for some subsets of Free Software, patent holders will either use other patents for aggression, or they'll assert patents in the patent pools against Free Software that's not part of the pool. In essence, we must assume that any for-profit company will become a patent troll eventually (they always do), and therefore any cross-licensing pools that don't include every patent possible for any possible Free Software will always be inadequate. So, the answer is simple: trust no software-patent-holding company unless they give an explicit GPLv3-compatible license for all their patents.

  We Must End Software Patents

  The failure of the Bilski case to end software patents in the USA means much work lies ahead to end software patents. The End Software Patents Wiki has some good stuff about this case as well as lots of other information related to software patents. There are now heavily funded for-profit corporate efforts that seek to convince the Free Software community that patent reform is enough. But, it's not! For example, if you see presenters at FLOSS conferences claiming to have solutions to patent problems, ask them if their organization opposes all software patents, and ask them if their funders license all their patents freely for GPLv3-or-later software implementations. If you hear the wrong answers, then their motives and mission are suspect.

  Finally, I'd like to note that, in some sense, these patent battles help Free Software, because it may actually teach companies that the expense of having software patents is not worth the risk of patent lawsuits. It's possible we've reached a moment in history where it'd be better if the Software Patent Cold War becomes a full Software Patent Nuclear War. Software freedom can survive that “nuclear winter”. I sometimes think that in the Free Software community, we may find ourselves left with just two choices: fifty more years of Patent Cold War (with lots of skirmishes like this one), or ten years of full-on patent war (after which companies would beg Congress to end software patents). Both outcomes are horrible until they're resolved, but the latter would reach resolution quicker. I often wonder which one is the better long term for software freedom.

  But, no matter what happens next, the necessary position is: all software patents are bad for software freedom. Any entity that supports anything short of full abolition of software patents is working against software freedom.

  

  ---

  ⁰I originally had PHP listed here, but jwildeboer argued that Zend Technologies, Ltd. might be a problem for PHP in the same way Oracle is for Java and Microsoft for C#. It's true that Zend is a software patent holder and was involved in the development of later PHP versions. I don't think the single-company-controlled software patent risks with PHP are akin to those of Java and C#, since Zend Technologies isn't the only entity involved in PHP's development, but certainly the other languages listed are likely preferable to PHP.

  Posted on Monday 16 August 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-08-13: GNOME Copyright Assignment Policy

  Vincent Untz announced and blogged today about the GNOME Copyright Assignment Policy and a longer guidelines document about the GNOME policy. I want to thank both Vincent and Michael Meeks for their work with me on this policy.

  As I noted in my blog last week, GUADEC really reminded me how great the GNOME community is. Therefore, it's with great pride that I was able to assist on this important piece of policy for the GNOME community.

  There are a lot of forces in the corporate side of Free Software right now that are aggressively trying to convince copylefted projects to begin assigning copyright of their code (or otherwise agree to CLAs) to corporations without any promises that the code will remain Free Software. We must resist this pressure: copyleft, when used correctly, is the force that keeps equality in the community, as I've written about before.

  I thank the GNOME Board of Directors for entrusting us to write the policy, and am glad they have adopted it.

  

  Posted on Friday 13 August 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-08-10: May They Make Me Superfluous

  The Linux Foundation announced today their own FLOSS license compliance program, which included the launch of a few software tools under a modified BSD license. They also have offered some training courses for those that want to learn how to comply.

  If this Linux Foundation (LF) program is successful, I may get something I've wished for since the first enforcement I ever worked on back in late 1998: I'd like to never do GPL enforcement again. I admit I talk a lot about GPL enforcement. It's indeed been a major center of my work for twelve years, but I can't say I've ever really liked doing it.

  By contrast, I have been hoping for years that someone would eventually come along and “put me out of the enforcement business”. Someday, I dream of opening up the <gpl@busybox.net> folder and having no new violation reports (BTW, those dreams usually become real-life nightmares, as I typically get two new violations reports each week). I also wish for the day that I don't have a backlogged queue of 200 or more GPL violations where no source nor offer for source has been provided. I hate that it takes so much time to resolve violations because of the sheer magnitude that exist.

  I got into GPL enforcement so heavily, frankly, because so few others were doing it. To this day, there are basically three groups even bothering to enforce GPL on behalf of the community: Conservancy (with enforcement efforts led by me), FSF (with enforcement efforts led by Brett Smith), and gpl-violations.org (with enforcement efforts led by Harald Welte). Generally, GPL enforcement has been a relatively lonely world for a long time, mainly because it's boring, tedious and patience-trying work that only the most dedicated (masochistic?) want to spend their time doing.

  There are a dozen of very important software-freedom-advancing activities that I'd rather spend my time doing. But as long as people don't respect the freedom of software users and ignore the important protections of copyleft, I have to continue doing GPL enforcement. Any effort like LF's is very welcome, provided that it reduces the number of violations.

  Of course, LF (as GPL educators) and Brett, Harald, and I (as GPL enforcers) will share the biggest obstacle: getting communication going with the actual violators. Fact is, people who know the LF exists or have heard of the GPL are likely to already be in compliance. When I find a new violation, it's nearly always someone who doesn't even know what's going on, and often doesn't even realize what their engineering team put into their firmware. If LF can reach these companies before they end up as a violation report emailed to me, I'll be as glad as can be. But it's a tall order.

  I do have a few minor criticisms of LF's program. First, I believe the directory of FLOSS Compliance Officers should be made publicly available. I think FLOSS Compliance Officers at companies should make themselves publicly known in the software freedom community so they can be contacted directly. As LF currently has it set up, you have to make a request of the LF to put you in touch with a company's compliance officer.

  Second, I admit I'd have liked to have been actively engaged in LF's process of forming this program. But, I presume that they wanted as much distance as possible from the world's most prolific GPL enforcer, and I can understand that. (I suppose there's a good cop/bad cop metaphor you could make here, but I don't like to think of myself as the GPL police.) I did offer to help LF on this back in April when they announced it at the Linux Collaboration Summit, but they haven't been in touch. Nevertheless, I'll hopefully meet with LF folks on Thursday at LinuxCon about their program. Also, I was invited a few months ago by Martin Michlmayr to join one subset of the project, the SPDX working group and I've been giving it time whenever I can.

  But, as I said, those are only minor complaints. The program as a whole looks like it might do some good. I hope companies take advantage of it, and more importantly, I hope LF can reach out to the companies who don't know their name yet but have BusyBox/Linux embedded in their products.

  Please, LF, help free me from the grind of GPL enforcement work. I remain committed to enforcing GPL until there are no violations left, but if LF can actually bring about an end to GPL violations sooner rather than later, I'll be much obliged. In a year, if I have an empty queue of GPL violations, I'll call LF's program a unmitigated success and gladly move on to other urgent work to advance software freedom.

  

  Posted on Tuesday 10 August 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-08-09: “Have To” Is a Relative Phrase

  I often hear it. I have to use proprietary software, people say. But usually, that's a justification and an excuse. Saying have to implies that they've been compelled by some external force to do it.

  It begs the question: Who's doing the forcing? I don't deny there might be occasions with a certain amount of force. Imagine if you're unemployed, and you've spent months looking for a job. You finally get one, but it generally doesn't have anything to do with software. After working a few weeks, your boss says you have to use a Microsoft Windows computer. Your choices are: use the software or be fired and spend months again looking for a job. In that case, if you told me you have to use proprietary software, I'd easily agree.

  But, imagine people who just have something they want to do, completely unrelated to their job, that is made convenient with proprietary software. In that case, there is no have to. One doesn't have to do a side project. So, it's a choice. The right phrase is wanted to, not have to.

  Saying that you're forced to do something when you really aren't is a failure to take responsibility for your actions. I generally don't think users of proprietary software are primarily to blame for the challenges of software freedom — nearly all the blame lies with those who write, market, and distribute proprietary software. However, I think that software users should be clear about why they are using the software. It's quite rare for someone to be compelled under threat of economic (or other) harm to use proprietary software. Therefore, only rarely is it justifiable to say you have to use proprietary software. In most cases, saying so is just making an excuse.

  As for being forced to develop proprietary software, I think it's even rarer yet. Back in 1991 when I first read the GNU Manifesto, I was moved by RMS' words about the issue:

  “Won't programmers starve?”

  I could answer that nobody is forced to be a programmer. Most of us cannot manage to get any money for standing on the street and making faces. But we are not, as a result, condemned to spend our lives standing on the street making faces, and starving. We do something else.

  But that is the wrong answer because it accepts the questioner's implicit assumption: that without ownership of software, programmers cannot possibly be paid a cent. Supposedly it is all or nothing.

  Well, even if it is all or nothing, RMS was actually right about this: we can do something else. By the mid 1990s, these words had inspired me to make a lifelong plan to make sure I'd never have to write or support proprietary software again. Despite being trained primarily as a computer scientist, I've spent much time building contingency plans to make sure I wouldn't be left with proprietary software support or development as my only marketable skill.

  During the 1990s, it wasn't clear that software freedom would have any success at all. It was a fringe activity; Cygnus was roughly the only for-profit company able to employ people to write Free Software. As such, I of course started learning the GCC codebase, figuring that I'd maybe someday get a job at Cygnus. I also started training as an American Sign Language translator, so I'd have a fallback career if I didn't get a job at Cygnus. Later, I learned how to play poker really well, figuring that in a worst case, I could end up as a professional poker player permanently.

  As it turned out, I've never had to rely fully on these fallback plans, primarily because I was hired by the FSF in 1999. For the last eleven years, I have been able to ensure that I've never had a job that required that I use, support, or write proprietary software and I've worked only on activities that directly advanced software freedom. I admit I was often afraid that someday I might be unable to find a job, and I'd have to support, use or write proprietary software again. Yet, despite that fear, since 1997, I've never even been close to that.

  So, honestly, I just don't believe those who say they have to use proprietary software. Almost always, they chose to use it, because it's more convenient than the other things they'd have to do to avoid it. Or, perhaps, they'd rather write or use proprietary software than write or use no software at all, even when avoiding software entirely was a viable option.

  In summary, I want to be clear that I don't judge people who use proprietary software. I realize not everyone wants to live their life as I do — with cascading fallback plans to avoid using, writing or supporting proprietary software. I nevertheless think it's disingenuous to say you have to use, support or develop proprietary software. It's a choice, and every year that goes by, the choice gets easier, so the statement sounds more like an excuse all the time.

  

  Posted on Monday 09 August 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-08-05: GUADEC 2010: Rate Conferences by Inspiration Value

  Conferences are often ephemeral. I've been going to FLOSS conferences since before there were conferences specifically for the topic. In the 1990s, I'd started attending various USENIX conferences. Many of my career successes can be traced back to attending those conferences and meeting key leaders in the FLOSS world. While I know this is true generally, I can't really recall, without reviewing notes specific conferences, what happened at them, and how specifically it helped me personally or FLOSS in general. I know they're important to me and to software freedom, but it's tough to connect the dots perfectly without looking in detail what happened when.

  Indeed, for most of us, after decades, conferences start to run together. At GUADEC this year, I had at least two conversations of the nature: What city was that? What conference was that? Wait, what year was that?. And that was just discussions about past GUADECs specifically, let alone other events!

  For my part, after checking my records, I discovered that I hadn't been to a GUADEC since 2003. I've served as FSF's representative on the GNOME Advisory Board straight through from 2001 until today, but nevertheless I hadn't been able to attend GUADECs from 2004-2009. Thus, the 2010 GUADEC was somewhat of a reintroduction for me to the in-person GNOME community.

  With fresh eyes, what I saw had great impact on me. GNOME seems to be a vibrant, healthy community, with many contributors and incredible diversity in both for-profit and volunteer contributions. GNOME's growth and project diversity has greatly exceeded what I would have expected to see between 2004 and 2010.

  It's not often I go to a conference and am jealous that I can't be more engaged as a developer. I readily admit that I haven't coded regularly in more than a decade (and I often long to do it again). But, I usually talk myself out of it when I remember the difficultly of getting involved and in shepherding work upstream. It's a non-trivial job, and some don't even bother. The challenges are usually enough to keep the enticement at bay.

  Yet, I left GUADEC 2010 and couldn't see a downside in getting involved. I found myself on the flight back wishing I could do more, thinking through the projects I saw and wondering how I might be a coder again. There must be some time on the weekends somewhere, I thought, and while I'm not a GUI programmer, there's plenty of system stuff in GNOME like dbus and systemd; surely I can contribute there.

  Fact is, I've got too many other FLOSS-world responsibilities and I must admit I probably won't contribute code, despite wanting to. What's amazing, though, is that everything about GUADEC made me want to get more involved and there appeared no downside in doing so. There's something special about a conference (and a community) that can inspire that feeling in a hardened, decade-long conference attendee. I interact with a lot of FLOSS communities, and GNOME is probably the most welcoming of all.

  The rest of this post is a random bullet list of cool things that happened at GUADEC that I witnessed/heard/thought about:

  • There was a lot of debate and concern about the change in the GNOME 3 release schedule. I was impressed at the community unity on this topic when I heard a developer say in the hall: The change in GNOME 3 schedule is bad for me, but it's clearly the right thing for GNOME, so I support it. That's representative of the “all for one” and selfless attitude you'll find in the GNOME community.
  • Dave Neary presented a very interesting study on GNOME code contributions, which he was convinced to release under CC-By-SA. The study has caused some rancor in the community about who does or does not contribute to GNOME upstream, but generally speaking, I'm glad the data is out there, and I'm glad Dave's released it under a license that allows people to build on the work and reproduce and/or verify the results. (Dave's also assured me he'll release the tools and config files and all other materials under FaiF licenses as well; I'll put a link here when he has one.) Thing is, the most important and wonderful datum from Dave's study is that a plurality of GNOME contribution comes from volunteers: a full 23%! I think every FLOSS project needs a plurality of volunteer contribution to truly be healthy, and it seems GNOME has it.
  • My talk on GPLv3 was reasonably well received, notwithstanding some friendly kibitzing from Michael Meeks. There had been push back in previous discussions in the GNOME community about GPLv3. It seems now, however, that developers are interested in the license. It's not my goal to force anyone to switch, but I hope that my talk and my participation in this recent LGPLv3 thread on desktop-list might help to encourage a slow-but-sure migration to GPLv3-or-later (for applications) and (GPLv2|LGPLv3-or-later) (for platform libraries) in GNOME. If folks have questions about the idea, I'm always happy to discuss them.
  • I enjoyed rooming with Brad Taylor. We did wonder, though, if the GNOME Travel Committee assigned us rooms by similar first names. (In fact, I was so focused that on the fact that we shared the same first name, I previously had typed Brad's last name wrong here!) I liked hearing about his TomBoy online project, Snowy. I'm obviously delighted to see adoption of AGPLv3, the license I helped create. I've promised Brad that I'll try to see if I can convince the org-mode community to use Snowy for its online storage as well.
  • Owen Taylor demoed and spoke about GNOME Shell 3.0. I don't use GUIs much myself, but I can see how GUI-loving users will really enjoy this excellent work.
  • I met Lennart Poettering and discussed with him in detail the systemd project. While I can see how this could be construed as a Canonical/Red Hat fight over the future of what's used for system startup, I still was impressed with Lennart's approach technically, and find it much healthier that his community isn't requiring copyright assignment.
  • Emmanuele Bassi's talk on Clutter was inspiring, as he delivered heartfelt slide indicating that he'd overcome the copyright assignment requirements and assignment is no longer required by Intel for Clutter upstream contributions. I like to believe that Vincent Untz's, Michael Meeks' and my work on the (yet to be ratified) GNOME Copyright Assignment Policy was a help to Emmanuele's efforts in this regard. However, it sounds to me like the outcome was primarily due to a lot of personal effort on Emmanuele's part internally to get Intel to DTRT. I thank him for this effort and congratulate him on that success.
  • It was great to finally meet Fabian Scherschel in person. He kindly brought me some gifts from Germany and I brought him some gifts from the USA (we prearranged it; I guess that's the “outlaw” version of gifts). Fab also got some good interviews for the Linux Outlaws podcast that he does with Dan Lynch. It seems that podcast has been heavily linked to in the GNOME community, which is really good for Dan and Fab and for GNOME, I think.
  

  That's about all the random thoughts and observations I have from GUADEC. The conference was excellent, and I think I simply must readd it to my “must attend each year” list.

  Finally, I want to thank the GNOME Foundation for sponsoring my travel costs. It allowed me to take some vacation time from my day job to attend and participate in GUADEC.

  Posted on Thursday 05 August 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-08-03: More GPL Enforcement Progress

  LWN is reporting a GPL enforcement story that I learned about during last week while at GUADEC (excellent conference, BTW, blog post on that later this week). I wasn't sure if it was really of interest to everyone, but since it's hit the press, I figured I'd write a brief post to mention it.

  As many probably know, I'm president of the Software Freedom Conservancy, which is the non-profit organizational home of the BusyBox project. As part of my role at Conservancy, I help BusyBox in its GPL enforcement efforts. Specifically and currently, the SFLC is representing Conservancy in litigation against a number of defendants who have violated the GPL and were initially unresponsive to Conservancy's attempts to bring them into compliance with the terms of the license.

  A few months ago, one of those defendants, Westinghouse Digital Electronics, LLC, stopped responding to issues regarding the lawsuit. On Conservancy's behalf, SFLC asked the judge to issue a default judgment against them. A “default” means what it looks like: Conservancy asked to “win by default” since Westinghouse stopped showing up. And, last week, Conservancy was granted a default judgment against Westinghouse, which included an injunction to stop their GPL-non-compliant distributions of BusyBox.

  “Injunctive Relief”, as the lawyers call it, is a really important thing for GPL enforcement. Obviously our primary goal is full compliance with the GPL, which means giving the complete and corresponding source code (C&CS, as I tend to abbreviate it) to all those who received binary distributions of the software. Unfortunately, in some cases (for example, when a company simply won't cooperate in the process despite many efforts to convince them to do so), the only option is to stop further distribution of the violating software. As many parts of the GPL itself point out, it's better to not have software distributed at all, if it's only being distributed as (de facto) proprietary software.

  I'm really glad that a judge has agreed that the GPL is important enough a license to warrant an injunction on out-of-compliance distribution. This is a major step forward in GPL enforcement in the USA. (Please note that Harald Welte had past similar successes in Germany, and deserves credit and kudos for getting this done the first time in the world. This success follows in his footsteps.)

  

  Posted on Tuesday 03 August 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

July

• 2010-07-15: At Least Motorola Admits It

  I've written before about the software freedom issues inherent with Android/Linux. Summarized shortly: the software freedom community is fortunate that Google released so much code under Free Software licenses, but since most of the code in the system is Apache-2.0 licensed, we're going to see a lot of proprietarized, non-user-upgradable versions. In fact, there's no Android/Linux system that's fully Free Software yet. (That's why Aaron Williamson and I try to keep the Replicant project going. We've focused on the HTC Dream and the NexusOne, since they are the mobile devices closest to working with only Free Software installed, and because they allow the users to put their own firmware on the device.)

  I was therefore intrigued to discover last night (via mtrausch) a February blog post by Lori Fraleigh of Motorola, wherein Fraleigh clarifies Motorola's opposition to software freedom for its Android/Linux users:

  We [Motorola] understand there is a community of developers interested in … Android system development … For these developers, we highly recommend obtaining either a Google ADP1 developer phone or a Nexus One … At this time, Motorola Android-based handsets are intended for use by consumers.

  I appreciate the fact that Fraleigh and Motorola are honest in their disdain for software developers. Unlike Apple — who tries to hide how developer-unfriendly its mobile platform is — Motorola readily admits that they seek to leave developers as helpless as possible, refusing to share the necessary tools that developers need to upgrade devices and to improve themselves, their community, and their software. Companies like Motorola and Apple both seek to squelch the healthy hacker tendency to make technology better for everyone. Now that I've seen Fraleigh's old blog post, I can at least give Motorola credit for full honesty about these motives.

  I do, however, find the implication of Fraleigh's words revolting. People who buy the devices, in Motorola's view, don't deserve the right to improve their technology. By contrast, I believe that software freedom should be universal and that no one need be a “mere consumer” of technology. I believe that every technology user is a potential developer who might have something to contribute but obviously cannot if that user isn't given the tools to do so. Sadly, it seems, Motorola believes the general public has nothing useful to contribute, so the public shouldn't even be given the chance.

  But, this attitude is always true for proprietary software companies, so there are actually no revelations on that point. Of more interest is how Motorola was able to do this, given that Android/Linux (at least most of it) is Free Software.

  Motorola's ability to take these actions is a consequence of a few licensing issues. First, most of the Android system is under the Apache-2.0 license (or, in some cases, an even more permissive license). These licenses allow Motorola to make proprietary versions of what Google released and sell it without source code nor the ability for users to install modified versions. That license decision is lamentable (but expected, given Google's goals for Android).

  The even more lamentable licensing issue here is regarding Linux's license, the GPLv2. Specifically, Fraleigh's post claims:

  The use of open source software, such as the Linux kernel … in a consumer device does not require the handset running such software to be open for re-flashing. We comply with the licenses, including GPLv2.

  I should note that, other than Fraleigh's assertion quoted above, I have no knowledge one way or another if Motorola is compliant with GPLv2 on its Android/Linux phones. I don't own one, have no plans to buy one, and therefore I'm not in receipt of an offer for source regarding the devices. I've also received no reports from anyone regarding possible non-compliance. In fact, I'd love to confirm their compliance: please get in touch if you have a Motorola Android/Linux phone and attempted to install a newly compiled executable of Linux onto your phone.

  I'm specifically interested in the installation issue because GPLv2 requires that any binary distribution of Linux (such as one on telephone hardware) include both the source code itself and the scripts to control compilation and installation of the executable. So, if Motorola wrote any helper programs or other software that installs Linux onto the phones, then such software, under GPLv2, is a required part of the complete and corresponding source code of Linux and must be distributed to each buyer of a Motorola Android/Linux phone.

  If you're surprised by that last paragraph, you're probably not alone. I find that many are confused regarding this GPLv2 nuance. I believe the confusion stems from discussions during the GPLv3 process about this specific requirement. GPLv3 does indeed expand the requirement for the scripts to control compilation and installation of the executable into the concept of Installation Information. Furthermore, GPLv3's Installation Information is much more expansive than merely requiring helper software programs and the like. GPLv3's Installation Information includes any material, such as an authorization key, that is necessary for installation of a modified version onto the device.

  However, merely because GPLv3 expanded installation information requirements does not lessen GPLv2's requirement of such. In fact, in my reading of GPLv2 in comparison to GPLv3, the only effective difference between the two on this point relates to cryptographic device lock-down. I do admit that under GPLv2, if you give all the required installation scripts, you could still use cryptography to prevent those scripts from functioning without an authorization key. Some vendors do this, and that's precisely why GPLv3 is written the way that it is: we'd observed such lock-down occurring in the field, and identified that behavior as a bug in GPLv2 that is now closed with GPLv3.

  However, because of all that hype about GPLv3's new Installation Information definition, many simply forgot that the GPLv2 isn't silent on the issue. In other words, GPLv3's verbosity on the subject led people to minimize the important existing requirements of GPLv2 regarding installation information.

  As regular readers of this blog know, I've spent much of my time for the last 12 years doing GPL enforcement. Quite often, I must remind violators that GPLv2 does indeed require the scripts to control compilation and installation of the executable, and that candidate source code releases missing the scripts remain in violation of GPLv2. I sincerely hope that Android/Linux redistributors haven't forgotten this.

  I have one final and important point to make regarding Motorola's February statement: I've often mentioned that the mobile industry's opposition to GPLv3 and to user-upgradable devices is for their own reasons, and nothing to do with regulators or other outside entities preventing them from releasing such software. In their blog post, Motorola tells us quite clearly that the community of developers interested in … experimenting with Android system development and re-flashing phones … [should obtain] either a Google ADP1 developer phone or a Nexus One, both of which are intended for these purposes. In other words, Motorola tacitly admits that it's completely legal and reasonable for the community to obtain such telephones, and that, in fact, Google sells such devices. Motorola was not required to put lock-down restrictions in place, rather they made a choice to prohibit users in this way. On this point, Google chose to treat its users with respect, allowing them to install modified versions. Motorola, by contrast, chose to make Android/Linux as close to Apple's iPhone as they could get away with legally.

  So, the next time a mobile company tries to tell you that they just can't abide by GPLv3 because some third party (the FCC is their frequent scapegoat) prohibits them, you should call them on their FUD. Point out that Google sells phones on the open market that provide all Installation Information that GPLv3 might require. (In other words, even if Linux were GPLv3'd, Android/Linux on the NexusOne and HTC Dream would be a GPLv3-compliant distribution.) Meanwhile, at least one such company, Motorola, has admitted their solitary reason for avoiding GPLv3: the company just doesn't believe users deserve the right to install improved versions of their software. At least they admit their contempt for their customers.

  Update (same day): jwildeboer pointed me to a few posts in the custom ROM and jailbreaking communities about their concerns about Motorola's new offering, the Droid-X. Some commentors there point out that eventually, most phones get jailbroken or otherwise allow user control. However, the key point of the CrunchGear User Manifesto is a clear and good one: no company or person has the right to tell you that you may not do what you like with your own property. This is a point akin and perhaps essential to software freedom. It doesn't really matter if you can figure out to how to hack a device; what's important is that you not give your money to the company that prohibits such hacking. For goodness sake, people, why don't we all use ADP1's and NexusOne's and be done with this?

  Updated (2010-07-17): It appears that cryptographic lock down on the Droid-X is confirmed (thanks to rao for the link). I hope everyone will boycott all Motorola devices because of this, especially given that there are Android/Linux devices on the market that aren't locked down in this way.

  BTW, in Motorola's answer to Engadget on this, we see they are again subtly sending FUD that the lock-down is somehow legally required:

  Motorola's primary focus is the security of our end users and protection of their data, while also meeting carrier, partner and legal requirements.

  I agree the carriers and partners probably want such lock down, but I'd like to see their evidence that there is a legal restriction that requires that. They present none.

  Meanwhile, they also state that such cryptographic lock-down is the only way they know how to secure their devices:

  Checking for a valid software configuration is a common practice within the industry to protect the user against potential malicious software threats. Pity that Motorola engineers aren't as clueful as the Google and HTC engineers who designed the ADP1 and Nexus One.

  

  Posted on Thursday 15 July 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-07-07: Proprietary Software Licensing Produces No New Value In Society

  I sought out the quote below when Chris Dodd paraphrased it on Meet The Press on 25 April 2010. (I've been, BTW, slowly but surely working on this blog post since that date.) Dodd was quoting Frank Rich, who wrote the following, referring to the USA economic system (and its recent collapse):

  As many have said — though not many politicians in either party — something is fundamentally amiss in a financial culture that thrives on “products” that create nothing and produce nothing except new ways to make bigger bets and stack the deck in favor of the house. “At least in an actual casino, the damage is contained to gamblers,” wrote the financial journalist Roger Lowenstein in The Times Magazine last month. This catastrophe cost the economy eight million jobs.

  I was drawn to this quote for a few reasons. First, as a poker player, I've spend some time thinking about how “empty” the gambling industry is. Nothing is produced; no value for humans is created; it's just exchanging of money for things that don't actually exist. I've been considering that issue regularly since around 2001 (when I started playing poker seriously). I ultimately came to a conclusion not too different from Frank Rich's point: since there is a certain “entertainment value”, and since the damage is contained to those who chose to enter the casino, I'm not categorically against poker nor gambling in general, nor do I think they are immoral. However, I also don't believe gambling has any particular important value in society, either. In other words, I don't think people have an inalienable right to gamble, but I also don't think there is any moral reason to prohibit casinos.

  Meanwhile, I've also spent some time applying this idea of creating nothing and producing nothing to the proprietary software industry. Proprietary licenses, in many ways, are actually not all that different from these valueless financial transactions. Initially, there's no problem: someone writes software and is paid for it; that's the way it should be. Creation of new software is an activity that should absolutely be funded: it creates something new and valuable for others. However, proprietary licenses are designed specifically to allow a single act of programming generate new revenue over and over again. In this aspect, proprietary licensing is akin to selling financial derivatives: the actual valuable transaction is buried well below the non-existent financial construction above it.

  I admit that I'm not a student of economics. In fact, I rarely think of software in terms of economics, because, generally, I don't want economic decisions to drive my morality nor that of our society at large. As such, I don't approach this question with an academic economic slant, but rather, from personal economic experience. Specifically, I learned a simple concept about work when I was young: workers in our society get paid only for the hours that they work. To get paid, you have to do something new. You just can't sit around and have money magically appear in your bank account for hours you didn't work.

  I always approached software with this philosophy. I've often been paid for programming, but I've been paid directly for the hours I spent programming. I never even considered it reasonable to be paid again for programming I did in the past. How is that fair, just, or quite frankly, even necessary? If I get a job building a house, I can't get paid every day someone uses that house. Indeed, even if I built the house, I shouldn't get a royalty paid every time the house is resold to a new owner⁰. Why should software work any differently? Indeed, there's even an argument that software, since it's so much more trivial to copy than a house, should be available gratis to everyone once it's written the first time.

  I recently heard (for the first time) an old story about a well-known Open Source company (which no longer exists, in case you're wondering). As the company grew larger, the company's owners were annoyed that the company could only bill the clients for the hour they worked. The business was going well, and they even had more work than they could handle because of the unique expertise of their developers. The billable rates covered the cost of the developers' salaries plus a reasonable profit margin. Yet, the company executives wanted more; they wanted to make new money even when everyone was on vacation. In essence, having all the new, well-paid programming work in the world wasn't enough; they wanted the kinds of obscene profits that can only be made from proprietary licensing. Having learned this story, I'm pretty glad the company ceased to exist before they could implement their make money while everyone's on the beach plan. Indeed, the first order of business in implementing the company's new plan was, not surprisingly, developing some new from-scratch code not covered by GPL that could be proprietarized. I'm glad they never had time to execute on that plan.

  I'll just never be fully comfortable with the idea that workers should get money for work they already did. Work is only valuable if it produces something new that didn't exist in the world before the work started, or solves a problem that had yet to be solved. Proprietary licensing and financial bets on market derivatives have something troubling in common: they can make a profit for someone without requiring that someone to do any new work. Any time a business moves away from actually producing something new of value for a real human being, I'll always question whether the business remains legitimate.

  I've thus far ignored one key point in the quote that began this post: “At least in an actual casino, the damage is contained to gamblers”. Thus, for this “valueless work” idea to apply to proprietary licensing, I had to consider (a) whether or not the problem is sufficiently contained, and (b) whether software or not is akin to the mere entertainment activity, as gambling is.

  I've pointed out that I'm not opposed to the gambling industry, because the entertainment value exists and the damage is contained to people who want that particular entertainment. To avoid the stigma associated with gambling, I can also make a less politically charged example such as the local Chuck E. Cheese, a place I quite enjoyed as a child. One's parent or guardian goes to Chuck E. Cheese to pay for a child's entertainment, and there is some value in that. If someone had issue with Chuck E. Cheese's operation, it'd be easy to just ignore it and not take your children there, finding some other entertainment. So, the question is, does proprietary software work the same way, and is it therefore not too damaging?

  I think the excuse doesn't apply to proprietary software for two reasons. First, the damage is not sufficiently contained, particularly for widely used software. It is, for example, roughly impossible to get a job that doesn't require the employee to use some proprietary software. Imagine if we lived in a society where you weren't allowed to work for a living if you didn't agree to play Blackjack with a certain part of your weekly salary? Of course, this situation is not fully analogous, but the fundamental principle applies: software is ubiquitous enough in industrialized society that it's roughly impossible to avoid encountering it in daily life. Therefore, the proprietary software situation is not adequately contained, and is difficult for individuals to avoid.

  Second, software is not merely a diversion. Our society has changed enough that people cannot work effectively in the society without at least sometimes using software. Therefore, the “entertainment” part of the containment theory does not properly apply¹, either. If citizens are de-facto required to use something to live productively, it must have different rules and control structures around it than wholly optional diversions.

  Thus, this line of reasoning gives me yet another reason to oppose proprietary software: proprietary licensing is simply a valueless transaction. It creates a burden on society and gives no benefit, other than a financial one to those granted the monopoly over that particular software program. Unfortunately, there nevertheless remain many who want that level of control, because one fact cannot be denied: the profits are larger.

  For example, Mårten Mikos recently argued in favor of these sorts of large profits. He claims that to benefit massively from Open Source (i.e., to get really rich), business models like “Open Core” are necessary. Mårten's argument, and indeed most pro-Open-Core arguments, rely on this following fundamental assumption: for FLOSS to be legitimate, it must allow for the same level of profits as proprietary software. This assumption, in my view, is faulty. It's always true that you can make bigger profits by ignoring morality. Factories can easily make more money by completely ignoring environmental issues; strip mining is always very profitable, after all. However, as a society, we've decided that the environment is worth protecting, so we have rules that do limit profit maximization because a more important goal is served.

  Software freedom is another principle of this type. While you can make a profit with community-respecting FLOSS business models (such as service, support and freely licensed custom modifications on contract), it's admittedly a smaller profit than can be made with Open Core and proprietary licensing. But that greater profit potential doesn't legitimatize such business models, just as it doesn't legitimize strip mining or gambling on financial derivatives.

  Update: Based on some feedback that I got, I felt it was important to make clear that I don't believe this argument alone can create a unified theory that shows why software freedom should be an inalienable right for all software users. This factor of lack of value that proprietary licensing brings to society is just another to consider in a more complete discussion about software freedom.

  Update: Glynn Moody wrote a blog post that quoted from this post extensively and made some interesting comments on it. There's some interesting discussion in the blog comments there on his site; perhaps because so many people hate that I only do blog comments on identi.ca (which I do, BTW, because it's the only online forum I'm assured that I'll actually read and respond to.)

  ---

  ⁰I realize that some argue that you can buy a house, then rent it to others, and evict them if they fail to pay. Some might argue further that owners of software should get this same rental power. The key difference, though, is that the house owner can't really make full use of the house when it's being rented. The owner's right to rent it to others, therefore, is centered around the idea that the owner loses some of their personal ability to use the house while the renters are present. This loss of use never happens with software.

  ¹You might be wondering, Ok, so if it's pure entertainment software, is it acceptable for it to be proprietary?. I have often said: if all published and deployed software in the world were guaranteed Free Software except for video games, I wouldn't work on the cause of software freedom anymore. Ultimately, I am not particularly concerned about the control structures in our culture that exist for pure entertainment. I suppose there's some line to be drawn between art/culture and pure entertainment/diversion, but considerations on differentiating control structures on that issue are beyond the scope of this blog post.

  Posted on Wednesday 07 July 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

June

• 2010-06-30: Post-Bilski Steps for Anti-Software-Patent Advocates

  Lots of people are opining about the USA Supreme Court's ruling in the Bilski case. Yesterday, I participated in a oggcast with the folks at SFLC. In that oggcast, Dan Ravicher explained most of the legal details of Bilski; I could never cover them as well as he did, and I wouldn't even try.

  Anyway, as a non-lawyer worried about the policy questions, I'm pretty much only concerned about those forward-looking policy questions. However, to briefly look back at how our community responded to this Bilski situation over the last 18 months: it seems similar to what happened while the Eldred case was working its way to the Supreme Court. In the months preceding both Eldred and Bilski, there seemed to be a mass hypnosis that the Supreme Court would actually change copyright law (Eldred) or patent law (Bilski) to make it better for freedom of computer users.

  In both cases, that didn't happen. There was admittedly less of that giddy optimism before Bilski as there was before Eldred, but the ultimate outcome for computer users is roughly no different in both cases: as we were with Eldred, we're left back with the same policy situation we had before Bilski ever started making its way through the various courts. As near as I can tell from what I've learned, the entire “Bilski thing” appears to be a no-op. In short, as before, the Patent Office sometimes can and will deny applications that it determines are only abstract ideas, and the Supreme Court has now confirmed that the Patent Office can reject such an application if the Patent Office knows an abstract idea when it sees it. Nothing has changed regarding most patents that are granted every day, including those that read on software. Those of us that oppose software patents continue to believe that software algorithms are indeed merely abstract ideas and pure mathematics and shouldn't be patentable subject matter. The governmental powers still seems to disagree with us, or, at least, just won't comment on that question.

  Looking forward, my largest concern, from a policy perspective, is that the “patent reform” crowd, who claim to be the allies of the anti-software-patent folks, will use this decision to declare that the system works. Bilski's patent was ultimately denied, but on grounds that leave us no closer to abolishing software patents. Patent reformists will say: Well, invalid patents get denied, leaving space for the valid ones. Those valid ones, they will say, do and should include lots of patents that read on software. But only the really good ideas should be patented, they will insist.

  We must not yield to the patent reformists, particularly at a time like this. (BTW, be sure to read RMS' classic and still relevant essay, Patent Reform Is Not Enough, if you haven't already.)

  Since Bilski has given us no new tools for abolishing software patents, we must redouble efforts with tools we already have to mitigate the threat patents pose to software freedom. Here are a few suggestions, which I think are actually all implementable by the average developer, to will keep up the fight against software patents, or at least, mitigate their impact:

  • License your software using the AGPLv3, GPLv3, LGPLv3, or Apache-2.0. Among the copyleft licenses, AGPLv3 and GPLv3 offer the best patent protections; LGPLv3 offers the best among the weak copyleft licenses; Apache License 2.0 offers the best patent protections among the permissive licenses. These are the licenses we should gravitate toward, particularly since multiple companies with software patents are regularly attacking Free Software. At least when such companies contribute code to projects under these licenses, we know those particular codebases will be safe from that particular company's patents.
  • Demand real patent licenses from companies, not mere promises. Patent promises are not enough⁰. The Free Software community deserves to know it has real patent licenses from companies that hold patents. At the very least, we should demand unilateral patent licenses for all their patents perpetually for all possible copylefted code (i.e., companies should grant, ahead of time, the exact same license that the community would get if the company had contributed to a yet-to-exist GPLv3'd codebase)¹. Note further that some companies, that claim to be part of the FLOSS community, haven't even given the (inadequate-but-better-than-nothing) patent promises. For example, BlackDuck holds a patent related to FLOSS, but despite saying they would consider at least a patent promise, have failed to do even that minimal effort.
  • Support organizations/efforts that work to oppose and end software patents. In particular, be sure that the efforts you support are not merely “patent reform” efforts hidden behind anti-software patent rhetoric. Here are a few initiatives that I've recently seen doing work regarding complete abolition of software patents. I suggest you support them (with your time or dollars):
    • End Software Patents (a project of FSF),
    • FFII (European-specific), and
    • APRIL (France-specific).
  • Write your legislators. This never hurts. In the USA, it's unlikely we can convince Congress to change patent law, because there are just too many lobbying dollars from those big patent-holding companies (e.g., the same ones that wrote those nasty amicus briefs in Bilski). But, writing your Senators and Congresspeople once a year to remind them of your opposition patents that read on software simply can't hurt, and may theoretically help a tiny bit. Now would be a good time to do it, since you can mention how the Bilski decision convinced you there's a need for legislative abolition of software patents. Meanwhile, remember, it's even better if you show up at political debates during election season and ask these candidates to oppose software patents!
  • Explain to your colleagues why software patents should be abolished, particularly if you work in computing. Software patent abolition is actually a broad spectrum issue across the computing industry. Only big and powerful companies benefit from software patents. The little guy — even the little guy proprietary developer — is hurt by software patents. Even if you can't convince your colleagues who write proprietary software that they should switch to writing Free Software, you can instead convince them that software patents are bad for them personally and for their chances to succeed in software. Share the film, Patent Absurdity, with them and then discuss the issue with them after they've viewed it. Blog, tweet, dent, and the like about the issue regularly.
  • (added 2010-07-01 on tmarble's suggestion) Avoid products from pro-software-patent companies. This is tough to do, and it's why I didn't call for an all-out boycott. Most companies that make computers are pro-software-patent, so it's actually tough to buy a computer (or even components for one) without buying from a pro-software-patent company. However, avoiding the companies who are most aggressive with patent aggression is easy: starting with avoiding Apple products is a good first step (there are plenty of other reasons to avoid Apple anyway). Microsoft would be next on the list, since they specifically use software patents to attack FLOSS projects. Those are likely the big two to avoid, but always remember that all large companies with proprietary software products actively enforce patents, even if they don't file lawsuits. In other words, go with the little guy if you can; it's more likely to be a patent-free zone.
  • If you have a good idea, publish it and make sure the great idea is well described in code comments and documentation, and that everything is well archived by date. I put this one last on my list, because it's more of a help for the software patent reformists than it is for the software patent abolitionists. Nevertheless, sometimes, patents will get in the way of Free Software, and it will be good if there is strong prior art showing that the idea was already thought of, implemented, and put out into the world before the patent was filed. But, fact is, the “valid” software patents with no prior art are a bigger threat to software freedom. The stronger the patent, the worst the threat, because it's more likely to be innovative, new technology that we want to implement in Free Software.

  I sat and thought of what else I could add to this list that individuals can do to help abolish software patents. I was sad that these were the only five six things that I could collect, but that's all the more reason to do these five six things in earnest. The battle for software freedom for all users is not one we'll win in our lifetimes. It's also possible abolition of software patents will take a generation as well. Those of us that seek this outcome must be prepared for patience and lifelong, diligent work so that the right outcome happens, eventually.

  ---

  ⁰ Update: I was asked for a longer write up on software patent licenses as compared to mere “promises”. Unfortunately, I don't have one, so the best I was able to offer was the interview I did on Linux Outlaws, Episode 102, about Microsoft's patent promise. I've also added a TODO to write something up more completely on this particular issue.

  ¹ I am not leaving my permissively-license-preferring friends out of this issue without careful consideration. Specifically, I just don't think it's practical or even fair to ask companies to license their patents for all permissively-licensed code, since that would be the same as licensing to everyone, including their proprietary software competitors. An ahead-of-time perpetual license to practice the teachings of all the company's patents under AGPLv3 basically makes sure that code that's eternally Free Software will also eternally be patent-licensed from that company, even if the company never contributes to the AGPLv3'd codebase. Anyone trying to make proprietary code that infringed the patent wouldn't have benefit of the license; only Free Software users, distributors and modifiers would have the benefit. If a company supports copyleft generally, then there is no legitimate reason for the company to refuse such a broad license for copyleft distributions and deployments.

  Posted on Wednesday 30 June 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-06-23: New Ground on Terminology Debate?

  (These days, ) I generally try to avoid the well-known terminology debates in our community. But, if you hang around this FLOSS world of ours long enough, you just can't avoid occasionally getting into them. I found myself in one this afternoon that spanned three identica threads. I had some new thoughts that I've shared today (and even previously) on my identi.ca microblog. I thought it might be useful to write them up in one place rather than scattered across a series of microblog statements.

  I gained my first new insight into the terminology issues when I had dinner with Larry Wall in early 2001 after my Master's thesis defense. It was first time I talked with him about these issues of terminology, and he said that it sounded like a good place to apply what he called the “golden rule of network protocols”: Always be conservative in what you emit and liberal in what you accept. I've recently noted again that's a good rule to follow regarding terminology.

  More recently, I've realized that the FLOSS community suffers here, likely due to our high concentration of software developers and engineers. Precision in communication is a necessarily component of the lives of developers, engineers, computer scientists, or anyone in a highly technical field. In our originating fields, lack of precise and well-understood terminology can cause bridges to collapse or the wrong software to get installed and crash mission critical systems. Calling x by the name y sometimes causes mass confusion and failure. Indeed, earlier this week, I watched a PBS special, The Pluto Files, where Neil deGrasse Tyson discussed the intense debate about the planetary status of Pluto. I was actually somewhat relieved that a subtle point regarding a categorical naming is just as contentious in another area outside my chosen field. Watching the “what constitutes a planet” debate showed me that FLOSS hackers are no different than most other scientists in this regard. We all take quite a bit of pride in our careful (sometimes pedantic) care in terminology and word choice; I know I do, anyway.

  However, on the advocacy side of software freedom (the part that isn't technical), our biggest confusion sometimes stems from an assumption that other people's word choice is as necessarily as precise as ours. Consider the phrase “open source”, for example. When I say “open source”, I am referring quite exactly to a business-focused, apolitical and (frankly) amoral⁰ interest in, adoption of, and contribution to FLOSS. Those who coined the term “open source” were right about at least one thing: it's a term that fits well with for-profit interests who might otherwise see software freedom as too political.

  However, many non-business users and developers that I talk to quite clearly express that they are into this stuff precisely because there are principles behind it: namely, that FLOSS seeks to make a better world by giving important rights to users and programmers. Often, they are using the phrase “open source” as they express this. I of course take the opportunity to say: it's because those principles are so important that I talk about software freedom. Yet, it's clear they already meant software freedom as a concept, and just had some sloppy word choice.

  Fact is, most of us are just plain sloppy with language. Precision isn't everyone's forte, and as a software freedom advocate (not a language usage advocate), I see my job as making sure people have the concepts right even if they use words that don't make much sense. There are times when the word choices really do confuse the concepts, and there are other times when they don't. Sometimes, it's tough to identify which of the two is occurring. I try to figure it out in each given situation, and if I'm in doubt, I just simplify to the golden rule of network protocols.

  Furthermore, I try to have faith in our community's intelligence. Regardless of how people get drawn into FLOSS: be it from the moral software freedom arguments or the technical-advantage-only open source ones, I don't think people stop listening immediately upon their arrival in our community. I know this even from my own adoption of software freedom: I came for the Free as in Price, but I stayed for the Free as in Freedom. It's only because I couldn't afford a SCO Unix license in 1992 that I installed GNU/Linux. But, I learned within just a year why the software freedom was what mattered most.

  Surely, others have a similar introduction to the community: either drawn in by zero-cost availability or the technical benefits first, but still very interested to learn about software freedom. My goal is to reach those who have arrived in the community. I therefore try to speak almost constantly about software freedom, why it's a moral issue, and why I work every day to help either reduce the amount of proprietary software, or increase the amount of Free Software in the world. My hope is that newer community members will hear my arguments, see my actions, and be convinced that a moral and ethical commitment to software freedom is the long lasting principle worth undertaking. In essence, I seek to lead by example as much as possible.

  Old arguments are a bit too comfortable. We already know how to have them on autopilot. I admit myself that I enjoy having an old argument with a new person: my extensive practice often yields an oratorical advantage. But, that crude drive is too much about winning the argument and not enough about delivering the message of software freedom. Occasionally, a terminology discussion is part of delivering that message, but my terminology debate tools box has a “use with care” written on it.

  ---

  ⁰ Note that here, too, I took extreme care with my word choice. I mean specifically amorality — merely an absence of any moral code in particular. I do not, by any stretch, mean immoral.

  Posted on Wednesday 23 June 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-06-11: Where Are The Bytes?

  A few years ago, I was considering starting a Free Software project. I never did start that one, but I learned something valuable in the process. When I thought about starting this project, I did what I usually do: ask someone who knows more about the topic than I do. So I phoned my friend Loïc Dachary, who has started many Free Software projects, and asked him for advice.

  Before I could even describe the idea, Loïc said: you don't have a URL? I was taken aback; I said: but I haven't started yet. He said: of course you have, you're talking to me about it, so you've started already. The most important thing you can tell me, he said, is Where are the bytes?

  Loïc explained further: Most projects don't succeed. The hardest part about a software freedom project is carrying it far enough so it can survive even if its founders quit. Therefore, under Loïc's theory, the most important task at the project's start is to generate those bytes, in hopes those bytes find their way to the a group of developers who will help keep the project alive.

  But, what does he mean by “bytes”? He means, quite simply, that you have to core dump your thinking, your code, your plans, your ideas, just about everything on a public URL that everyone can take a look at. Push bytes. Push them out every time you generate a few. It's the only chance your software freedom project has.

  The first goal of a software freedom project is to gain developers. No project can have long-term success without a diverse developer base. The problem is, the initial development work and project planning too often ends up trapped in the head of a few developers. It's human nature: How can I spend my time telling everyone about what I'm doing? If I do that, when will I actually do anything? Successful software freedom project leaders resist this human urge and do the seemingly counterintuitive thing: they dump their bytes on the public, even if it slows them down a bit.

  This process is even more essential in the network age. If someone wants to find a program that does a job, the first tool is a search engine: to find out if someone else has done it yet. Your project's future depends completely that every such search performed helps developers find your bytes.

  In early 2001, I asked Larry Wall, of all the projects he'd worked on, which was the hardest. His answer was quick: when I was developing the first version of perl5, Larry said, I felt like I had to code completely alone and just make it work by myself. Of course, Larry's a very talented guy who can make that happen: generate something by himself that everyone wanted to use. While I haven't asked him what he'd do in today's world if he was charged with a similar task, I can guess — especially given at how public the Perl6 process has been — that he'd instead use the new network tools, such as DVCS, to push his bytes early and often and seek to get more developers involved early.⁰

  Admittedly, most developers' first urge is to hide everything. We'll release it when it's ready, is often heard, or — even worse — Our core team works so well together; it'll just slow us down to make things public now. Truth is, this is a dangerous mixture of fear and narcissism — the very same drives that lead proprietary software developers to keep things proprietary.

  Software freedom developers have the opportunity to actually get passed the simple reality of software development: all code sucks, and usually isn't complete. Yet, it's still essential that the community see what's going on at ever step, from the empty codebase and beyond. When a project is seen as active, that draws in developers and gives the project hope of success.

  When I was in college, one of the teams in a software engineering class crashed and burned; their project failed hopelessly. This happened despite one of the team members spending about half the semester up long nights, coding by himself, ignoring the other team members. In their final evaluation, the professor pointed out: Being a software developer isn't like being a fighter pilot. The student, missing the point, quipped: Yeah, I know, at least a fighter pilot has a wingman. Truth is, one person, or two people, or even a small team, aren't going to make a software freedom project succeed. It's only going to succeed when a large community bolsters it and prevents any single point of failure.

  Nevertheless, most software freedom projects are going to fail. But, there is no shame in pushing out a bunch of bytes, encouraging people to take a look, and giving up later if it just doesn't make it. All of science works this way, and there's no reason computer science should be any different. Keeping your project private assures its failure; the only benefit is that you can hide that you even tried. As my graduate advisor told me when I was worried my thesis wasn't a success: a negative result can be just as compelling as a positive one. What's important is to make sure all results are published and available for public scrutiny.

  ---

  When I started discussing this idea a few weeks ago, some argued that early GNU programs — the founding software of our community — were developed in private initially. This much is true, but just because GNU developers once operated that way doesn't mean it was the right way. We have the tools now to easily do development in public, so we should. In my view, today, it's not really in the spirit of software freedom until the project, including its design discussions, plans, and prototypes are all developed in public. Code (regardless of its license) merely dumped over the wall on intervals deserves to be forked by a community committed to public development.

  ---

  Update (2010-06-12): I completely forgot to mention The Risks of Distributed Version Control by Ben Collins-Sussman, which is five years old now but still useful. Ben is making a similar point to mine, and pointing out how some uses of DVCS can cause the effects that I'm encouraging developers to avoid. I think DVCS is like any tool: it can be used wrongly. The usage Ben warns about should be avoided, and DVCS, when used correctly, assists in the public software development process.

  ---

  ⁰Note that pushing code out to the public in the mid-1990s was substantially more arduous (from a technological perspective) than it is today. Those of you who don't remember shar archives may not realize that. :)

  Posted on Friday 11 June 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

May

• 2010-05-08: Beware of Proprietary Drift

  The Free Software Foundation (FSF) announced yesterday a campaign to collect a clear list of OpenOffice.Org extensions that are FaiF, to convince the OO.o Community Council to list only FaiF extensions, and to find those extensions that are proprietary software, so that OO.o extension developers can focus of their efforts on writing replacements under a software-freedom-respecting license.

  I use OpenOffice.Org (OO.o) myself only when someone else sends me a document in that format; I'm a LaTeX, DocBook, MarkDown, or HTML user for documents I originate. Nevertheless, I'm obviously a rare sort of software user, and I understand that OO.o is a program many people use. Plus, a program like OO.o is extremely large, with a diverse user base, so extension-style improvement, from a technological perspective, makes sense to meet all the users' requirements.

  Unfortunately, the social impact of a program designed this way causes danger for software freedom. It sometimes causes a chain of events that I call “proprietary drift” — a social phenomena that leads otherwise FaiF codebases to slowly become, in their default use, mostly proprietary packages, at least with regard the features users find most important and necessary.

  Copyleft itself was originally designed to address this problem: to make sure that improved versions of packages were available with as much software freedom as the original. Copyleft isn't a perfect solution to reach this goal, and furthermore many essential software freedom codebases are under weak copyleft and/or permissive licenses. Such is the case with OO.o, and the proprietary drift of the codebase is thus of great concern here.

  For those of us that have the goal of building a world where software freedom is given for all published and deployed software, this problem of proprietary drift is a terrible threat. In many ways, it's even a worse threat than the marketing and production of fully proprietary software. This may seem a bit counter-intuitive on its surface; logic would seem to dictate that some software freedom is better than none, and therefore an OO.o user with a few proprietary extensions installed is better off than a Microsoft Word user. And, in fact, none of that is false.

  However, the situation introduces a complexity. In short, it can inspire a “good enough” reaction among users. Particularly for users who have generally used only proprietary software, the experience of using a package that mostly respects software freedom can be incredibly liberating. When 98% of your software is FaiF-licensed, you sometimes don't notice the 2% that isn't. Over time, the 2% goes up to 3%, then 4%. This proprietary drift will often lead back to a system not that much different from (for example) Apple's operating system, which has a permissively-licensed software freedom core, but most of the system is very much proprietary. In other words, in the long term, proprietary drift leads to mostly proprietary systems.

  Sometimes, I and other software freedom advocates are criticized for giving such a hard time to those who are seemingly closest to our positions. Often, this is because the threat of proprietary drift is so great. Concern about proprietary drift is, at least in large part, the inspiration for positions opposing UbuntuOne, for the Linux Libre project, and for this this new initiative to catalog the FaiF OO.o extensions and rewrite the proprietary ones. We all agree that purely proprietary software programs like those from Apple, Microsoft, and Oracle are the greatest threat to software freedom in the short term. But, in the long term, proprietary drift has the potential to creep up on users who prefer software freedom. You may never see it coming if you aren't constantly vigilant.

  [There's a derivative version of this article available in Arabic. I can't personally attest to the accuracy of the translation, as I can't read Arabic, but osamak, the translator, is a good guy.]

  ---

  Disclaimer: While I am a member of FSF's Board of Directors, and I believe the positions stated above are consistent with FSF's positions, the opinions are not necessarily those of the FSF even though I refer to various FSF-sponsored initiatives. Furthermore, this remains my personal blog and the opinions certainly do not express those of my employer nor those of any other organization or project for which I volunteer.

  Posted on Saturday 08 May 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

April

• 2010-04-21: Launchpad Single Sign On Released

  I wrote 15 months ago thanking Canonical for their release of Launchpad. However, in the interim, a part of the necessary codebase was made proprietary, namely the authentication system used in the canonical instance of Launchpad hosted by Canonical. (Yes, I still insist on using canonical in the canonical way despite the company name making it confusing. :). I added this fact to my list of reasons of abandoning Ubuntu and other Canonical products.

  Fortunately, I've now removed this reason from the list of reasons I switched back to Debian from Ubuntu, since Jono Bacon announced release of this code today. According to Jono, this release means that Launchpad and its dependencies are again fully Free Software. This is a step forward. And, I did promise many people at Canonical that I'd make a point about thanking them for doing Free Software releases when they do them, since I do make a point of calling them out about negative things they do.

  Like any mixed proprietary/Free Software company, there is tons more to be released. I remain most concerned about UbuntuOne's server side code, but I very much hope this release today marks a bounce-back for Canonical to its roots in the 100% Free Software world.

  Posted on Wednesday 21 April 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-04-07: Proprietary Licenses Are Even Worse Than They Look

  There are lots of evil things that proprietary software companies might do. Companies put their own profit above the rights and freedoms of their users, and to that end, much can be done that subjugates users. Even as someone who avoids proprietary software, I still read many proprietary license agreements (mainly to see how bad they are). I've certainly become numb to the constant barrage of horrible restrictions they place on users. But, sometimes, proprietary licenses go so far that I'm taken aback by their gratuitous cruelty.

  Apple's licenses are probably the easiest example of proprietary licensing terms that are well beyond reasonableness. Of course, Apple's licenses do the usual things like forbidding users from copying, modifying, sharing, and reverse engineering the software. But even worse, Apple also forbid users from running Apple software on any hardware that is not produced by Apple.

  The decoupling of one's hardware vendor from one's software vendor was a great innovation brought about by the PC revolution, in which, ironically, Apple played a role. Computing history has shown us that when your software vendor also controls your hardware, you can easily be “locked in“ in ways that make mundane proprietary software licenses seem almost nonthreatening.

  

  Indeed, Apple has such a good hype machine that they even have convinced some users this restrictive policy makes computing better. In this worldview, the paternalistic vendor will use its proprietary controls over as many pieces of the technology as possible to keep the infantile users from doing something that's “just bad for them”. The tyrannical MCP of Tron comes quickly to my mind.

  I'm amazed that so many otherwise Free Software supporters are quite happy using OSX and buying Apple products, given these kinds of utterly unacceptable policies. The scariest part, though, is that this practice isn't confined to Apple. I've been recently reminded that other companies, such as IBM, do exactly the same thing. As a Free Software advocate, I'm critical of any company that uses their control of a proprietary software license to demand that users run that software only on the original company's hardware as well. The production and distribution of mundane proprietary software is bad enough. It's unfortunate that companies like Apple and IBM are going the extra mile to treat users even worse.

  Posted on Wednesday 07 April 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

March

• 2010-03-26: LibrePlanet 2010 Completes Its Orbit

  Seven and a half years ago, I got this idea: the membership of the Free Software Foundation should have a chance to get together every year and learn about what the FSF has been doing for the last year. I was so nervous at the first one on Saturday 15 March 2003, that I even wore a suit which I rarely do.

  The basic idea was simple: the FSF Board of Directors came into town anyway each March for the annual board meeting. Why not give a chance for FSF associate members to meet the leadership and staff of FSF and ask hard questions to their hearts' content? I'm all about transparency, as you know. :)

  Since leaving the position of Executive Director a few months before the 2005 meeting, I've attended every annual meeting, just as an ordinary Associate Member and FSF volunteer. It's always enjoyable to attend a conference organized by someone else that you used to help organize; it's like, after having done sysadmin work for other people for years, to have someone keep a machine running and up to date just for you. It's been wonderful to watch the FSF AM meeting grow into a full-fledged conference for discussion and collaboration between folks from all over the Free Software world. “One room, one track, one day” has become “five rooms, three tracks, and three days” with the proverbial complaint throughout: But, why do I have to miss this great session so that I can go to some other great session!?!

  Some highlights for me this year were:

  • I saw John Gilmore win a well-deserved FSF Award for the Advancement of Free Software.
  • I got to spend time with the intrepid gnash developer Rob Savoye again, whom I knew of for years (his legend precedes him) but I'd rarely had a chance to see in person regularly, until lately.
  • I met so many young people excited about software freedom. I can only imagine to be only 19 or 20 years old and have the opportunity meet other Free Software developers in person. At that age, I considered myself lucky to simply have Usenet access so that I could follow and participate in online discussions about Free Software (good ol' gnu.misc.discuss ;). I am so glad that young folks, some from as far away as Brazil, had the opportunity to visit and speak about their work.
  • On the informal Friday sessions, I was a bit amazed that I pulled off a marathon six-hour session of mostly well-received talks/discussions (for which I readily admit I had not prepped well). The first three hours was about the challenges of software freedom on mobile devices, and the second three were about the nitty-gritty details of the hardest and most technical GPL enforcement task: the C&CS check. People seemed to actually enjoy watching me break half my Fedora chroots trying to build some source code for a plasma television. Someone even told me later: it was more fun because we got to see you make all the mistakes.
  • Finally (and I realize I've probably buried the lede here, but I've kept the list chronological, since I wrote most of it before I found out this last thing), after the FSF Board meeting, which followed LibrePlanet, I was informed by a phone call from my good friend Henry Poole that I'd been elected to FSF's Board of Directors, which has now been announced by FSF on Peter Brown's blog. I've often told the story that when I first learned about the FSF as a young programmer and sysadmin, I thought that someday, maybe I could be good enough to get a job as a sysadmin for the FSF. I did indeed volunteer as a sysadmin for the FSF starting around 1996, but I truly felt I'd exceeded any possible dream when I was later named FSF's Executive Director, and was able to serve in that post for so many years. Now, being part of the Board of Directors is an even greater opportunity for involvement in the organization that I've loved and respected for so long.

  FSF is an organization based around a very simple, principled idea: that users and programmers alike deserve inalienable rights to copy, share, modify, and redistribute all the software that they use. This issue isn't merely about making better software (although Free Software developers usually do, anyway); it's about a principle of morality: everyone using computers should be treated well and be given the maximal opportunity to treat their neighbors well, too. Helping make this simple idea into reality is the center of all the work I've done for the last 12 years of my life, and I expect it will be the focus of my (hopefully many) remaining years. I am thankful that the Voting Members of FSF have given me this additional opportunity to help our shared cause. I plan to work hard in this and all the other responsibilities that I already have to our Free Software community. Like everyone on FSF's Board of Directors, I serve in that role completely as a volunteer, so in some ways I feel this is just a natural extension of the volunteer work I've continued to do for the FSF regularly since I left its employment in 2005.

  Finally, I was glad to meet (or meet again) so many FSF supporters at LibrePlanet, and I deeply hope that I can serve our shared goal well in this additional role.

  Posted on Friday 26 March 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-03-15: Is Your Support of Copyleft Logically Consistent?

  Most of you are aware from one of my previous posts that It's a Wonderful Life! is my favorite film. Recently, I encountered something in the software freedom community that reminded me of yet another quote from the flim:

  

  GEORGE:

  Look, uh … I think maybe you better not mention getting your wings around here.

  CLARENCE:

  Why? Don't they believe in angels?

  GEORGE:

  I… yeah, they believe in them…

  CLARENCE:

  Ohhh … Why should they be surprised when they see one?

  Obviously, I don't believe in angels myself. But, Clarence's (admittedly naïve) logic is actually impeccable: Either you believe in angels or you don't. If you believe in angels, then you shouldn't be surprised to (at least occasionally) see one.

  This film quote came to my mind in reference to a concept in GPL enforcement. Many people give lip service to the idea that the GPL, and copyleft generally, is a unique force that democratizes software and ensures that FLOSS cannot be exploited by proprietary software interests. Many of these same people, though, oppose GPL enforcement when companies exploit GPL'd code and don't give the source code and take away users' rights to modify and share that software.

  I've admitted that the copyleft is merely a strategy to achieve maximal software freedom. There are other strategies too, such as the Apache community process. The Apache Software Foundation releases software under a permissive non-copyleft license, but then negotiates with companies to convince them to contribute to the code base publicly. For some projects, that strategy has worked well, and I respect it greatly.

  Some (although not all) people in non-copyleft FLOSS communities (like the Apache community) are against GPL enforcement. I disagree with them, but their position is logically consistent. Such folks don't agree with us (copyleft-supporting folks) that a license should be used as a mechanism to guarantee that all published and deployed improved versions of the software are released in software freedom. It's not that those other folks don't prefer FLOSS; they simply prefer a non-legally binding social pressure to encourage software sharing rather than a strategy with legal backup. I prefer a strategy with legal strength, but I still respect non-copyleft folks who don't support that. They take a logically consistent and reasonable approach.

  However, it's ultimately hypocritical to claim support for a copyleft structure but oppose GPL enforcement. If you believe the license should have a legal requirement that ensures software is always distributed in software freedom, then why would you be surprised — or, even worse, angry — that a copyright holder would seek to uphold users' rights when that license is violated?

  There is great value in having multiple simultaneous strategies ongoing to achieve important goals. Universal software freedom is my most important goal, and I expect to spend nearly all of my life focused on achieving it for all published and deployed software in the world. However, I don't expect nor even want everyone else to single-minded-ly support my exact same strategies in all cases. The diversity of the software freedom community makes it more likely that we'll succeed if we avoid single point of failure on any particular plan, and I support that diversity.

  However, I also think it's reasonable to expect logically consistent positions. A copyleft license is effectively indistinguishable from the Apache license if copyleft is never enforced when violations occur. Condemning community-oriented⁰ GPL enforcement (that seeks primarily to get the code released) while also claiming to support the idea of copyleft is a logically inconsistent and self-contradictory position. It's unfortunate that so many people hold this contradictory position.

  ---

  ⁰There are certain types of GPL enforcement that are not consistent with the goal of universal software freedom. For example, some so-called “Open Core” companies are well known for releasing their (solely) copyrighted code under GPL, and then using GPL enforcement as a mechanism to pressure users to take a proprietary license. GPL enforcement is only acceptable in my view if its primary goal is to have all code released under GPL. Such enforcement must never compromise about one point: that compliance with the GPL is a non-negotiable term of settling the enforcement action. If the enforcer is willing to sell out the rights that users' have to source code, then even I would condemn, as I have previously, such GPL enforcement as bad for the software freedom community. For this reason, in all GPL enforcement that I engage in, I make it a term of my participation that compliance with the terms of the GPL for the code in question be a non-negotiable requirement.

  Posted on Monday 15 March 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-03-05: Ok, Be Afraid if Someone's Got a Voltmeter Hooked to Your CPU

  Boy, do I hate it when a FLOSS project is given a hard time unfairly. I was this morning greeted with news from many places that OpenSSL, one of the most common FLOSS software libraries used for cryptography, was somehow severely vulnerable.

  I had a hunch what was going on. I quickly downloaded a copy of the academic paper that was cited as the sole source for the story and read it. As I feared, OpenSSL was getting some bad press unfairly. One must really read this academic computer science article in the context it was written; most commenting about this paper probably did not.

  First of all, I don't claim to be an expert on cryptography, and I think my knowledge level to opine on this subject remains limited to a little blog post like this and nothing more. Between college and graduate school, I worked as a system administrator focusing on network security. While a computer science graduate student, I did take two cryptography courses, two theory of computation courses, and one class on complexity theory⁰. So, when compared to the general population I probably am an expert, but compared to people who actually work in cryptography regularly, I'm clearly a novice. However, I suspect many who have hitherto opined about this academic article to declare this severe vulnerability have even less knowledge than I do on the subject.

  This article, of course, wasn't written for novices like me, and certainly not for the general public nor the technology press. It was written by and for professional researchers who spend much time each week reading dozens of these academic papers, a task I haven't done since graduate school. Indeed, the paper is written in a style I know well; my “welcome to CS graduate school” seminar in 1997 covered the format well.

  The first thing you have to note about such papers is that informed readers generally ignore the parts that a newbie is most likely focus on: the Abstract, Introduction and Conclusion sections. These sections are promotional materials; they are equivalent to a sales brochure selling you on how important and groundbreaking the research is. Some research is groundbreaking, of course, but most is an incremental step forward toward understanding some theoretical concept, or some report about an isolated but interesting experimental finding.

  Unfortunately, these promotional parts of the paper are the sections that focus on the negative implications for OpenSSL. In the rest of the paper, OpenSSL is merely the software component of the experiment equipment. They likely could have used GNU TLS or any other implementation of RSA taken from a book on cryptography¹. But this fact is not even the primary reason that this article isn't really that big of a deal for daily use of cryptography.

  The experiment described in the paper is very difficult to reproduce. You have to cause very subtle faults in computation at specific times. As I understand it, they had to assemble a specialized hardware copy of a SPARC-based GNU/Linux environment to accomplish the experiment.

  Next, the data generated during the run of the software on the specially-constructed faulty hardware must be collected and operated upon by a parallel processing computing environment over the course of many hours. If it turns out all the needed data was gathered, the output of this whole process is the private RSA key.

  The details of the fault generation process deserve special mention. Very specific faults have to occur, and they can't occur such that any other parts of the computation (such as, say, the normal running of the operating system) are interrupted or corrupted. This is somewhat straightforward to get done in a lab environment, but accomplishing it in a production situation would be impractical and improbable. It would also usually require physical access to the hardware holding the private key. Such physical access would, of course, probably give you the private key anyway by simply copying it off the hard drive or out of RAM!

  This is interesting research, and it does suggest some changes that might be useful. For example, if it doesn't slow a system down too much, the integrity of RSA signatures should be verified, on a closely controlled proxy unit with a separate CPU, before sending out to a wider audience. But even that would be a process only for the most paranoid. If faults are occurring on production hardware enough to generate the bad computations this cracking process relies on, likely something else will go wrong on the hardware too and it will be declared generally unusable for production before an interloper could gather enough data to crack the key. Thus, another useful change to make based on this finding is to disable and discard RSA keys that were in use on production hardware that went faulty.

  Finally, I think this article does completely convince me that I would never want to run any RSA computations on a system where the CPU was emulated. Causing faults in an emulated CPU would only require changes to the emulation software, and could be done with careful precision to detect when an RSA-related computation was happening, and only give the faulty result on those occasions. I've never heard of anyone running production cryptography on an emulated CPU, since it would be too slow, and virtualization technologies like Xen, KVM, and QEMU all pass-through CPU instructions directly to hardware (for speed reasons) when the virtualized guest matches the hardware architecture of the host.

  The point, however, is that proper description of the dangers of a “security vulnerability” requires more than a single bit field. Some security vulnerabilities are much worse than others. This one is substantially closer to the “oh, that's cute” end of the spectrum, not the “ZOMG, everyone's going to experience identity theft tomorrow” side.

  ---

  ⁰Many casual users don't realize that cryptography — the stuff that secures your networked data from unwanted viewers — isn't about math problems that are unsolvable. In fact, it's often based on math problems that are trivially solvable, but take a very long time to solve. This is why algorithmic complexity questions are central to the question of cryptographic security.

  ¹ I'm oversimplifying a bit here. A key factor in the paper appears to be the linear time algorithm used to compute cryptographic digital signatures, and the fact that the signatures aren't verified for integrity before being deployed. I suspect, though, that just about any RSA system is going to do this. (Although I do usually test the integrity of my GnuPG signatures before sending them out, I do this as a user by hand).

  Posted on Friday 05 March 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-03-04: Musings on Software Freedom for Mobile Devices

  I started using GNU/Linux and Free Software in 1992. In those days, while everything I needed for a working computer was generally available in software freedom, there were many components and applications that simply did not exist. For highly technical users who did not need many peripherals, the Free Software community had reached a state of complete software freedom. Yet, in 1992, everyone agreed there was still much work to be done. Even today, we still strive for a desktop and server operating system, with all relevant applications, that grants complete software freedom.

  Looked at broadly, mobile telephone systems are not all that different from 1992-era GNU/Linux systems. The basics are currently available as Free, Libre, and Open Source Software (FLOSS). If you need only the bare minimum of functionality, you can, by picking the right phone hardware, run an almost completely FLOSS operating system and application set. Yet, we have so far to go. This post discusses the current penetration of FLOSS in mobile devices and offers a path forward for free software advocates.

  A Brief History

  The mobile telephone market has never functioned like the traditional computer market. Historically, the mobile user made arrangements with some network carrier through a long-term contract. That carrier “gave” the user a phone or discounted it as a loss-leader. Under that system, few people take their phone hardware choice all that seriously. Perhaps users pay a bit more for a slightly better phone, but generally they nearly always pick among the limited choices provided by the given carrier.

  Meanwhile, Research in Motion was the first to provide corporate-slave-oriented email-enabled devices. Indeed, with the very recent focus on consumer-oriented devices like the iPhone, most users forget that Apple is by far not the preferred fruit for the smart phone user. Today, most people using a “smart phone” are using one given to them by their employer to chain them to their office email 24/7.

  Apple, excellent at manipulating users into paying more for a product merely because it is shiny, also convinced everyone that now a phone should be paid for separately, and contracts should go even longer. The “race to mediocrity” of the phone market has ended. Phones need real features to stand out. Phones, in fact, aren't phones anymore. They are small mobile computers that can also make phone calls.

  If these small computers had been introduced in 1992, I suppose I'd be left writing the Mobile GNU Manifesto, calling for developers to start from scratch writing operating systems for these new computers, so that all users could have software freedom. Fortunately, we have instead been given a head start. Unlike in 1992, not every company in the market today is completely against releasing Free Software. Specifically, two companies have seen some value in releasing (some parts of) phone operating systems as Free Software: Nokia and Google. However, the two companies have done this for radically different reasons.

  The Current State of Mobile Software Freedom

  For its part, Nokia likely benefited greatly from the traditional carrier system. Most of their phones were provided relatively cheaply with contracts. Their interest in software freedom was limited and perhaps even non-existent. Nokia sold new hardware every time a phone contract was renewed, and the carrier paid the difference between the loss-leader price and Nokia's wholesale cost. The software on the devices was simple and mostly internally developed. What incentive did Nokia have to release software in software freedom? (Nokia realized too late this was the wrong position, but more on that later.)

  In parallel, Nokia had chased another market that I've never fully understood: the tablet PC. Not big enough to be a real computer, but too large to be a phone, these devices have been an idea looking for a user base. Regardless of my personal views on these systems, though, GNU/Linux remains the ideal system for these devices, and Nokia saw that. Nokia built the Debian-ish Maemo system as a tablet system, with no phone. However, I can count on one hand all the people I've met who bothered with these devices; I just don't think a phone-less small computer is going to ever become the rage, even if Apple dumps billions into marketing the iPad. (Anyone remember the Newton?)

  I cannot explain, nor do I even understand, why Nokia took so long to use Maemo as a platform for a tablet-like telephone. But, a few months ago, they finally released one. This N900 is among only a few available phones that make any strides toward a fully free software phone platform. Yet, the list of proprietary components required for operation remains quite long. The common joke is that you can't even charge the battery on your N900 without proprietary software.

  While there are surely people inside Nokia who want more software freedom on their devices, Nokia is fundamentally a hardware company experimenting with software freedom in hopes that it will bolster hardware sales. Convincing Nokia to shorten that proprietary list will prove difficult, and the community based effort to replace that long list with FLOSS (called Mer) faces many challenges. (These challenges will likely increase with the recent Maemo merger with Moblin to form MeeGo).

  Fortunately, hardware companies are not the only entity interested in phone operating systems. Google, ever-focused on routing human eyes to its controlled advertising, realizes that even more eyes will be on mobile computing platforms in the future. With this goal in mind, Google released the Android/Linux system, now available on a variety of phones in varying degrees of software freedom.

  Google's motives are completely different than Nokia's. Technically, Google has no hardware to sell. They do have a set of proprietary applications that yield the “Google online experience” to deliver Google's advertising. From Google's point of view, an easy-to-adopt, licensing-unencumbered platform will broaden their advertising market.

  Thus, Android/Linux is a nearly fully non-copylefted phone operating system platform where Linux is the only GPL licensed component essential to Android's operation. Ideally, Google wants to see Android adopted broadly in both Free Software and mixed Free/proprietary deployments. Google's goals do not match that of the software freedom community, so in some cases, a given Android/Linux device will give the user more software freedom than the N900, but in many cases it will give much less.

  The HTC Dream is the only Android/Linux device I know of where a careful examination of the necessary proprietary components have been analyzed. Obviously, the “Google experience” applications are proprietary. There also are about 20 hardware interface libraries that do not have source code available in a public repository. However, when lined up against the N900 with Maemo, Android on the HTC Dream can be used as an operational mobile telephone and 3G Internet device using only three proprietary components: a proprietary GSM firmware, proprietary Wifi firmware, and two audio interface libraries. Further proprietary components are needed if you want a working accelerometer, camera, and video codecs as their hardware interface libraries are all proprietary.

  Based on this analysis, it appears that the HTC Dream currently gives the most software freedom among Android/Linux deployments. It is unlikely that Google wants anything besides their applications to be proprietary. While Google has been unresponsive when asked why these hardware interface libraries are proprietary, it is likely that HTC, the hardware maker with whom Google contracted, insisted that these components remain proprietary, and perhaps fear patent suits like the one filed this week are to blame here. Meanwhile, while no detailed analysis of the Nexus One is yet available, it's likely similar to the HTC Dream.

  Other Android/Linux devices are now available, such as those from Motorola and Samsung. There appears to have been no detailed analysis done yet on the relative proprietary/freeness ratio of these Android deployments. One can surmise that since these devices are from traditionally proprietary hardware makers, it is unlikely that these platforms are freer than those available from Google, whose maximal interest in a freely available operating system is clear and in contrast to the traditional desires of hardware makers.

  Whether the software is from a hardware-maker desperately trying a new hardware sales strategy, or an advertising salesman who wants some influence over an operating system choice to improve ad delivery, the software freedom community cannot assume that the stewards of these codebases have the interests of the user community at heart. Indeed, the interests between these disparate groups will only occasionally be aligned. Community-oriented forks, as has begun in the Maemo community with Mer, must also begin in the Android/Linux space too. We are slowly trying with the Replicant project, founded by myself and my colleague Aaron Williamson.

  A healthy community-oriented phone operating system project will ultimately be an essential component to software freedom on these devices. For example, consider the fate of the Mer project now that Nokia has announced the merger of Maemo with Moblin. Mer does seek to cherry-pick from various small device systems, but its focus was to create a freer Maemo that worked on more devices. Mer now must choose between following the Maemo in the merge with Moblin, or becoming a true fork. Ideally, the right outcome for software freedom is a community-led effort, but there may not be enough community interest, time and commitment to shepherd a fork while Intel and Nokia push forward on a corporate-controlled codebase. Further, Moblin will likely push the MeeGo project toward more of a tablet-PC operating system than a smart phone.

  A community-oriented Android/Linux fork has more hope. Google has little to lose by encouraging and even assisting with such forks; such effort would actually be wholly consistent with Google's goals for wider adoption of platforms that allow deployment of Google's proprietary applications. I expect that operating system software-freedom-motivated efforts will be met with more support from Google than from Nokia and/or Intel.

  However, any operating system, even a mobile device one, needs many applications to be useful. Google experience applications for Android/Linux are merely the beginning of the plethora of proprietary applications that will ultimately be available for MeeGo and Android/Linux platforms. For FLOSS developers who don't have a talent for low-level device libraries and operating system software, these applications represent a straightforward contribution towards mobile software freedom. (Obviously, though, if one does have talent for low-level programming, replacing the proprietary .so's on Android/Linux would be the optimal contribution.)

  Indeed, on this point, we can take a page from Free Software history. From the early 1990s onward, fully free GNU/Linux systems succeeded as viable desktop and server systems because disparate groups of developers focused simultaneously on both operating systems and application software. We need that simultaneous diversity of improvement to actually compete with the fully proprietary alternatives, and to ensure that the “mostly FLOSS” systems of today are not the “barely FLOSS” systems of tomorrow.

  Careful readers have likely noticed that I have ignored Nokia's other release, the Symbian> codebase. Every time I write or speak about the issues of software freedom in mobile devices, I'm chastised for leaving it out of the story. My answer is always simple: when a FLOSS version of Symbian can be compiled from source code, using a FLOSS compiler or SDK, and that binary can be installed onto an actual working mobile phone device, then (and only then) will I believe that the Symbian source release has value beyond historical interest. We have to get honest as a community about the future of Symbian: it's a ten-year-old proprietary codebase designed for devices of that era that doesn't bootstrap with any compilers our community uses regularly. Unless there's a radical change to these facts, the code belongs in a museum, not running on a phone.

  Also, lest my own community of hard-core FLOSS advocates flame me, I must also mention the Neo FreeRunner device and the OpenMoko project. This was a noble experiment: a freely specified hardware platform running 100% FLOSS. I used an OpenMoko FreeRunner myself, hoping that it would be the mobile phone our community could rally around. I do think the device and its (various) software stack(s) have a future as an experimental, hobbyist device. But, just as GNU/Linux needed to focus on x86 hardware to succeed, so must software freedom efforts in mobile systems focus on mass-market, widely used, and widely available hardware.

  Jailbreaking and the Self-Installed System

  When some of us at my day-job office decided to move as close to a software freedom phone platform as we could, we picked Android/Linux and the HTC Dream. However, we carefully considered the idea of permission to run one's own software on the device. In the desktop and server system market, this is not a concern, but on mobile systems, it is a central question.

  The holdover of those carrier-controlled agreements for phone acquisition is the demand that devices be locked down. Devices are locked down first to a single carrier's network, so that devices cannot (legally) be resold as phones ready for any network. Second, carriers believe that they must fear the FCC if device operating systems can be reinstalled.

  On the first point, Google is our best ally in this regard. The HTC Dream developer models, called the Android Dev Phone 1 (aka ADP1), while somewhat more expensive than T-Mobile branded G1s, permit the user to install any operating system on the phone, and the purchase agreement extract no promises from the purchaser regarding what software runs on the device. Google has no interest in locking you to a single carrier, but only to a single Google experience application vendor. Offering a user “carrier freedom of choice”, while tying those users tighter to Google applications, is probably a central part of their marketing plans.

  The second point — fear of an FCC crack down when mobile users have software freedom — is beyond the scope of this article. However, what Atheros has done with their Wifi devices shows that software freedom and FCC compliance can co-exist. Furthermore, the central piece of FCC's concern — the GSM chipset and firmware — runs on a separate processor in modern mobile devices. This is a software freedom battle for another day, but it shows that the FCC can be pacified in the meantime by keeping the GSM device a black box to the Free Software running on the primary processor of the device.

  Conclusion

  Seeking software freedom on mobile devices will remain a complicated endeavor for some time. Our community should utilize the FLOSS releases from companies, but should not forget that, until viable community forks exist, software freedom on these devices exists at the whim of these companies. A traditional “get some volunteers together and write some code” approach can achieve great advancement toward community-oriented FLOSS systems on mobile devices. Developers could initially focus on applications for the existing “mostly FLOSS” platforms of MeeGo and Android/Linux. The challenging and more urgent work is to replace lower-level proprietary components on these systems with FLOSS alternatives, but admittedly needs special programming skills that aren't easy to find.

  (This blog post first appeared as an article in the March 2010 issue of the Canadian online journal, The Open Source Business Resource.)

  Posted on Thursday 04 March 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-03-03: Thoughts on Jeremy's Sun/Oracle Analysis

  Leslie Hawthorn referred me to an excellent article by Jeremy Allison about Sun merging with Oracle. It was a particularly interesting read for me since, while I knew that Jeremy worked for Sun early in his career, I didn't realize that he started in engineering tech support.

  The most amusing part to me is that it's quite possible Jeremy was on the UK tech support hotline during the same time frame when I was calling USA Sun tech support while working for Westinghouse. I probably would have had a different view of proprietary software if Jeremy had answered the USA phone calls. One of the major life experiences that led me down the path of hard-core software freedom beliefs were my many calls to Sun tech support, who would usually tell me they just weren't going to fix the bugs I was reporting because Westinghouse just wasn't “big enough” (it was ironically one of the largest employers in Maryland in the 1980s and early 1990s) to demand that Sun fix such bugs (notwithstanding our monthly Sun maintenance fees).

  But, more fascinating still is Jeremy's analysis of why Sun failed as a FLOSS company. Specifically, Jeremy points out that the need for corporate control over all software technologies that Sun released, specifically demanding the exclusive right to proprietarize non-Sun contributions, was a primary reason that Sun just never succeeded as a FLOSS company.

  Meanwhile, I'm less optimistic than Jeremy on the future of Oracle. I have paid attention to Oracle's contributions to btrfs in light of recent events. Amusingly, btfs exists in no small part because ZFS was never licensed correctly and never turned into a truly community-oriented project. While the two projects don't have identical goals, they are similar enough that it seems unlikely btrfs would exist if Sun had endeavored to become a real FLOSS contributor and shepherd ZFS into Linux upstream using normal Linux community processes. It's thus strange to think that Oracle controls ZFS, even while it continues to contribute to btrfs, in a normal, upstream way (i.e., collaborating under the terms of GPLv2 with community developers and employees of other companies such as Red Hat, HP, Intel, Novell, and Fujitsu).

  I have mostly considered Oracle's contributions to btrfs (and to Xen, to which they contribute to in much the same way) as a complete fluke. Oracle is third only to Apple and Microsoft in its predatory, proprietary software marketing practices and mistreatment of users. Other than these notable exceptions, Oracle's attitude generally matches Sun's long-ago roots (and Apple's current attitude) in this regard: non-copyleft FLOSS without giving contributions back is the best “Open Source” plan.

  Software corporations usually oscillate between treating users and developers well and treating them poorly. Larger companies are often completely self-contradictory on this issue across multiple divisions. Microsoft and Apple are actually unique in their consistency of anti-software-freedom attitudes; I've typically assessed Oracle as roughly equivalent to the two of them⁰. I don't really see Oracle's predatory proprietary licensing models changing, and I expect them to try to manipulate FLOSS to bolster their proprietary licensing. Oracle was never an operating system company before the Sun acquisition, and therefore contributing to operating system components like btrfs and Xen were historically a non-issue. My pessimistic view is that Oracle's FLOSS involvement won't go beyond what currently exists (and I even find myself worrying if others can pick up the slack on btrfs if (when?) Oracle starts marketing a proprietarized ZFS-based solution instead). In short, I expect Oracle's primary business will still be anti-FLOSS. Nevertheless, I'll try to quickly acknowledge it if it turns out I'm wrong.

  ---

  ⁰ Contrary to the popular receptions at the time, I was actually quite depressed both when, in 1999, Oracle announced first that they'd have a certified version of Oracle's database available for Red Hat Linux and when, in 2002, Oracle announced so-called “Unbreakable” Linux. These moves were not toward more software freedom, but rather to leverage the availability of a software freedom operating system, GNU/Linux, to sell proprietary licenses for Oracle databases. Neither event should have been heralded as anything but negative for software freedom.

  Posted on Wednesday 03 March 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

February

• 2010-02-22: SCALE 8x Highlights

  I just returned today (unfortunately on an overnight flight, which always causes me to mostly lose the next day to sleep problems) from SCALE 8x. I spoke about GPL enforcement efforts, and also was glad to spend all day Saturday and Sunday at the event.

  These are my highlights of SCALE 8x:

  • Karsten Wade's keynote was particularly good. It's true that some of his talk was the typical messaging we hear from Corporate Open Source PR people (which are usually called “Community Managers”, although Karsten calls himself a “Senior Community Gardener” instead). Nevertheless, I was persuaded that Karsten does seek to educate Red Hat internally to have the right attitude about FLOSS contribution. In particular, he opened with a an illuminating literary analogy (from Chris Grams) about Tom Sawyer manipulating his acquaintances into paying him to do his work. I hadn't seen Chris' article when it was published back in September, and found this (“new to me”) analogy quite compelling. This is precisely the kind of activity that I see happening with problematic copyright assignments. I think the Tom Sawyer analogy fits aptly to that situation, because a contributor first does some work without compensation (the original patch), and then is manipulated even further into giving up something of value (signing away copyrights for nothing in return) for the mere honor of being able to do someone else's work. It was no surprised that after Karsten's keynote, jokes abounded in the SCALE 8x hallways all weekend that we should nickname Canonical's new COO, Matt Asay, the “Tom Sawyer of Open Source”. I am sure Red Hat will be happy that their keynote inspired some anti-Canonical jokes.
  • Another Red Hat employee (who is also my good friend and former cow-orker), Richard Fontana, also gave an excellent talk that many missed, as it was scheduled in the very final session slot. Fontana put forward more details about his theory of the “Lex Mercatoria” of FLOSS and how it works in resolving licensing conflicts and incompatibility inside the community. He contrasted it specifically against the kinds of disputes that happen in normal GPL violations, which are primarily perpetrated by those outside the FLOSS world). I agreed with Fontana's conclusions, but his argument seemed to assume that these in-community licensing issues were destabilizing. I asked him about this, pointing out that the community is really good at solving these issues before they destabilize anything. Fontana agreed that they do get easily resolved, and revised his point to say that the main problem is that distribution projects (like Debian and Fedora) hold the majority of responsibility for resolving these issues, and that upstreams need to take more responsibility on this. (BTW, Karsten was also in the audience for Fontana's talk, has written a more detailed blog post about it.) Fontana noted to me after his talk that he thought I wasn't paying attention, as I was using my Android phone a lot during the talk. I was actually dent'ing various points from his talk. I realized when Fontana expressed this concern that perhaps we as speakers have to change our views about what it means when people seem focused on computing devices during a talk. (I probably would have thought the same as Fontana in the situation.) The online conversation during a talk is a useful part of the interaction. Stormy Peters even once suggested before a talk at Linux World that we should have a way to put dents up on the screen as people comment during a talk. I may actually try to find a way to do this next time I give a talk.
  • I also saw Brian Aker's presentation about Drizzle, which is a fork of the MySQL codebase that he began inside Sun and now maintains further (having left Sun before the Oracle merger completed). I was impressed to see how much Drizzle has grown in just a few years, and how big its user base is. (Being a database developer, Brian thinks user numbers in the tens of thousands is just a start, but there are many FLOSS projects that would be elated even to max out at tens of thousands users. While I admire his goals of larger user bases, I think they've already accomplished a lot.) I talked with Brian for an hour after his talk all about the GPL and the danger of single-copyright-held business models. He's avoided this for Drizzle, and it sounds like none of the consulting companies spouting up around the user community has too much power over the project. (Brian also blogged a summary of some of the points in the discussion we had.)
  • Because it directly time-conflicted Brian's talk, I missed my friend and colleague's Karen Sandler's talk about trademarks, but I hear it went well. Karen told me not to attend anyway since she said I already knew everything it contained, and that she would have went to Brian's talk too if my talk was against it. She did however make a brief appearance at my talk, so I feel bad my post-talk chat with Brian made it impossible for me to do the same for her talk.
  • I spoke extensively with Matt Kraai in the Debian booth. It was great to meet Matt for the first time, as he had previously volunteered on the Free Software Directory project when I was at FSF, and he's also contributed a lot of development effort to BusyBox. It's always strange but great to finally meet someone in person you've occasionally been in touch with for nearly a decade online.
  • Don Armstrong was also in the Debian booth. I got to know Don when we served on one of the GPLv3 discussion committees together, and I hadn't been in touch with him regularly since the GPLv3 process ended. He's continuing to do massive amounts of volunteer work for Debian, including being in charge of the bug tracking system! I asked him for some ideas in how to help Debian more, and he immediately mentioned the Debian/GNOME Bug Weekend coming up this weekend. I'm planning to get involved this weekend, and I hope others will too.
  • Finally, I had a number of important meetings with lots of people in the FLOSS world, such as Tarus Balog, Michael Dexter, Bob Gobeille, Deb Nicholson, Rob Savoye and Randal Schwartz. Ok, enough name-dropping. (BTW, Tarus has written about his trip as well, and mentioned our ongoing copyright assignment debate. Tarus argues that he can do non-promise copyright assignment in OpenNMS and still avoid the normal Open Core shareware-like outcomes, which he dubs “fauxpen source” for “fake open source”. Time will tell.)

  SCALE is really the gold standard of community-run, local FLOSS conferences. It is the inspiration for many of the other regional events such as OLF, SELF, and the like. A major benefit of these regional events is that while they draw speakers from all over the country, the average attendee is a local who usually cannot travel to the better-known events like OSCON.

  Posted on Monday 22 February 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-02-17: Computer Science Education Benefits from FLOSS

  I read with interest today when Linux Weekly News linked to Greg DeKoenigsberg's response to Mark Guzdial's ACM Blog post, The Impact of Open Source on Computing Education (which is mostly a summary of his primary argument on his personal blog). I must sadly admit that I was not terribly surprised to read such a post from an ACM-affiliated academic that speaks so negatively of FLOSS's contribution to Computer Science education.

  I mostly agree with (and won't repeat) DeKoenigsberg's arguments, but I do have some additional points and anecdotal examples that may add usefully to the debate. I have been both a student (high school, graduate and undergraduate) and teacher (high school and TA) of Computer Science. In both cases, software freedom was fundamental and frankly downright essential to my education and to that of my students.

  Before I outline my copious disagreements, though, I want to make abundantly clear that I agree with one of Guzdial's primary three points: there is too much unfriendly and outright sexist (although Guzdial does not use that word directly) behavior in the FLOSS community. This should not be ignored, and needs active attention. Guzdial, however, is clearly underinformed about the extensive work that many of us are doing to raise awareness and address that issue. In software development terms: it's a known bug, it's been triaged, and development on a fix is in progress. And, in true FLOSS fashion, patches are welcome, too (i.e., get involved in a FLOSS community and help address the problem).

  However, the place where my disagreement with Guzdial begins is that this sexism problem is unique to FLOSS. As an undergraduate Computer Science major, it was quite clear to me that a sexist culture was prevalent in my Computer Science department and in CS in general. This had nothing to do with FLOSS culture, since there was no FLOSS in my undergraduate department until I installed a few GNU/Linux machines. (See below for details.)

  Computer Science as a whole unfortunately remains heavily male-dominated with problematic sexist overtones. It was common when I was an undergraduate (in the early 1990s) that some of my fellow male students would display pornography on the workstation screens without a care about who felt unwelcome because of it. Many women complained that they didn't feel comfortable in the computer lab, and the issue became a complicated and ongoing debate in our department. (We all frankly could have used remedial sensitivity training!) In graduate school, a CS professor said to me (completely straight-faced) that women didn't major in Computer Science because most women's long term goals are to have babies and keep house. Thus, I simply reject the notion that this sexism and lack of acceptance of diversity is a problem unique to FLOSS culture: it's a CS-wide problem, AFAICT. Indeed, the CRA's Taulbee Survey shows (see PDF page 10) that only 22% of the tenure track CS faculty in the USA and Canada are women, and only 12% of the full professors are. In short, Guzdial's corner of the computing world shares this problem with mine.

  Guzdial's second point is the most offensive to the FLOSS community. He argues that volunteerism in FLOSS sends a message that no good jobs are available in computing. I admit that I have only anecdotal evidence to go on (of course, Guzdial quotes no statistical data, either), but in my experience, I know that I and many others in FLOSS have been successfully and gainfully employed precisely because of past volunteer work we've done. Ted T'so is fond of saying: Thanks to Linux, my hobby became my job and my job became my hobby. My experience, while neither as profound nor as important as Ted's, is somewhat similar.

  I downloaded a copy of GNU/Linux for the first time in 1992. I showed it to my undergraduate faculty, and they were impressed that I had a Unix-like system running on PC hardware, and they encouraged me to build a computer lab with old PC's. I spent the next three and half years as the department's volunteer⁰ sysadmin and occasional developer, gaining essential skills that later led me to a lucrative career as a professional sysadmin and software developer. If the lure of software freedom advocacy's relative poverty hadn't sidetracked me, I'd surely still be on that same career path.

  But that wasn't even the first time I developed software and got computers working as a volunteer. Indeed, every computer geek I know was compelled to write code and do interesting things with computers from the earliest of ages. We didn't enter Computer Science because we wanted to make money from it; we make a living in computing because we love it and are driven to do it, regardless of how much we get paid for it. I've observed that dedicated, smart people who are really serious about something end up making a full-time living at that something, one way or the other.

  Frankly, there's an undertone in Guzdial's comments on this point that I find disturbing. The idea of luring people to Computer Science through job availability is insidious. I was an undergraduate student right before the upward curve in CS majors, and a graduate student during the plateau (See PDF page 4 of the Taulbee Survey for graphs). As an undergraduate, I saw the very beginnings of people majoring in Computer Science “for the money”, and as a graduate student, I was surrounded by these sorts of undergraduates. Ultimately, I don't think our field is better off for having such people in it. Software is best when it's designed and written by people who live to make it better — people who really hate to go to bed with a bug still open. I must constantly resist the urge to fix any given broken piece of software in front of me lest I lose focus on my primary task of the moment. Every good developer I've met has the same urge. In my experience, when you see software developed by someone who doesn't have this drive, you see clearly that it's (at best) substandard, and (usually) pure junk. That's what we're headed for if we encourage students to major in Computer Science “for the money”. If students' passion is making money for its own sake, we should encourage them to be investment bankers, not software developers, sysadmins, and Computer Scientists.

  Guzdial's final point is that our community is telling newcomers that programming is all that matters. The only evidence Guzdial gives for this assertion is a pithy quote from Linus Torvalds. If Guzdial actually listened to interviews that Torvalds has given, Guzdial would hear that Torvalds cares about a lot more than just code, and spends most of his time in natural language discussions with developers. The Linux community doesn't just require code; it requires code plus a well-argued position of why the code is right for the users.

  Guzdial's primary point here, though, is that FLOSS ignores usability. Using Torvalds and the Linux community as the example here makes little sense, since “usability” of a kernel is about APIs for fellow programmers. Linus' kernel is the pinnacle of usability measured against the userbase who interacts with it directly. If a kernel is something non-technical users are aware of “using”, then it's probably not a very usable kernel.

  But Guzdial's comment isn't really about the kernel; instead, he subtly insults the GNOME community (and other GUI-oriented FLOSS projects). Usability work is quite expensive, but nevertheless the GNOME community (and others) desperately want it done and try constantly to fund it. In fact, very recently, there has been great worry in the GNOME community that Oracle's purchase of Sun means that various usability-related projects are losing funding. I encourage Guzdial to get in touch with projects like the GNOME accessibility and usability projects before he assumes that one offhand quote from Linus defines the entire FLOSS community's position on end-user usability.

  As a final anecdote, I will briefly tell the story of my year teaching high school. I was actively recruited (again, yet another a job I got because of my involvement in FLOSS!) to teach a high school AP Computer Science class while I was still in graduate school in Cincinnati. The students built the computer lab themselves from scratch, which one student still claims is one of his proudest accomplishments. I had planned to teach only ‘A’ topics, but the students were so excited to learn, we ended up doing the whole ‘AB’ course. All but two of the approximately twenty students took the AP exam. All who took it at least passed, while most excelled. Many of them now have fruitful careers in computing and other sciences.

  I realize this is one class of students in one high school. But that's somewhat the point here. The excitement and the “do it yourself” inspiration of the FLOSS world pushed a random group of high school students into action to build their own lab and get the administration to recruit a teacher for them. I got the job as their teacher precisely because of my involvement in FLOSS. There is no reason to believe this success story of FLOSS in education is an aberration. More likely, Guzdial is making oversimplifications about something he hasn't bothered to examine fully.

  Finally, I should note that Guzdial used Michael Terry's work as a jumping off point for his comments. I've met, seen talks by, and exchanged email with Terry and his graduate students. I admit that I haven't read Terry's most recent papers, but I have read some of the older ones and am familiar generally with his work. I was thus not surprised to find that Terry clarified that his position differs from Guzdial's, in particular noting that we found that open source developers most certainly do care about the usability of their software, but that those developers make an error by focusing too much on a small subset of their userbase (i.e., the loudest). I can certainly verify that fact from the anecdotal side. Generally speaking, I know that Terry is very concerned about FLOSS usability, and I think that our community should work with him to see what we can learn from his research. I have never known Terry to be dismissive of the incredible value of FLOSS and its potential for improvement, particularly in the area of usability. Terry's goal, it seems to me, is to convince and assist FLOSS developers to improve the usability of our software, and that's certainly a constructive goal I do support.

  (BTW, I mostly used last names through out this post because Mark, Michael, and Greg are relatively common names and I can think of a dozen FLOSS celebrities who have one of those first names. :)

  ---

  ⁰Technically, I was “paid” in that I was given my own office in the department because I was willing to do the sysadmin duties. It was nice to be the only undergraduate on campus (outside of student government) with my own office.

  Posted on Wednesday 17 February 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-02-08: The New Era of Big Company Forks

  I was intrigued to read Greg Kroah-Hartman's analysis of what's gone wrong with the Android fork of Linux, and the discussion that followed on lwn.net. Like Greg, I am hopeful that the Android platform has a future that will work closely with upstream developers. I also have my own agenda: I believe Android/Linux is the closest thing we have to a viable fully FaiF phone operating system platform to take on the proprietary alternatives like the BlackBerry and the iPhone.

  I believe Greg's comments hint at a “new era” problem that the FLOSS community hasn't yet learned to solve. In the “old days”, we had only big proprietary companies like Apple and Microsoft that had little interest in ever touching copylefted software. They didn't want to make improvements and share them. Back then (and today too) they prefer to consume all the permissively licensed Free Software they can, and release/maintain proprietary forks for years.

  I'm often critical of Google, but I must admit Google is (at least sometimes) not afraid of dumping code on a regular basis to the public, at least when it behooves them to do it⁰. A source-available Android/Linux helps Google, because Google executives know the profit can be found in pushing proprietary user-space Android application programs that link to Google's advertising. They don't want to fight with Apple or Research in Motion to get their ads onto those platforms; they'll instead use Free Software to shift the underlying platform.

  So, in this case, the interests of software freedom align a bit with Google's for-profit motive. We want a fully FaiF phone operating system, that also has a vibrant group of Free Software applications for that operating system. While Google doesn't care a bit about Free Software applications on the phone, they need a readily available phone operating system so that many hardware phone manufacturers will adopt it. The FLOSS community and Google thus can work together here, in much the same way various companies have always helped improve GNU/Linux on the desktop because they thought it would foil their competitors (i.e., Microsoft and Apple).

  Yet, the problematic spot for FLOSS developers is Google doesn't actually need our development help. Sure, Google needs the FLOSS licenses we developed, and they need to get access to the upstream. But they have that by default; all that knowledge and code is public. Meanwhile, they can easily afford to have their engineers maintain Android's Linux fork indefinitely, and can more or less ignore Greg's suggestions for shepherding the code upstream. A small company with limited resources would have to listen to Greg, lest the endeavor run out of steam. But Google has plenty of steam.

  We're thus left appealing to Google's sense of decency, goodwill, collaboration and other software freedom principles that don't necessarily make an impact on their business. This can be a losing battle when communicating with a for-profit company (particularly a publicly traded one). They don't have any self-interest nor for-profit reason to work with upstream; they can hire as many good Linux hackers as they need to keep their fork going.

  This new era problem is actually harder than the old problem. In other words, I can't simply write an anti-Google blog post here like I'd write an anti-Apple one. Google is releasing their changes, making them available. They even have a public git repository for (at least) the HTC Dream platform. True, I can and do criticize both Google and HTC for making some hardware interface libraries¹ proprietary, but that makes them akin to NVidia, not Microsoft and Apple.

  I don't have an answer for this problem; I suggest only that our community get serious about volunteer development and improvement of Android/Linux. When Free Software started, we needed people to spend their nights and weekends writing Free Software because there weren't any companies and for-profit business models to pay them yet. The community even donated to Free Software charitable non-profits to sponsor development that served the public. The need for that hasn't diminished; it's actually increased. Now, there is more code than ever available under FaiF licenses, but even more limited not-for-profit community resources to shepherd that code in a community-oriented direction. For-profit employers are beginning to control the destiny of more community developers, and this will lead to more scenarios like the one Greg describes. We need people to step forward and say: I want to do what's right with this code for this particular userbase, not what's right for one company. I hope someone will see the value in this community-directed type of development and fund it, but for the meantime, it has my nights and weekends. Just about every famous FLOSS hacker today started with that attitude. We need a bit more of that to go around.

  (I don't think I can end a blog post on this topic without giving a little bit of kudos to a company whom I rarely agree with: Novell. As near as I can tell, despite the many negative things Novell does, they have created a position for Greg that allows him to do what's right for Linux with what (appears to be) minimal interference. They deserve credit for this, and I think more companies that benefit from FLOSS should create more positions like this. Or, even better, create such positions through non-profit intermediaries, as the companies that fund Linux Foundation do for Linus Torvalds.)

  ---

  ⁰Compare this to Apple, which is so allergic to copyleft licenses that they will do bizarre things that are clearly against their own interest and more or less a waste of time merely to avoid GPL'd codebases.

  ¹Updated: I originally wrote drivers here, but Greg pointed out that there aren't actually Linux drivers that are proprietary. I am not sure what to call these various .so files which are clearly designed to interface with the HTC hardware in some way, so I just called them hardware interface libraries.

  Posted on Monday 08 February 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-02-02: I Think I Just Got Patented.

  I could not think of anything but the South Park quote, They took our jobs! when I read today Black Duck's announcement of their patent, Resolving License Dependencies For Aggregations of Legally-Protectable Content.

  I've read through the patent, from the point of view of someone skilled in this particular art. In fact, I'm specifically skilled in two distinct arts related to this patent: computer programming and Free Software license compatibility analysis. It's from that perspective that I took a look at this patent.

  (BTW, the thing to always remember about reading patents is that the really significant part isn't the abstract, which often contains pie-in-the-sky prose about what the patent covers. The claims are the real details of the so-called “invention”.)

  So, when I look closely at these claims, I am appalled to discover this patent claims, as a novel invention, things that I've done regularly, with a mix of my brain and a computer, since at least 1999. I quickly came to the conclusion that this is yet another stupid patent granted by the USPTO that it would be better to just ignore.

  Indeed, ever since Amazon's one-click patent, I've hated the inundation of “look what stupid patent was granted today” slashdot items. I think it's a waste of time, generally speaking, since the USPTO is granting many stupid software patents every single day. If we spend our time gawking and saying how stupid they are, we don't get any real work done.

  But, the (likely obvious) reason this caught my attention is that the patent covers activities I've done regularly for so long. It gives me this sick feeling in my stomach to read someone else claiming as an invention something I've done and considered quite obvious for more than a decade.

  I'm not a patent agent (nor do I want to be — spending a week of my life studying for a silly exam to get some credential hasn't been attractive to me since I got my Master's degree), but honestly, I can't see how this patented process isn't obvious to everyone skilled in the arts of FLOSS license evaluation and computer programming. Indeed, the process described is so simple-minded, that it's a waste of time in my view to spend time writing a software system to do it. With a few one-off 10-line Perl programs and a few greps, I've had a computer assist me with processes like this one many times since the late 1990s.

  I do feel some shame that I've now contributed to the “hey, everyone, let's gawk at this silly pointless surely-invalid patent” rant. I guess that I have new sympathy for website designers who were so personally offended regarding the Amazon one-click patent. I can now confirm first-hand: it does really feel different when the patent claims seem close to an activity you've engaged in yourself for many years prior to the patent application. It's when the horribleness of the software patent system starts to really hit home.

  The saddest part, though, is that Black Duck again shows itself as a company whose primary goal is to prey on people's fear of software freedom. They make proprietary software and acquire software patents with the primary goal of scaring people into buying stuff they probably don't need. I've spent a lot more time working regularly on FLOSS license compliance than anyone who has ever worked at Black Duck. Simply put, coming into (and staying in) compliance is a much simpler process than they say, and can be done easily without the use of overpriced proprietary analysis of codebases.

  Posted on Tuesday 02 February 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-02-01: Not All Copyright Assignment is Created Equal

  In an interview with IT Wire, Mark Shuttleworth argues that all copyright assignment systems are equal, saying further that what Intel, Canonical and other for-profit companies ask for in the process are the same things asked for by Free Software non-profit organizations like the Free Software Foundation.

  I've written about this before, and recently quit using Ubuntu in part because of Canonical's assignment policies (which are, as Mark correctly points out, not that different from other for-profit company's assignment forms.)

  However, it's quite disingenuous for companies to point to the long standing tradition of copyright assignment to the FSF as a justification for their own practices. There are two key differences that people like Shuttleworth constantly gloss over or outright ignore:

  • FSF promises to never make their software proprietary. Shuttleworth claims that All copyright assignment agreements empower dual licensing, and relicensing, but that is simply a false statement if you include FSF in the “All”. FSF promises to never proprietarize its versions of the software assigned to it and always release its versions of the software under Free Software licenses.
  • Non-profits have a different duty to the public. For-profit companies have one duty: to make money for their owners and/or shareholders. Non-profit organizations, by contrast, are chartered to carry out the public good. Therefore, they cannot liberally ignore what's in the public good just because it makes some money. An organization like FSF, which has a public charter that explicitly says that it seeks to advance software freedom, would fail to carry out its public mission if it engaged in proprietary relicensing.

  It seems that Mark Shuttleworth wants to confuse us about copyright assignment so we just start signing away our software. In essence, companies try to bank on the goodwill created by the FSF copyright assignment process over the years to convince developers to give up their rights under GPL and hand over their hard work for virtually nothing in return. We shouldn't give in.

  I am not opposed to copyright assignment in the least, in fact, I support it in many cases. However, without assurances that otherwise copylefted software won't be relicensed as proprietary software, developers should treat a copyright assignment process with maximum skepticism. Furthermore, we should simply not tolerate attempts by for-profit companies to confuse the developer community by comparing as equals copyright assignment systems that are radically different in their intent, execution, and consequences.

  (Some useful additional reading: my “Open Core” Is the New Shareware, Michael Meeks' Thoughts on Copyright Assignment, Dave Neary's Copyright assignment and other barriers to entry, and this LWN article.)

  Posted on Monday 01 February 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

January

• 2010-01-26: Proud to Be a Member of GNOME Foundation

  I suppose that I should have applied years ago to be a member of the GNOME Foundation. I have served since 2001 as the Free Software Foundation's representative on the GNOME Advisory Board, and have worked hard the last nine years to maintain a good relationship between the FSF and the GNOME Foundation. Indeed, I was very glad and willing when FSF asked me to continue to serve in this role as a volunteer after I left employment of the FSF in 2005.

  Regarding actual GNOME Foundation membership, though, I suppose that I previously felt under-qualified to apply since (a) my personal avoidance of all things GUI is widely known, and (b) obviously I haven't contributed any code or even documentation to GNOME. The most I've done on the development side is the occasional bug report over the years. Yet, ever since I was finally able to switch the non-technical users in my life over to GNU/Linux, I've been very grateful and supportive for GNOME and its mission to create a Free Software desktop that everyone — not just computer geeks — can use effectively.

  Meanwhile, Leslie Hawthorn reminded me recently to stop perpetuating the false belief that the only useful FLOSS contribution is code and documentation. I think that it was her point that encouraged me to apply for GNOME Foundation membership. I was excited to receive my acceptance this morning.

  Many people in the GNOME community already know that I'm a good contact person if you have any issues that relate to the relationship between GNOME and GNU or between FSF and GNOME Foundation (these are, BTW, two clear and distinct sets of relationships). I'll take this opportunity to remind everyone that if you ever have a concern related to these relationships, I am always glad to assist in my diplomatic role between the two organizations (and projects).

  And, of course, as I have for years, I remain available to the GNOME community for the occasional licensing policy questions and/or GPL enforcement assistance.

  I very much hope to go to GUADEC this year, as I have not been in six years! However, I'm a bit worried about the tight scheduling between it and OSCON (which would mean at least two and a half weeks away in a row!), but I'll strive to be there.

  Posted on Tuesday 26 January 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2010-01-14: Back Home, with Debian!

  By the end of 2004, I'd been running Debian ‘testing’ on my laptop since around early 2003. For almost two years, I'd lived with periodic instability — including a week in the spring of 2003 when I couldn't even get X11 started — for the sake of using a distribution that maximally respected software freedom.

  I'd had no trouble with ‘potato’ for its two year lifespan, but after 6-8 months of woody, I was backporting far too much and I couldn't spare the time for upkeep. Running ‘testing’ was the next best option, as I could pin myself for 3-6 months at a time on a particularly stable day and have a de-facto “release”. But, I slowly was unable to spare the time for even that work, and I was ready to throw up my hands in surrender.

  At just about that time, a thing called ‘warty’ was released. I'd already heard about this company, Canonical, as they'd tried earlier that year to buy a domain name I technically own (canonical.org), but had long since given over to a group of old friends. (They of course had no interest in selling such a “hot property”). This new distribution, Ubuntu, was Debian-based, and when installed, it “felt” like Debian. Canonical was committed to a six-month release schedule, so I said to myself: well, if I have to ‘go corporate’ again, I might as well go to something that works like the distribution I prefer. And so, my five year stint as an Ubuntu user began.

  Of course, I hadn't always been a Debian user. I started in 1992 with SLS and quickly moved to Slackware. When the pain of that got too great, I went “corporate” for a while back then, too. I used Red Hat Linux from early 1996 until 1998. I ultimately gave up Red Hat because the distribution eventually became focused around the advancement of the company. They were happy to include lots of proprietary software — indeed, in the later 1990s, Red Hat CDs typically came with as many as two extra CDs filled with proprietary software. Red Hat (the company) had earlier made some efforts to appease us harder-core software-freedom folks. But, by the late 1990s, their briefly-lived RMS (aka Red Hat Means Source) distribution had withered completely. By then, I truly regretted my 1996 decision to go corporate, and fell in love quickly with Debian and its community-led, software-freedom-driven community. I remained a Debian user from 1998 until 2004.

  But, by the end of 2004, the pain of waiting for ‘sarge’ was great. So, for technical reasons only, “going corporate” again seemed like a reasonable trade-off. Ubuntu initially looked basically like Debian: ‘main’ and ‘universe’ were FaiF, ‘restricted’ was like ‘non-free’.

  Sadly, though, a for-profit, corporate-controlled distribution can never remain community-oriented. A for-profit company is eventually always going to put the acquisition of wealth above any community principle. So it has become with Ubuntu, in my view. The time has come (for me, at least) to go back to a truly community-oriented, software-freedom-respecting distribution. (Hopefully, I'll also never be tempted to leave again.)

  I didn't take this decision lightly, and didn't take it for only one reason. I've gone back to Debian for three (now) seven specific reasons:

  • UbuntuOne's server side system is proprietary software with no prospects of liberation. This has been exacerbated since Canonical now heavily focuses on strong integration of UbuntuOne into the desktop for the Lucid release. It seems clear that one of Canonical's top goals is to convince every Ubuntu user to rely regularly on new proprietary software and services.⁰
  • Canonical has become too aggressive with community-unfriendly copyright assignment policies. Copyright assignment on Free Software can be put to good uses. However, most for-profit corporations design their copyright assignment process primarily to circumvent the company's potential copyleft obligations; Canonical's copyright assignment is sadly typical in that regard. Even worse, Canonical's management has become increasingly more aggressive in pressuring the community into accepting such copyright assignment policies as a fait accompli. (I'll likely write more on this issue this year, but in the meantime, my “Open Core” Is the New Shareware, Michael Meeks' Thoughts on Copyright Assignment, Dave Neary's Copyright assignment and other barriers to entry, and this LWN article are all good “further reading” resources.)
  • The line between ‘restricted’ and ‘main’ has become far too blurry. I was very glad when I first saw Ubuntu's “you're about to install restricted drivers” warning window, and I find that a good way to deal with the issue. However, there are many times (particularly during initial install) when Ubuntu doesn't even inform the user that proprietary software has been installed. I realize that there's a reasonable trade-off between (a) making someone's hardware work (so they don't think Microsoft is better merely because “it works”) and (b) having a fully FaiF system. However, this trade-off is only reasonable when the users are told clearly that they own hardware made by vendors opposed to software freedom. If the users never know, how will they know what hardware to avoid in the future?
  • Updated on 2010-01-19: This one is less of an issue to me than the others, but it shows the same pattern of Let's do more proprietary software on our platform that Red Hat went through in the 1990s. Namely, Canonical is now directly encouraging customers to run proprietary software on Ubuntu. (Updated on 2010-02-03: it turns out Canonical was already doing this a long time ago but I didn't know about it until 2010-01-19. (Thanks to J.B. Nicholson-Owens for the info on this.))
  • Updated on 2010-01-25: osamak kindly pointed out that Canonical also has plans to offer a facility for installing third-party proprietary software, called the “Software Center”. This appears to be similar to services that help install proprietary software on GNU/Linux systems such as Linspire's system and Click-and-Run.
  • Updated on 2010-02-06: Canonical has named Matt Asay its COO. Matt has an often stated that sometimes proprietary software is a better option for customers and believes that software freedom, as a political and moral cause, should be given up, in favor of pragmatically providing proprietary solutions whenever it is convenient. Specifically, in Matt's own words:

    Sometimes, after all, an open-source project is absolutely the wrong choice for a customer … The path forward is open source, not free software. Sometimes that openness will mean embracing Microsoft in order to meet a customer's needs.

    I would not want to run a distribution led by someone who believes proprietary software and FLOSS are equally legitimate. As a side note, I also find it quite bizarre that Canonical would hire someone to run its operations whose past statements clearly disagree with closing Ubuntu Bug 1. (Also, Matt Asay said in an interview that Canonical has a goal of deploying more proprietary application software.)
  • Updated on 2010-02-17, 2010-04-21: After the (very good) news 13 months ago that Canonical would release LaunchPad under AGPLv3, Canonical abandoned the authentication and login system for LaunchPad (and many other Ubuntu/Canonical online systems), and replaced it with proprietary software, but then released it in April 2010.

  (Updated on 2010-02-17: As can be seen above, my mere list of three reasons posted just one month ago has now more than doubled! It's as if Canonical made a 2010 plan to “do less software freedom”, and is executing it with amazing corporate efficiency. As Queen Gertrude says in Hamlet, One woe doth tread upon another's heel, so fast they follow.)

  When considering all this and taking a step back and look at the status of major distributions, my honest assessment is this: among the two primary corporate-controlled-but-dabbling-in-community-orientation distributions (aka Fedora and Ubuntu), Fedora is clearly much more software-freedom-friendly. Nevertheless, since I've twice gone corporate and ultimately regretted it, I decided it was time to go back home — back to Debian.

  So, during the last week of 2009, I took nearly two full days off to reinstall and configure my laptop from scratch with lenny. I've thus been back on Debian since 2010-01-01. Twelve days in, I am very impressed. Really, all the things I liked about Ubuntu are now available upstream as well. This isn't the distribution I left in 2004; it's much better, all while being truly community-oriented and software-freedom-respecting. It's good to be home. Thank you, Debian developers.

  ---

  ⁰ For more information on the danger that proprietary network services pose to software freedom, please see the Franklin Street Statement.

  Posted on Thursday 14 January 2010 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

2009

December

• 2009-12-14: Litigation filed against Various GPL Violators

  I probably won't comment too much on the specifics at this point, but I wanted to make sure everyone saw that SFLC filed a lawsuit against fourteen GPL violators today on behalf of the Software Freedom Conservancy and Erik Andersen.. A PDF copy of the complaint is available.

  Posted on Monday 14 December 2009 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2009-12-10: Thanks for Rafael Rivera, an Excellent GPL Compliance Engineer

  I'd like to congratulate Rafael Rivera on his successful GPL compliance work regarding the Microsoft WUDT software, which is apparently used to make ISOs from stuff you downloaded from Microsoft software.

  I'm of course against the idea of using Microsoft Windows, and why you'd ever want to make an ISO out of some Microsoft Windows stuff is beyond my comprehension. However, Rafael identified that the WUDT was based on some GPL'd software, and as such he was quite correct in demanding that Microsoft comply with the terms of the GPL (as it has done before, for example, with its Windows Services for Unix). Rafael was first to discover and point out this violation. More importantly, he also did what we in the GPL enforcement world call the “compliance engineering work”, which includes confirming the violation exists by technical measures, and checking that the complete and corresponding source code actually builds and installs the binary as expected.

  That importance of that latter part of the work is unfortunately not often identified. GPL is designed to hook up the legal requirements of a copyright license with certain technical requirements needed to allow downstream users to modify and improve the software. This is the true innovation of the GPL: to make copyright law into a tool that gives users the actual means to improve and redistribute modified versions of software.

  When we check to see if someone is in compliance, it's not merely about seeing if they dumped a big pile of source onto the world. We also have to check carefully that the source builds and that the process produces a working binary that can be installed by the user. That's why GPLv2 requires scripts to control compilation and installation of the executable and what GPLv3 clarifies that requirement even further into the formally defined Installation Information.

  Thanks again to Rafael for doing this work. While everyone knows how often I fault Microsoft, I have to say they did a timely job in this particular case. A little under a month is actually the best one can hope for from initial identification to a violator about a problem to having in our hands complete and corresponding source code (or “C&CS”, as we GPL enforcement geeks call it). Microsoft should have known better than to screw this up after years of working with the GPL, but everyone makes mistakes, and the real measure of a company is how quickly they redress a mistake.

  Now if we could just get Microsoft to stop the more harmful mistake of attacking FLOSS with patents, but that's a tougher problem to solve…

  Posted on Thursday 10 December 2009 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2009-12-06: The Anatomy of a Modern GPL Violation

  I've been thinking the last few weeks about the evolution of the GPL violation. After ten years of being involved with GPL enforcement, it seems like a good time to think about how things have changed.

  Roughly, the typical GPL violation tracks almost directly the adoption and spread of Free Software. When I started finding GPL violations, it was in a day when Big Iron Unix was still king (although it was only a few years away from collapse), and the GNU tools were just becoming state of the art. Indeed, as a sysadmin, I typically took a proprietary Unix system, and built a /usr/local/ filled with the GNU tools, because I hated POSIX tools that didn't have all the GNU extensions.

  At the time, many vendors were discovering the same frustrations I was as a sysadmin. Thus, the typical violation in those days was a third-party vendor incorporating some GNU tools into their products, for use on some Big Iron Unix. This was the age of the violating backup product; we saw frequently backup products that violated the GPL on GNU tar in those days.

  As times changed, and computers got truly smaller, the embedded Unix-like system was born. GNU/Linux and (more commonly) BusyBox/Linux were the perfect solutions for this space. What was once a joke on comp.os.linux.advocacy in the 1990s began to turn into a reality: it was actually nearly possible for Linux to run on your toaster.

  The first class of embedded devices that were BusyBox/Linux-based were the wireless routers. Throughout the 2000s, the typical violation was always some wireless router. I still occasionally see those types of products violating the GPL, but I think the near-constant enforcement done by Erik Andersen, FSF, and Harald Welte throughout the 2000's has led the wireless router violation to become the exception rather than the rule. That enforcement also led to the birth of community-focused development of the OpenWRT and DD-WRT, that all started from that first enforcement that we (Erik, Harald and FSF (where I was at the time)) all did together in 2002 to ensure the WRT54G source release.

  In 2009, there's a general purpose computer in almost every electronics product. Putting a computer with 8MB RAM and a reasonable processor in a device is now a common default. Well, BusyBox/Linux was always the perfect operating system for that type of computer! So, when you walk through the aisles of the big electronics vendors today, it's pretty likely that many of the devices you see are BusyBox/Linux ones.

  Some people think that a company can just get away with ignoring the GPL and the requirements of copyleft. Perhaps if a company has five customers total, and none of them ask for source, your violation may never be discovered. But, if you produce a mass market product based on BusyBox/Linux, some smart software developer is going to eventually buy one. They are going to get curious, and when they poke, they'll see what you put in there. And, that developer's next email is going to be to me to tell me all about that device. In my ten years of enforcement experience, I find that a company's odds of “getting away” with a GPL violation are incredibly low. The user community eventually notices and either publicly shames the company (not my preferred enforcement method), or they contact someone like me to pursue enforcement privately and encourage the company in a friendly way to join the FLOSS community rather than work against it.

  I absolutely love that so many companies have adopted BusyBox/Linux as their default platform for many new products. Since circa 1994 when I first saw the “can my toaster run Linux?” joke, I've dreamed of time when it would be impossible to buy a mass-market electronics product without finding FLOSS inside. I'm delighted we've nearly reached that era during my lifetime.

  However, such innovation is made possible by the commons created by the GPL. I have dedicated a large portion of my adult life to GPL enforcement precisely because I believe deeply in the value of that commons. As I find violator after violator, I look forward to welcoming them to our community in a friendly way, and ask them to respect the commons that gave them so much, and give their code back to the community that got them started.

  Posted on Sunday 06 December 2009 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

November

• 2009-11-08: GPL Enforcement: Don't Jump to Conclusions, But Do Report Violations

  In one of my favorite movies, Office Space, Tom Smykowski (one of the fired employees) has a magic-eight-ball-style novelty product idea: a “Jump to Conclusions” mat. Sometimes, I watch discussions in the software freedom community and think that, as a community, we're all jumping around on one of these mats.

  I find that people are most likely to do this when something seems novel and exciting. I don't really blame anyone for doing it; I do it myself when I have discovered an exciting thing that's new to me, even if it's well known by others. But, often, this new thing is actually rather mundane, and it's better to check in with the existing knowledge about the idea before “jumping” to any conclusions. In other words, the best square on the mat for us to land on is the one that reads: Think again!

  Meanwhile, as some who follow my microblog know, I've been on a mission in recent months to establish just how common and mundane GPL violations are. Since 21 August 2009, I've been finding one new GPL violating company per day (on average) and I am still on target to find one per day for 365 days straight. When I tell this to people who are new to GPL enforcement, they are surprised and impressed. However, when I tell people who have done GPL enforcement themselves, they usually say some version of: Am I supposed to be impressed by that? Couldn't a monkey do that? Fact is, the latter are a little bit right: there are so many GPL violations that I might easily be able to go on finding one per day for two years straight.

  In short, GPL violations are common and everyday occurrences. I believe firmly they should be addressed, and I continue to dedicate much of my life to resolve them. However, finding yet another GPL violation isn't a huge and earth-shaking discovery. Indeed, it's what I was doing today to kill time while drinking my Sunday morning coffee.

  I don't mean to imply that I don't appreciate greatly when folks find new GPL violations. I think finding and reporting GPL violations is a very valuable service, and I wouldn't spend so much time finding them myself if I didn't value the work highly. But, the work is more akin to closing annoying bugs than it is to launching a paradigm-shifting FLOSS project. Closing bugs is an essential part of FLOSS development, but no one blogs about every single bug they close (although maybe we do microblog them ;).

  Having this weekend witnessed another community tempest about a potential GPL violation, I decided to share a few guidelines that I encourage everyone to follow when finding a GPL violation. (In other words, what follows are a some basic guidelines for reporting violations; other such guides are also available at the FSF's site and the gpl-violations.org site.)

  • Assume the violation is an oversight or an accident by the violator until you have clear evidence that tells you differently. I'd say that 98% of the violations I've ever worked on since 1998 have been unintentional and due primarily to negligence, not malice.

  • Don't go public first. Back around late 1999, when I found my first GPL violation from scratch, I wanted to post it to every mailing list I could find and shame that company that failed to respect and cooperate with the software freedom community. I'm glad that I didn't do that, because I've since seen similar actions destroy the lines of communication with violators, and make resolution tougher. Indeed, I believe that if the Cisco/Linksys violations had not been a center of public ridicule in 2003 when I (then at the FSF) was in the midst of negotiating with them for compliance, we would not have ended up with such a long saga to resolution.

  • Do contact the copyright holders, or their designated enforcement agents. Since the GPL is a copyright license, if the violator fails to comply on their own, only the copyright holder (typically) has the power to enforce the license⁰. Here's a list of contact addresses that I know for reporting various violations (if you know more such addresses, please let me know and I'll add them here):

    • BusyBox and uClibc: <gpl@busybox.net> (this address is primarily answered by me currently)
    • FSF copyrights (many GNU programs such as GnuPG, wget, glibc, gcc, binutils): <license-violation@fsf.org>
    • iptables, netfilter, mtd, initrd and msdosfs: <license-violation@gpl-violations.org>
    • Samba: <licensing@samba.org>
    • XviD: <violations@xvid.org>

    If the GPL'd project you've found a violation on isn't on the list above, just find email addresses of people with commit access to the repository for the project or with email addresses in the MAINTAINERS or CONTRIBUTORS files. It's better not to post the violation to a public discussion list for the project, as that's just “going public”.

  • Never treat a “community violator” the same way as a for-profit violator. I believe there is a fundamental difference between someone who makes a profit during the act of infringement than someone who merely seeks to contribute as a volunteer and screws something up. There isn't a perfect line between the two — it's a spectrum. However, those who don't make any money from their infringement are probably just confused community members who misunderstood the GPL and deserve pure education and non-aggressive enforcement. Those who make money from the infringement deserve some friendly education too, of course, but ultimately they are making a profit by ignoring the rights of their users. I think these situations are fundamentally different, and deserve different tactics.

  • Once you've reported a violation, please be patient with those of us doing enforcement. There are always hundreds of GPL violations that need action, and there are very few of us engaged in regular and active enforcement. Also, most of us try to get compliance not just on the copyrights we represent, but all GPL'd software. (This behooves both the software freedom community and the violator, as the former wants to see broad compliance, and the latter doesn't want to deal with each copyright holder individually). Thus, it takes much time and effort to do each enforcement action. So, when you report a new violation, it might take some time for the situation to resolve.

  • Do try your best to request source from the violator on your own. While making the violation public doesn't help, inquiring privately does often help. If you have received distribution of a binary that you think is GPL'd or LGPL'd (or used a network service that you think is AGPL'd), do write to the violator (typically best to use the technical support channels) and ask for the complete and corresponding source code. Be as polite and friendly as possible, and always assume it is their intention to comply until you have specific evidence that they don't intend to do so.

  • Share as much good information with the violator as you can to encourage their compliance. My colleagues and I wrote A Practical Guide to GPL Compliance for just this purpose.

  We need a careful balance regarding GPL enforcement. Remember that the primary goal of the GPL is encourage more software freedom in the world. For many violators, the first experience the violator has with FLOSS is an enforcement action. We therefore must ensure that enforcement action is reasonable and friendly. I view every GPL violator as a potential FLOSS contributor, and try my best to open every enforcement action with that attitude. I am human and thus sometimes become more frustrated with uncooperative violators than I should be. However, striving for kindness with violators only helps give a great image to the software freedom community.

  ---

  ⁰In some situations, there are a few possibilities for users that exist if the copyright holder is unable or unwilling to enforce the GPL. We've actually recently seen an interesting successful enforcement by a user. I plan to blog in detail about this soon.

  Posted on Sunday 08 November 2009 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2009-11-04: Android/Linux's Future and Advancement of Mobile Software Freedom

  Harald Welte knows more about development of embedded systems than I ever will. So, I generally defer completely to his views about software freedom development for embedded systems. However, as you can tell by that opening, I am setting myself up to disagree a little bit with him just this once on the topic. :)

  But first, let me point out where we agree: I think his recent blog post about what Android/Linux is not should be read by everyone interested in software freedom for mobile devices. (Harald's post also refers to a presentation by Matt Porter. I agree with Harald that talk is worth looking at closely.) The primary point Matt and Harald both make is one that Stallman has actually made for years: Linux is an operating system kernel, not a whole system for a user. That's why I started saying Android/Linux to refer to this new phone platform. It's just the kernel, Linux, with a bunch of Java stuff on top. As Matt points out, it doesn't even use a common Linux-oriented C Library, such as uClibc or the GNU C Library; it used a BSD-derived libc called Bionic.

  Indeed, my colleague Aaron Williamson discovered this fact quickly five months ago when he started trying to make a fully FaiF Android/Linux platform on the HTC Dream. I was amazed and aghast when he told me about adb and how there is no real shell on the device by default. It's not a GNU/Linux system, and that becomes quickly and painfully obvious to anyone who looks at developing for the platform. On this much, I agree with Harald entirely: this is a foreign system that will be very strange to most GNU/Linux hackers.

  Once I learned this fact, I immediately pondered: Why did Google build Android in this way? Why not make it GNU/Linux like the OpenMoko? I concluded that there are probably a few reasons:

  • First, while Linux is easy to cram into a small space, particularly with BusyBox and uClibc, if you want things both really small and have a nice GUI API, it's a bit tougher to get right. There is a reason the OpenMoko software stack was tough to get right and still has issues. Maemo, too, has had great struggles in its history that may not be fully overcome.
  • Second, Google probably badly wanted Java as the native application language, due to its ubiquity. I dislike Java more than the average, but there's no denying that nearly all undergraduate Computer Science students of the last ten years did most of their work in Java. Java is more foreign to most GNU/Linux developers than Python, Perl, Ruby and the like, but to the average programmer in the world, Java is the lingua franca.
  • Third, and probably most troubling, Google wanted to have as little GPL'd and LGPL'd stuff in the stack as possible. Their goal isn't software freedom; it is to convince phone carriers and manufacturers to make Google's proprietary applications the default mobile application set. The operating system is pure commodity to sell the proprietary applications. So, from Google's perspective, the more permissively licensed stuff in the Android/Linux base system, the better.

  Once you ponder all this, the obvious next question is: Should we bother with this platform, or focus on GNU/Linux instead? In fact, this very question comes up almost weekly over on the Replicant project's IRC channel (#replicant on freenode). Harald's arguments for GNU/Linux are good ones, and as I tell my fellow Replicant hackers, I don't begrudge anyone who wants to focus on that line of development. However, I think this is the place where I disagree with Harald: I think the freed Android code does have an important future in the advancement of software freedom.

  We have to consider carefully here, as Android/Linux puts us in a place software freedom developers have never been in before. Namely, we have an operating system whose primary deployments are proprietary, but the code is mostly available to us as Free Software, too. Furthermore, this operating system runs on platforms that we don't have a fully working port of GNU/Linux yet. I think these factors make the decision to port GNU/Linux or fork the mostly FaiF release into nearly a coin-flip decision.

  However, when deciding where to focus development effort, I think the slight edge goes to Android/Linux. It's not a huge favorite — maybe 54% (i.e., for my fellow poker players, all-in-prelfop in HE, Android would be the pair, not the unsuited overcards :). Android/Linux deserves the edge primarily because Google and their redistributors (carriers and phone makers) will put a lot of marketing and work into gaining public acceptance of “Android” as an iPhone replacement. We can take advantage of this, and say: What we have is Android too, but you can modify and improve it and run more applications not available in the Android Market! Oh, and if you really really do want that proprietary application from the Market, those will run on our system, too (but we urge you not to use proprietary software). It's simply going to be easier to get people to jailbreak their phones and install a FaiF firmware if it looks almost identical to the one they have, but with a few more features they don't have already.

  So, by all means, if porting GNU/Linux and/or BusyBox/Linux to strange new worlds is your hobby, then by all means make it run on the HTC Dream too. In fact, as a pure user I'll probably prefer it once it's ready for prime time. However, I think the strategic move to get more software freedom in the world is to invest development effort into a completely freedom-respecting fork of Android/Linux. (And, yet another shameless plug, we need driver hacker help on Replicant! :).

  Posted on Wednesday 04 November 2009 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

October

• 2009-10-26: Software Freedom on Mobile Devices

  I agree pretty completely with Harald Welte's comments regarding Symbian. I encourage everyone to take a look at his comments.

  We are in a very precarious time with regard to the freedom of mobile devices. We currently have no truly Free Software operating system that does the job, and there are multiple companies trying to get our attention with code releases that have some Free Software in them. None of these companies have pro-software-freedom motives about these issues (obviously, they are for-profit companies, who focus solely on their own profits). So, we have to carefully analyze what these proprietary software companies are up to, why they are releasing some code, and determine if we'll be successful forking these platforms to build a fully software freedom phone platform.

  We thus must take care not to burn our developer time on likely hopeless codebases. I think Harald's analysis convinces me that Symbian is such a hopeless codebase. They haven't released software we can build for any known phone for sale, and we don't have a compiler that can build the stuff. It's also under a license that isn't a bad one by any means, but it is however not a widely used license for operating system software. Symbian's release, thus, is purely of academic interest to historians who might want to study what phone software looked like at the turn of the millennium before the advent of Linux-based phones.

  Currently, given the demise of mass-market OpenMoko production, our best hope, in my opinion, is the HTC Dream running a modified version of Android/Linux. We don't have 100% Free Software even for that yet, but we are actively working on it, and the list of necessary-to-work proprietary components is down to two libraries. Plus, the Maemo software (and the new device it runs on, not even released yet) is the only other option, and it has quite an extensive list of proprietary components. As far as we can tell currently, the device may even be unusable without a large amount of proprietary software.

  Even so, Android/Linux isn't a Dream (notwithstanding the name of the most widely used hardware platform). It's developed generally by a closed community, who throw software over the wall when they see fit, and we'll have to maintain forks to really make a fully Free Software version. But this is probably going to be true of any Free Software phone platform that a company releases anyway.

  I'll keep watching and expect my assessment will change if facts change. However, unless I see that giant laundry list of proprietary components in Maemo decreasing quickly, I think I'll stick with the least of all these evils, Android/Linux on the HTC Dream. It's by far the closest to having a fully free software platform. Since the only way to get us to freedom is to replace proprietary components one-by-one, picking the closest is just the best path to freedom. At the very least, we should eliminate platforms for which the code can't even be compiled!

  Posted on Monday 26 October 2009 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2009-10-16: “Open Core” Is the New Shareware

  There has been some debate recently about so-called “Open Core” business models. Throughout the history of Free Software, companies have loved to come up with “innovative” proprietary-like ways to use the FLOSS licensing structures. Proprietary relicensing, a practice that I believe has proved itself to have serious drawbacks, was probably the first of these, and now Open Core is the next step in this direction. I believe the users embracing these codebases may be ignoring a past they're condemned to repeat.

  Like most buzzwords, Open Core has no real agreed-upon meaning. I'm using it to describe a business model whereby some middleware-ish system is released by a single, for-profit entity copyright holder, who requires copyright-assigned changes back to the company, and that company sells proprietary add-ons and applications that use the framework. Often, the model further uses the GPL to forbid anyone but the copyright-holding company to make such proprietary add-on applications (i.e., everyone else would have to GPL their applications). In the current debate, some have proposed that a permissive license structure can be used for the core instead.

  Ultimately, “Open Core” is a glorified shareware situation. As a user, you get some subset of functionality, and may even get the four freedoms with regard to that subset. But, when you want the “good stuff”, you've got to take a proprietary license. And, this is true whether the Core is GPL'd or permissively licensed. In both cases, the final story is the same: take a proprietary license or be stuck with cripple-ware.

  This fact remains true whether the Open Core is under a copyleft license or a permissive one. However, I must admit that a permissive license is more intellectually honest to the users. When users encounter a permissive license, they know what they are in for: they may indeed encounter proprietary add-ons and improvements, either from the original distributor or a third party. For example, Apple users sadly know this all too well; Apple loves to build on a permissively licensed core and proprietarize away. Yet, everyone knows what they're getting when they buy Apple's locked down, unmodifiable, and programmer-unfriendly products.

  Meanwhile, in more typical “Open Core” scenarios, the use of the GPL is actually somewhat insidious. I've written before about how the copyleft is a tool, not an end in itself. Like any tool, it can be misused or abused. I think using the GPL as a tool for corporate control over users, while legally permissible, is ignoring the spirit of the license. It creates two classes of users: those precious few that can proprietarize and subjugate others, and those that can't.¹

  This (ab)use of GPL has led folks like Matt Aslett to suggest that the permissive licensing solution would serve this model better. While I've admitted such a change would have some level of increased intellectually honesty, I don't think it's the solution we should strive for to solve the problem. I think Aslett's completely right when he argues that GPL'd “Open Core” became popular because it's Venture Capitalists' way of making peace with freely licensed copyrights. However, heading to an Apple-like permissive only structure only serves to make more Apple-like companies, and that's surely not good for software freedom either. In fact, the problem is mostly orthogonal to licensing. It's a community building problem.

  The first move we have to make is simply give up the idea that the best technology companies are created by VC money. This may be true if your goal is to create proprietary companies, but the best Free Software companies are the small ones, 5-10 employees, that do consulting work and license all their improvements back to a shared codebase. From low-level technology like Linux and GCC to higher-level technology like Joomla all show that this project structure yields popular and vibrant codebases. The GPL was created to inspire business and community models like these examples. The VC-controlled proprietary relicensing and “Open Core” models are manipulations of the licensing system. (For more on this part of my argument, I suggest my discussions on Episode 0x14 of the Software Freedom Law Show.)

  I realize that it's challenging for a community to create these sort of codebases. The best way to start, if you're a small business, is to find a codebase that gets you 40% or so toward your goal and start contributing to the code with your own copyrights, licensed under GPL. Having something that gets you somewhere will make it easier to start your business on a consulting basis without VC, and allow you to be part of one of these communities instead of trying to create an “Open Core” community you can exploit with proprietary licensing. Furthermore, the fact that you hold copyright alongside others will give you a voice that must be heard in decision-making processes.

  Finally, if you find an otherwise useful single-corporate-copyright-controlled GPL'd codebase from one of these “Open Core” companies, there is something simple you can do:

  Fork! In essence, don't give into pressure by these companies to assign copyright to them. Get a group of community developers together and maintain a fork of the codebase. Don't be mean about it, and use git or another DVCS to keep tracking branches of the company's releases. If enough key users do this and refuse to assign copyright, the good version will eventually become community one rather than the company-controlled one.

  My colleague Carlo Piana points out a flaw in this plan, saying the ant cannot drive the elephant. While I agree with Carlo generally, I also think that software freedom has historically been a little bit about ants driving elephants. These semi-proprietary business models are thriving on the fundamental principle of a proprietary model: keep users from cooperating to improve the code on which they all depend. It's a prisoner's dilemma that makes each customer afraid to cooperate with the other for fear that the other will yield to pressure not to cooperate. As the fictional computer Joshua points out, this is a strange game. The only winning move is not to play.

  The software freedom world is more complex than it once was. Ten years ago, we advocates could tell people to look for the GPL label and know that the software would automatically be part of a freedom-friendly, software sharing community. Not all GPL'd software is created equal anymore, and while the right to fork remains firmly in tact, the realities of whether such forks will survive, and whether the entity controlling the canonical version can be trusted is another question entirely. The new advice is: judge the freedom of your codebase not only on its license, but also on the diversity of the community that contributes to it.

  ---

  ¹I must put a fine point here that the only way companies can manipulate the GPL in this example is by demanding full copyright assignment back to the corporate entity. The GPL itself protects each individual contributor from such treatment by other contributors, but when there is only one contributor, those protections evaporate. I must further note that for-profit corporate assignment differs greatly from assignment to a non-profit, as non-profit copyright assignment paperwork typically includes broad legal assurances that the software will never be proprietarized, and furthermore, the non-profit's very corporate existence hinges on engaging only in activity that promotes the public good.

  Posted on Friday 16 October 2009 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2009-10-11: Denouncing vs. Advocating: In Defense of the Occasional Denouncement

  For the last decade, I've regularly seen complaints when we harder-core software freedom advocates spend some time criticizing proprietary software in addition to our normal work preserving, protecting and promoting software freedom. While I think entire campaigns focused on criticism are warranted in only extreme cases, I do believe that denouncement of certain threatening proprietary technologies is a necessary part of the software freedom movement, when done sparingly.

  Denouncements are, of course, negative, and in general, negative tactics are never as valuable as positive ones. Negative campaigns alienate some people, and it's always better to talk about the advantages of software freedom than focus on the negative of proprietary software.

  The place where negative campaigns that denounce are simply necessary, in my view, is when the practice either (a) will somehow completely impeded the creation of FLOSS or (b) has become, or is becoming, widespread among people who are otherwise supportive of software freedom.

  I can think quickly of two historical examples of the first type: UCITA and DRM. UCITA was a State/Commonwealth-level law in the USA that was proposed to make local laws more consistent regarding software distribution. Because the implications were so bad for software freedom (details of which are beyond scope of this post but can be learned at the link), and because it was so unlikely that we could get the UCITA drafts changed, it was necessary to publicly denounce the law and hope that it didn't pass. (Fortunately, it only ever passed in my home state of Maryland and in Virginia. I am still, probably pointlessly, careful never to distribute software when I visit my hometown. :)

  DRM, for its part, posed an even greater threat to software freedom because its widespread adoption would require proprietarization of all software that touched any television, movie, music, or book media. There was also a concerted widespread pro-DRM campaign from USA corporations. Therefore, grassroots campaigns denouncing DRM are extremely necessary even despite that they are primarily negative in operation.

  The second common need for denouncement when use of a proprietary software package has become acceptable in the software freedom community. The most common examples are usually specific proprietary software programs that have become (or seem about to become) “all but standard” part of the toolset for Free Software developers and advocates.

  Historically, this category included Java, and that's why there were anti-Java campaigns in the Free Software community that ran concurrently with Free Software Java development efforts. The need for the former is now gone, of course, because the latter efforts were so successful and we have a fully FaiF Java system. Similarly, denouncement of Bitkeeper was historically necessary, but is also now moot because of the advent and widespread popularity of Mercurial, Git, and Bazaar.

  Today, there are still a few proprietary programs that quickly rose to ranks of “must install on my GNU/Linux system” for all but the hardest-core Free Software advocates. The key examples are Adobe Flash and Skype. Indeed, much to my chagrin, nearly all of my co-workers at SFLC insist on using Adobe Flash, and nearly every Free Software developer I meet at conferences uses it too. And, despite excellent VoIP technology available as Free Software, Skype has sadly become widely used in our community as well.

  When a proprietary system becomes as pervasive in our community as these have (or looks like it might), it's absolutely time for denouncement. It's often very easy to forget that we're relying more and more heavily on proprietary software. When a proprietary system effectively becomes the “default” for use on software freedom systems, it means fewer people will be inspired to write a replacement. (BTW, contribute to Gnash!) It means that Free Software advocates will, in direct contradiction of their primary mission, start to advocate that users install that proprietary software, because it seems to make the FaiF platform “more useful”.

  Hopefully, by now, most of us in the software freedom community agree that proprietary software is a long term trap that we want to avoid. However, in the short term, there is always some new shiny thing. Something that appeals to our prurient desire for software that “does something cool”. Something that just seems so convenient that we convince ourselves we cannot live without it, so we install it. Over time, short term becomes the long term, and suddenly we have gaping holes in the Free Software infrastructure that only the very few notice because the rest just install the proprietary thing. For example, how many of us bother to install Linux Libre, even long enough to at least know which of our hardware components needs proprietary software? Even I have to admit I don't do this, and probably should.

  An old adage of software development is that software is always better if the developers of it actually have to use the thing from day to day. If we agree that our goal is ultimately convincing everyone to run only Free Software (and for that Free Software to fit their needs), then we have to trailblaze by avoiding running proprietary software ourselves. If you do run proprietary software, I hope you won't celebrate the fact or encourage others to do so. Skype is particularly insidious here, because it's a community application. Encouraging people to call you on Skype is the same as emailing someone a Microsoft Word document: it's encouraging someone to install a proprietary application just to work with you.

  Finally, I think the only answer to the FLOSS community celebrating the arrival of some new proprietary program for GNU/Linux is to denounce it, as a counterbalance to the fervor that such an announcement causes. My podcast co-host Karen often calls me the canary in the software coalmine because I am usually the first to notice something that is bad for the advancement of software freedom before anyone else does. In playing this role, I often end up denouncing a few things here and there, although I can still count on my two hands the times I've done so. I agree that advocacy should be the norm, but the occasional denouncement is also a necessary part of the picture.

  (Note: this blog is part of an ongoing public discussion of a software program that is not too popular yet, but was heralded widely as a win for Free Software in the USA. I didn't mention it by name mainly because I don't want to give it more press than it's already gotten, as it is one of this programs that is becoming a standard GNU/Linux user application (at least in the USA), but hasn't yet risen to the level of ubiquity of the other examples I give above. Here's to hoping that it doesn't.)

  Posted on Sunday 11 October 2009 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

July

• 2009-07-29: Microsoft Releases GPL'd Software (Again): Does This Change Anything?

  Microsoft has received much undeserved press about their recent release of Linux drivers for their virtualization technology under GPLv2. I say “undeserved” because I don't particularly see why Microsoft should be lauded merely for doing something that is in their own interest that they've done before.

  Most people have forgotten that Microsoft once had a GPL-based product available for Windows NT. It was called Windows Services for UNIX, and AFAICT, remains available today (although perhaps they've transitioned in recent years to no longer include GPL'd software).

  This product was acquired by Microsoft when they purchased Softway Systems. The product was based on GCC, and included a variety of GNU system utilities ported to Windows. Microsoft was a compliant distributor of this software for years, right during the time when they were calling the GPL an unAmerican cancerous virus that eats up software like PacMan. The GPL is not a new license to Microsoft; they only pretend that it is to give bad press to the GPL or to give good press to themselves.

  Another thing that's not new to Microsoft is that they have no interesting in contributing to Free Software unless it makes their proprietary software more desirable. In my old example above, they hoped to entice developers who preferred a Unix development environment to switch to Windows NT. In the recent Linux driver release, they seek to convince developers to switch from Xen and KVM to their proprietary virtualization technology.

  In fact, the only difference in this particular release is that, unlike in the case of Softway's software, Microsoft was apparently (according to Steve Hemminger) out of compliance briefly. According to Steve, Microsoft distributed binaries linked to various GPL parts.

  Meanwhile, Sam Ramji claimed that Microsoft were already planning to release the software before Hemminger and Greg K-H contacted them. I do believe Sam when he says that there was already talk inside Microsoft about releasing the source underway before the Linux developers began their enforcement effort. However, that internal Microsoft talk doesn't mean that there wasn't a problem. As soon as one distributes the binaries of a GPL'd work, one must provide the source (or an offer therefor) alongside those binaries. Thus, if Microsoft released binaries and delayed in releasing source, there was a GPL violation.

  Like all GPL violations (and potential GPL violations), it's left to the copyright holders of the software to engage in enforcement. I think it's great that, according to Steve and related press coverage, the Linux developers used the most common enforcement strategy in the GPL community — quietly contact the company, inform them of their obligations, and help them in a friendly way into compliance. That process almost always works, and the fact that Microsoft came into compliance shows the value of our community's standard enforcement practice.

  Still, there is a more important item of note from a perspective of software freedom. This Linux driver — whether it is released properly under the GPL or kept proprietary in violation of the GPL — is designed to convince users to give up Free virtualization platforms like Xen and KVM and use Microsoft's virtualization technology instead. From that perspective, it matters little that it was released as Free Software: people should avoid the software and use platforms for virtualization that respect their freedom.

  Someday, perhaps, Microsoft will take a proper place among other large companies that actually contribute code that improves the general infrastructure of Free Software. Many companies give generally useful improvements back to Linux, GCC, and various other parts of the GNU/Linux system. Microsoft has never done this: they only contribute code when it improves Free Software interoperability with their proprietary technology. The day that Microsoft actually changes its attitude toward Free Software did not occur last week. Microsoft's old strategy stays the same: try to kill Free Software with patents, and in the meantime, convince as many Free Software users as possible to begin relying on Microsoft proprietary technology.

  Posted on Wednesday 29 July 2009 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2009-07-17: Microsoft Patent Aggression Continues Against Free Software

  I think this news item from yesterday mostly speaks for itself, but I could not let the incident go by without blogging briefly about it.

  There has been so much talk in the last two weeks that Microsoft has changed with regard to its patent policy toward Free Software. We fool ourselves if we trust any of the window-dressing that Microsoft has put forward to convince us that we can trust them in this regard. Indeed, I spoke extensively about this in my interview on the Linux Outlaws show this week.

  What we see in this agreement between the Melco Group and Microsoft is another little above-water piece of the same patent aggression iceberg that Microsoft has placed in our community's way. They continue to shake down companies that distribute GNU/Linux systems for patent royalties. As I've written about before, it's difficult to judge if these are GPLv2-compliant, but they are almost certainly not GPLv3-compliant. If there were ever a moment for the community to scramble to GPLv3, this would be it, if for no other reason to defend ourselves against the looming aggression.

  In the meantime, we'd be foolish to trust any sort of promises Microsoft has to make about their patents. Would they really make a reliable promise that would prevent their ongoing campaign of patent aggression against Free Software?

  Update: In related news, I was also glad to read FSF's new statement on the issue, which includes some of the same comments I made on Linux Outlaws Episode 102.

  Posted on Friday 17 July 2009 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

June

• 2009-06-29: Considerations on Patents that Read on Language Infrastructure

  In an essay last Friday entitled Why free software shouldn't depend on Mono or C#, RMS argued a key point that I agree with: the software freedom community should minimize its use of programming language infrastructure that comes primarily from anti-software-freedom companies, notwithstanding FaiF (Free as in Freedom) implementations. I've been thinking about an extension of that argument: that language infrastructure created in a community process is likely more resilient against attacks from proprietary software companies.

  Specifically, I am considering the risk that a patent attack will occur against the language or its canonical implementation. We know that the USPTO appears to have no bounds in constantly granting so-called “software patents”, most of which are invalid within their own system, and the rest may be like the RSA patent, and will force our community to invent around them, or (as we had to do with RSA), “wait them out”. I'd like to consider how these known facts apply to the implementation of language infrastructure in the Free Software world.

  Programming languages and their associated standard libraries and implementations evolve in three basic ways:

  • A Free Software community designs and implements the language in a grassroots fashion. Perl, PHP, and Python are a few examples.
  • A single corporate entity controls the language and its canonical implementation. They perhaps also convince some standards body to adopt it, but usually retain complete control. C# and Java a few examples.
  • A single corporate entity controlled the language initially, but more than 20 years have passed and the language now has many proprietary and Free Software implementations. C and C++ are a few examples.

  The patent issues in each of these situations deserves different consideration, primarily related to the dispersion of patents that likely read on the given language implementation. We have to assume that the USPTO has granted many patents that read on any software a person can conceivably write. The question is always: of all the things you can write, which has the most risk of patent attack from the patent holders in question?

  In the case of the community-designed and Free-Software-implemented languages, the patent risk is likely spread across many companies, and mitigated by the fact that few have probably filed patents applications designed specifically to read on the language and its implementation. Since various individuals and companies contributed to the development and design, and because it was a process run by the community, it's unlikely there was a master plan by one entity to apply specifically for patents on the language. So, while there are likely many patents that read on the implementation, a single holder is unlikely to hold all the patents, and those patents were probably not crafted for the specific language. Only some of these many patent-holding entities will have a desire to attack Free Software. It is therefore less likely that a user of the language will be sued; a patent troll would have to do some work to acquire the relevant patent. If that unlikely event does anyway occur, the fact that the patent was not specifically designed to read on the language implementation may indeed help, either by easing the process of “inventing around” or by making it more difficult for the patent troll to show the patent reads on the language implementation. Finally, if the implementation is under a license like GPL, or the Apache License (or any license with a patent grant), those companies that did contribute to the language implementation may have granted a patent license already.

  Of course, these are all relative arguments against the alternative: a language designed by a single company. If a single corporate entity designed and implemented the language more recently than 20 years ago, that company likely filed many yet-unexpired patents throughout the process of designing and implementing the language and its infrastructure. When the Free Software community implements fresh versions of the language from scratch, it's very likely that it will generate software that reads on those patents. Thus, the community must live in constant and direct fear of that company. We must assume the patents exist, and we know who holds them, and we know they filed them with this very language in mind. It may be tough to invent around them and still keep the Free Software implementation compatible. This is why I and other Free Software advocates have insisted for years the all companies who claim to support software freedom should grant GPL-compatible patent licenses for all their patents. (I still await Sam Ramji's response on my call for Microsoft to do so.)

  Without that explicit patent license, we certainly should prefer the community-driven and Free-Software-developed languages over those developed by companies (like Microsoft) that have a history of anti-Free Software practices. Regarding companies with a more ambiguous history toward Free Software, some might argue that patents consolidated in a “friendly” company is safest of all alternatives. They might argue that with all those patents consolidated, patent trolls will have a tough time acquiring patents and attacking FaiF implementations. However, while this can sometimes be temporarily true, one cannot rely on this safety. Java, for example, is in a precarious situation now. Oracle is not a friend to Free Software, and soon will hold all Sun's Java patents — a looming threat to FaiF Java implementations. While I think it's more likely that Microsoft will attack FaiF C# implementations with its patents eventually, an Oracle attack on FaiF Java is a possibility. (We should also not forget that Sun in the late 1990s was very opposed to Free Software implementations of Java; the corporate winds always change and we should not throw ourselves to them.)

  The last case in my list deserves at least a brief mention. Languages like C (which was a purely AT&T endeavor initially) have reached the age that the early patents would have now expired, and such languages have slowly moved into community and standards-driven control. Thus, over long periods of time, history shows us that companies do loosen their iron grip of proprietary control of language implementations. However, during that first 20 year period, we should face them with great trepidation and stick with languages developed by the Free Software community itself.

  Finally, I close with important advice: don't be paralyzed with fear over software patents. There are likely some USA patents that read on any software you write. Make good choices (like avoiding C#, as RMS suggests, and favoring languages like Perl, Python, PHP and C), and get on with your work. If, as a non-profit Free Software developer, someone writes you a threatening letter about patents or sues you for patent infringement, of course seek help from an attorney.

  Update:While my analysis was focused on the patent issues around languages, I couldn't resist this orthogonal topic posted by David Siegel with some very helpful suggestions to developers who wish to limit the use of C#. FLOSS is about using good software development to help solve legal, social and technological impediments to freedom. David is right on course with his suggestions.

  Posted on Monday 29 June 2009 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

May

• 2009-05-12: Support Your Friendly Neighborhood FLOSS Charities

  I don't think we talk enough in the FLOSS community about the importance of individual support of FLOSS-related charitable organizations. On a recent Software Freedom Law Show episode, Karen and I discuss with Stormy Peters how important it is for geeks — who may well often give lots of code to many FLOSS projects — also should consider giving a little bit of financial funding to FLOSS organizations as well.

  Of course, it's essential that people give their time to the charities and the causes that they care about. In the FLOSS world, we typically do that by giving code or documentation to our favorite FLOSS project. I think that's led us all into the classic “I gave at the office” feeling. Indeed, I know that I too have fallen into this rut at times myself.

  I suppose I could easily claim that, more than most people, I've given enough at the office. Working at various non-profit organizations since the 1990s, I've always made substantially less in salary than I would in the for-profit industry for similar work. I also have always volunteered my time in addition to my weekly work schedule. For example, I currently get paid for my 40 hour/week job at the SFLC, but I also donate about 20 hours of work for the Software Freedom Conservancy each week.

  Still, I don't believe that this is enough. There are many, many FLOSS non-profits that deserve support — more than I have time to give. Meanwhile, very small amounts of money, aggregated over many people giving, makes a world of difference in a number of ways to these organizations.

  Non-profits that are funded by a broad base of supporters are much more stable and have greater longevity than other types of non-profits that are funded primarily by corporate donations. This is because one donor or even a few disappearing is not disaster. Also, through these donations, organizations build a constituency of supporters that truly represent the people that the non-profit seeks to serve.

  Traditionally (with a few notable exceptions), non-profits in the FLOSS world have relied primarily on corporate donations. I generally think this is not ideal for a community that wishes to be fully represented by the non-profits that embody the projects we care about. We want these projects to represent the interest of developers and users, not necessarily the for-profit corporate interests. Plus, we want the organizations to survive even when companies stop supporting FLOSS or just simply go out of business.

  If we all contribute, it doesn't take that much for each individual to be a part of making a real difference. I believe that if each person who has benefited seriously from FLOSS gave $200/year, we'd make a substantial change and a wonderful positive impact on the non-profit organizations that shepherd and keep these FLOSS projects alive. I'm not suggesting giving to any specific organization: just to take $200/year and divide in the way you think is best across 2-4 different FLOSS non-profits that sponsor project you personally care about or benefit from.

  Think about it: $200/year breaks down to $16/month. For me (and likely for most people in a major city), $16/month means one fewer dinner at a restaurant each month. Can't we all eat at home one more time per month, and share that savings to help FLOSS non-profits?

  If you are looking for a list of non-profits that could use your support, the FLOSS Foundations Directory is a good place to start. FWIW, in addition to my volunteer work with Conservancy, here's the list of non-profits that I'm supporting with a total of $200 this year (in alphabetical order): The Free Software Foundation, GNOME Foundation, The Parrot Foundation, and The Twisted Project. Which ones will you give to this year?

  Posted on Tuesday 12 May 2009 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

April

• 2009-04-24: Fork Well: It Could Be The Last, Best Hope for Community

  I have faced with much trepidation the news of Oracle's looming purchase of Sun. Oracle has never shown any interest in community development, particularly in the database area. They are the largest proprietary database vendor on the planet, and they probably have very simple plans for MySQL: kill it.

  That's why I read with relief this post by Monty (co-founder of the MySQL project) this week, wherein Monty plans (and encourages others, too) to put their full force behind a MySQL “fork” that will be centered outside of Oracle.

  Monty is undoubtedly correct when he says I don't think that anyone can own an open source project; the projects are defined by the de-facto project leaders and the developers that are working on the project. and that [w]ith Oracle now owning MySQL, I think that the need for an independent true Open Source entity for MySQL is even bigger than ever before.

  I don't find the root of this problem in that one company has sold itself to another, pursuant to the the greater glory of the Ferengi Rules of Acquisition. Instead, I think the error is that projects inside Sun did not have a non-profit entity to shepherd them. When a single for-profit company is in control of a project's copyrights, its trademarks, and employs nearly all its core developers, there is a gross imbalance. The community around the project isn't healthy, and can easily be disrupted by the winds of corporate change, which blow in service of the only goal of for-profit existence: higher profits.

  I encourage Monty, as well as core developers of VirtualBox, OpenOffice, OpenSolaris, Sun's Java, and any other project that is currently under the full control of Sun (or indeed any other for-profit corporation) to think about this idea. Non-profits, particularly 501(c)(3)'s, are fundamentally different than for-profits. They exist to serve a community or a constituency and the public good, never profit. Therefore, the health of the codebase, the diversity of the developer and user community, and the advancement of software freedom can be the clear mission of a non-profit that houses a FLOSS project. A non-profit ensures that while corporate funding comes and goes, the mission of the project and its institutional embodiment stay stable. For example, just like shareholders have a duty to fire a CEO when he fails to make enough profit (i.e., the for-profit company is not reaching its maximal goal), boards of directors and/or memberships of non-profits must fire the President and/or Executive Director when they fail to serve the community well. Instead of the “profit motive”, 501(c)(3)'s have the “community motive”.

  Yet, the challenge of focusing on such goals remains difficult for projects that did not spawn from a community to start. GNU and Linux were both started by individual developers that built strong communities before there was any for-profit corporate interest in the software. When a project started inside a company with profit in mind, shoehorning community principles into the project can rarely succeed. I believe that a community must usually evolve from the ashes of some incident that wakes everyone up to realize the project will come to harm due to strict adherence to the profit motive.

  I should probably remind everyone that I'm not opposed to capitalism per se. Indeed, I've often fought on the other side of this equation when licenses (such as MySQL's own very early pre-GPL license) permit noncommercial use but prohibit commercial use. I believe that commercial and non-commercial activity with the code should be equally permitted in a non-discriminatory way. However, the center of gravity for developers, where the copyrights and trademarks live, and how core work on the codebase is funded are all orthogonal questions to the question of the software's license.

  My experience has anecdotally taught me that FLOSS communities function best when the following two things are true: (a) the codebase is held neutrally, either in the hands of the individual developers who wrote the code, or in a 501(c)(3) non-profit, and (b) not too many core developers share the same employer. I believe that reaching that state should be Job One of any for-profit seeking to build a FLOSS community. Sadly, this type of community health is often at direct odds with the traditional capitalist thinking of for-profit shareholders. I'm thus not surprised when FLOSS community managers in for-profit companies can only do so much. The rest is really up to the community of developers to fork and demand that a non-profit or other neutral and diverse developer-controlled management team exist. Attempts at this, sadly, fail much more often than they succeed.

  Monty's post likely had more hope in it than this one. Monty didn't jump to my conclusion that Oracle will kill MySQL; Monty considers it also possible that Oracle might sell MySQL or (and here's the possibility I really doubt) that Oracle will change into a community-driven FLOSS company. I love Monty's optimism in even considering this possible. I honestly hope my pragmatism about this is shown to be sheer pessimism. In the meantime, focusing on the MySQL forks and pressuring Oracle to engage the FLOSS community in a genuine way is the best strategy no matter what outcome you think is most likely.

  Update (on 17 May 2009): Monty announced an industry consortium that will seek to be a neutral space for MySQL development. I tend to prefer charitable non-profits to trade associations, but better the latter than hoping for Oracle to do the right thing.

  Posted on Friday 24 April 2009 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

• 2009-04-16: TomTom/Microsoft: A Wake-Up Call for GPLv3 Migration

  There has been a lot of press coverage about the Microsoft/TomTom settlement. Unfortunately, so far, I have seen no one speak directly about the dangers that this deal could pose to software freedom, and what our community should consider in its wake. Karen and I discussed some of these details on our podcast, but I thought it would be useful to have a blog post about this issue as well.

  Most settlement agreements are sealed. This means that we won't ever actually know what TomTom agreed to and whether or not it violates GPLv2. The violation, if one exists, would likely be of GPLv2's § 7. The problem has always been that it's difficult to actually witness a v2§7 violation occurring (due in large part to less than perfect wording of that section). To find a violation v2§7, you have to discover that there were conditions imposed on [TomTom] ... that contradict the conditions of [GPLv2]. So, we won't actually know if this agreement violates GPLv2 unless we read the agreement itself, or if we observe some behavior by Microsoft or TomTom that shows that the agreement must be in violation.

  To clarify the last statement, consider the hypothetical options. For TomTom to have agreed to something GPLv2-compliant with Microsoft, the agreement would have needed to either (a) not grant a patent license at all (perhaps, for example, Microsoft conceded in the sealed agreement that the patents aren't actually enforceable on the GPLv2'd components), or (b) give a patent license that was royalty-free and permitted all GPLv2-protected activities by all recipients of patent-practicing GPLv2'd code from TomTom, or downstream from TomTom.

  It's certainly possible Microsoft either capitulated regarding the unenforceability (or irrelevancy) of its patents on the GPLv2'd software in question, or granted some sort of license. We won't know directly without seeing the agreement, or by observing a later action by Microsoft. If, for example, Microsoft later is observed enforcing the FAT patent against a Linux distributor, one might successfully argue that the user must have the right to practice those Microsoft patents in the GPLv2 code, because otherwise, how was TomTom able to distribute under GPLv2? (Note, BTW, that any redistributor of Linux could make themselves downstream from TomTom, since TomTom distributes source on their website.) If no such permission existed, TomTom would then be caught in a violation — at least in my (perhaps minority) reading of GPLv2.⁰

  Many have argued that GPLv2 § 7 isn't worded well enough to verify this line of thinking. I and a few other key GPL thinkers disagree, mainly because this reading is clearly the intent of GPLv2 when you read the Preamble. But, there are multiple interpretations of GPLv2's wording on this issue, and, the wording was written before the drafters really knew exactly how patents would be used to hurt Free Software. We'll thus probably never really have complete certainty that such patent deals violate GPLv2.

  This TomTom/Microsoft deal (and indeed, probably dozens of others like it whose existence is not public, because lawsuits aren't involved) almost surely plays into this interpretation ambiguity. Microsoft likely convinced TomTom that the deal is GPLv2-compliant, and that's why there are so many statements in the press opining about its likely GPLv2 compliance. I, Jeremy Allison, and others might be in the minority in our belief of the strength of GPLv2 § 7, but no one can disagree with the intent of the section, as stated in the Preamble. Microsoft is manipulating the interpretation disagreements to convince smaller companies like Novell, TomTom, and probably others into believing that these complicated patent licensing deals and/or covenants are GPLv2-compliant. Since most of them are about the kernel named Linux, and the Linux copyright holders are the only ones with power to enforce, Microsoft is winning on this front.

  Fortunately, the GPLv3 clarifies this issue, and improves the situation. Therefore, this is a great moment in our community to reflect on the importance of GPLv3 migration. The drafters of GPLv3, responding to the Microsoft/Novell deal, considered carefully how to address these sorts of agreements. Specifically, we have these two paragraphs in GPLv3:

  If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.

  A patent license is “discriminatory” if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.

  Were Linux under GPLv3 (but not GPLv2), these terms, particularly those in the second paragraph, would clearly and unequivocally prohibit TomTom from entering into any arrangement with Microsoft that doesn't grant a license to any Microsoft patent that reads on Linux. Indeed, even what has been publicly said about this agreement seems to indicate strongly that this deal would violate GPLv3. While the Novell/Microsoft deal was grandfathered in (via the date above), this new agreement is not. Yet, the most frustrating aspect of the press coverage of this deal is that few have taken the opportunity to advocate for GPLv3 adoption by more projects. I hope now that we're a few weeks out from the coverage, project leaders will begin again to consider adding this additional patent protection for their users and redistributors.

  Toward the goal of convincing GPLv2 users to switch to GPLv3, I should explain a bit why special patent licensing deals like this are bad for software freedom; it's not completely obvious. To do so, we can look specifically at what TomTom and Microsoft said in the press coverage of their deal: The agreement protects TomTom's customers under the patents …, the companies said (Microsoft, TomTom Settle Patent Dispute, Ina Fried).

  Thus, according to Microsoft and TomTom, the agreement gives some sort of “patent protection” to TomTom customers, and presumably no one else. This means that if someone buys a GNU/Linux-based TomTom product, they have greater protection from Microsoft's patents than if they don't. It creates two unequal classes of users: those who pay TomTom and those who don't. The ones who don't pay TomTom will have to worry if they will be the next ones sued or attacked in some other way by Microsoft over patent infringement.

  Creating haves and have-nots in the software licensing space is precisely what all versions of the GPL seek to prevent. This is why the Preamble of GPLv2 said: any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary.

  Further to this point, in the Rationale Document for the Third Discussion Draft of GPLv3, a similar argument is given in more detail:

  The basic harm that such an agreement can do is to make the free software subject to it effectively proprietary. This result occurs to the extent that users feel compelled, by the threat of the patent, to get their copies in this way. So far, the Microsoft/Novell deal does not seem to have had this result, or at least not very much: users do not seem to be choosing Novell for this reason. But we cannot take for granted that such threats will always fail to harm the community. We take the threat seriously, and we have decided to act to block such threats, and to reduce their potential to do harm. Such deals also offer patent holders a crack through which to split the community. Offering commercial users the chance to buy limited promises of patent safety in effect invites each of them to make a separate peace with patent aggressors, and abandon the rest of our community to its fate.

  It's true that one can blissfully use, redistribute, sell and modify some patent-covered software for years without ever facing a patent enforcement action. But, particularly in situations where known patents have been asserted, those without a patent license often live in fear of copying, modifying and sharing code that exercises the teachings of the patent. We saw this throughout the 1990s with RSA, and today most commonly with audio and video codecs. Microsoft and other anti-Free Software companies have enough patents to attack if we let them. The first steps in stopping it are to (a) adopt GPLv3, LGPLv3 and AGPLv3 with the improved patent provisions, and (b) condemning GPLv2-only deals that solve a patent problem for some users but leave the rest out in the cold, and (c) pointing out that the purported certainty that such deals are GPLv2-compliant is definitely in question.

  Patents always remain a serious threat, and, while the protection under GPLv2 has probably been underestimated, we cannot overestimate the additional protection that GPLv3 gives us in this regard. Microsoft clearly knows that the GPLv3 terms will kill their patent aggression business model, and have therefore focused their attacks on GPLv2-licensed code. Shouldn't we start to flank them by making less GPLv2 code available for these sorts of deals?

  Finally, I would like to draw specific attention the fact that TomTom, as a company, is not necessarily an ally of software freedom. They are like most for-profit companies; they use FLOSS when it is convenient for them, and give back when the licenses obligate them to do so, or when it behooves them in some way. As a for-profit company, they made this deal to please their shareholders, not the Free Software community. Admittedly, their use of the FLOSS in their products was done legitimately (that is, once their GPLv2 non-compliance was corrected by Harald Welte in 2004). However, I do not think we should look upon TomTom as a particularly helpful member of the community. Indeed, most of the patents that Microsoft asserted against TomTom were on their proprietary components, not their FLOSS ones. Thus, most of this dispute was a proprietary software company arguing with another proprietary software company over patents that read on proprietary software. Our community should tell TomTom that if they want to join and support the FLOSS world, they should release their software under a FLOSS license — including software that they aren't obligated to do so by the licenses. Wouldn't it be quite interesting if TomTom's mapping display software were available under, say, GPLv3?

  (Added later): Even if TomTom fails to release their mapping applications as Free Software, our minimal demand should be a license to their patents for use in Free Software. Recall that TomTom countersued Microsoft, also alleging patent infringement on TomTom's patents. TomTom has still yet to offer a public license on those patents for use by the Free Software community. If they are actually not hostile to software freedom, wouldn't they allow us to at least practice the teachings of their patents in GPL'd software?

  ---

  ⁰Update: Andrew Tridgell pointed out that my verb tenses in my hypothetical example made the text sound more broadly worded than I intended. I've thus corrected the text in the hypothetical example to be clearer. Thanks for the clarification, Tridge!

  Posted on Thursday 16 April 2009 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

• 2009-04-08: Neary on Copyright Assignment: Some Thoughts

  Dave Neary found me during breakfast at the Linux Collaboration Summit this morning and mentioned that he was being flamed for a blog post he made, Copyright assignment and other barriers to entry. Or, as some might title it in a Computer Science academic tradition: Copyright Assignment Considered Harmful. I took a look at Dave's post, and I definitely think it's worth reading and considering, regardless of whether you agree with it or flame it. For my part, I think I agree with most of his points.

  One of the distinctions that Dave is making that some might miss is the difference between non-profit, community-controlled copyright assignment assignees and for-profit copyright assignees. He quotes Luis Villa to make the point that companies, ultimately, aren't the best destinations as a final home of FLOSS copyrights. If copyright assignment is looked only through the lens of a for-profit corporate entity — with only the duty to its shareholders to determine its future — then indeed it's a dangerous situation for many of the reasons that Dave raises.

  I believe strongly that assigning copyright to a for-profit corporate entity is usually problematic. As Dave points out, corporations aren't really community members proper of a Free Software community; rather, their employees typically are. I have always felt that either copyrights should be assigned to a transparently-run non-profit 501(c)(3) entity, or they should be held by individual contributors. Indeed, the Samba project even has a policy to accept absolutely no corporate copyrights in their codebase, and I would love to see more projects adopt that policy.

  I trust 501(c)(3) non-profits more than for-profits not only because I've spent most of my career in the former, and have enjoyed that time more than my time at the latter. I trust non-profits more because their charters and founding documents require a duty to a public-benefiting mission and to a community. They are failing to act properly under their charters if they put the needs of a for-profit entity ahead of the needs of the community and the public. This is exactly the correct alignment of incentives for a consolidation of FLOSS copyrights.

  Some projects don't like centralized copyright for various reasons. While I do prefer it myself, I can understand this desire among individuals to each keep their stake of control in the project. Thus, I don't object to projects that want each individual contributor to have their own copyright. In this situation, the incentives are still properly aligned, because individuals who helped make the project happen have the legal control. While these individuals have no required commitment to the public good like a non-profit, they are members of a community and are much more likely to put the community needs above the profit motive that controls all for-profit entities.

  When Dave says copyright assignment might be harmful, he seems to talk primarily about for-profit corporate assignment. I agree with him on that point. however, when he mentions that it's unnecessary, I don't completely agree, but he raises well the points that I would raise as to why it's important.

  However, in the middle of Dave's post is the bigger concern that deserves special mention. The important task is keeping a clear record of the copyright provenance about where the work came from, and who might have a copyright claim. Copyright assignment is a short-hand way to do this in an organized and clear fashion. It's a simple solution with some overhead, and sometimes projects over the years have been annoyed with (and even ridiculed) that overhead. However, the more complex solutions have overhead, too. If you don't do assignment, you must keep careful track of every contributor, what their employer agreements say, and whether they have the right to submit patches under their own copyrights to the project. Some projects do this better than others.

  Regardless, all of this is hard work. For years, I've seen it as a personal task of mine to help develop systems and recommendations that help make either process (assignment or good copyright record-keeping) less burdensome. I haven't worked on this task as much as I should have, but I have not forgotten that it needs attention. I envision integrated hooks and systems with revision control systems that help with this. I think we eventually need something that makes it trivial for hackers to implement and easy to maintain. I understand that the last thing any Free Software hacker wants to do is sit and contemplate the legal implications of contributions they've received. As such, all of us who follow this issue hope to make it easier for projects to do the work. In the meantime, I think discussion about this is good, and I'm thankful for Dave to raising the issue again.

  Posted on Wednesday 08 April 2009 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

March

• 2009-03-17: Scale 7x Keynote Redux

  Many people have been commenting on and/or asking about my keynote, When Software Is A Services, Is Only the “Network Luddite” Free? from Scale 7x in late February. There is finally a downloadable H264/MPEG-4 AAC version (114MB) available. There is also an audio recording of the same speech available from SCALE's website. Finally, please note that the keynote is substantially similar to my Plone Conference Keynote, which we released as a podcast.

  I'm working with the SCALE 7x organizers to see if I can get the video and audio of the keynote in a freer format. However, since the mp4 file linked above does play in vlc, I figured it's worth getting it out to folks who are looking for it now.

  There was also an article in Ars Technica that covered my keynote.

  Posted on Tuesday 17 March 2009 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

January

• 2009-01-27: Welcome (Finally!) to the GCC Runtime Library Exception

  For the past sixteen months, I participated in a bit of a “mini-GPLv3 process” among folks at the FSF, SFLC, the GNU Compiler Collection Steering Committee (GCC SC), and the GCC community at large. We've been drafting an important GPLv3 license exception (based on a concept by David Edelsohn and Eben Moglen, that they invented even before the GPLv3 process itself started). Today, that GCC Runtime Library Exception for GPLv3 went into production.

  I keep incessant track of my hours spent on various projects, so I have hard numbers that show I personally spent 188 hours — a full month of 40-hour weeks — on this project. I'm sure my colleagues have spent similar amounts, too. I am proud of this time, and I think it was absolutely worthwhile. I hope the discussion gives you a flavor of why FLOSS license exception drafting is both incredibly important and difficult to get right without the greatest of care and attention to detail.

  Why GPL Exceptions Exist

  Before I jump into discussion of this GCC Runtime Library exception, some background is needed. Exceptions have been a mainstay of copyleft licensing since the inception of the GNU project, and once you've seen many examples over many years, they become a standard part of FLOSS licensing. However, for the casual FLOSS developer who doesn't wish to be a licensing wonk (down this path lies madness, my friends, run screaming with your head covered!), exceptions are a rare discovery in a random source file or two, and they do not command great attention. An understandable reaction, but from a policy perspective, they are an essential part of the copyleft system.

  From the earliest days of the copyleft, it was understood that copyleft was a merely a strategy to reach the goal of software freedom. The GPL is a tool that implements this strategy, but like any tool, it doesn't fit every job.

  In some sense, the LGPL was the earliest and certainly the most widely known “GPL exception”. (Indeed, my friend Richard Fontana came up with the idea to literally make LGPL an exception to GPLv3, although in the v2 world, LGPLv2 was a fully separate license from GPLv2.) Discussions on why the LGPL exists are beyond the scope of this blog post (although I've written about them before). Generally speaking, though, LGPL is designed to be a tool when you don't want the full force of copyleft for all derivative works. Namely, you want to permit the creation of some proprietary (or partly proprietary) derivative works because allowing those derivations makes strategic sense in pursuing the goal of software freedom.

  Aside from the LGPL, the most common GPL exceptions are usually what we generally categorize as “linking exceptions”. They allow the modifier to take some GPL'd object code and combine it in some way with some proprietary code during the compilation process. The simplest of these exceptions is found when you, for example, write a GPL'd program in a language with only a proprietary implementation, (e.g., VisualBasic) and you want to allow the code to combine with the VisualBasic runtime libraries. You use your exclusive right as copyright holder on the new program to grant downstream users, redistributors and modifiers the right combine with those proprietary libraries without having those libraries subject to copyleft.

  In essence, copyleft exceptions are the scalpels of copyleft. They allow you to create very carefully constructed carve-outs of permission when pure copyleft is too blunt an instrument to advance the goal of software freedom. Many software freedom policy questions require this fine cutting work to reach the right outcome.

  The GCC Exception

  The GCC Exception (well, exceptions, really) have always been a particularly interesting and complex use of a copyleft exception. Initially, they were pragmatically needed to handle a technological reality about compilers that interacts in a strange way with copyright derivative works doctrine. Specifically, when you compile a program with gcc, parts of GCC itself, called the runtime library (and before that, crt0), are combined directly with your program in the output binary. The binary, therefore, is both a derivative work of your source code and a derivative work of the runtime library. If GCC were pure GPL, every binary compiled with GCC would need to be licensed under the terms of GPL.

  Of course, when RMS was writing the first GCC, he realized immediately this licensing implication and created an exception to avoid this. Versions of that exception has been around and improved since the late 1980s. The task that our team faced in late 2007 was to update that exception, both to adapt it to the excellent new GPLv3 exceptions infrastructure (as Fontana did for LGPLv3), and to handle a new policy question that has been kicking around the GCC world since 2002.

  The Plugin Concern

  For years, compiler experimentalists and researchers have been frustrated by GCC. It's very difficult to add a new optimization to GCC because you need quite a deep understanding of the codebase to implement one. Indeed I tried myself, as a graduate student in programming languages in the mid-1990s, to learn enough about GCC to do this, but gave up when a few days of study got me nowhere. Advancement of compiler technology can only happen when optimization experimentation can happen easily.

  To make it easy to try new optimizations out, GCC needs a plugin architecture. However, the GCC community has resisted this because of the software freedom implications of such an architecture: if plugins are easy to write, then it will be easy to write out to disk a version of GCC's internal program representation (sometimes called the intermediate representation, or IR). Then, proprietary programs could be used to analyze and optimize this IR, and a plugin could be used to read the file back into GCC.

  From a licensing perspective, such an optimizing proprietary program will usually not be a derivative work of GCC; it merely reads and writes some file format. It's analogous to OpenOffice reading and writing Microsoft Word files, which doesn't make it a derivative of Word by any means! The only parts that are covered by GPL are the actual plugins to GCC to read and write the format, just as OpenOffice's Word reader and writer are Free Software, but Microsoft Word is not.

  This licensing implication is a disaster for the GCC community. It would mean the advent of “compilation processes” that were “mixed”, FaiF and proprietary. The best, most difficult and most interesting parts of that compilation process — the optimizations — could be fully proprietary!

  This outcome is unacceptable from a software freedom policy perspective, but difficult to handle in licensing. Eben Moglen, David Edelsohn, and a few others, however, came up with an innovative idea: since all binaries are derivative of GCC anyway, set up the exception so that proprietary binary output from GCC is permitted only when the entire compilation process involves Free Software. In other words, you can do these proprietary optimization plugins all you want, but if you do, you'll not be able to compile anything but GPL'd software with them!

  The Drafting and the Outcome

  As every developer knows, the path from “innovative idea” to “working implementation” is a long road. It's just as true with licensing policy as it is with code. Those 188 hours that I've spent, along with even more hours spent by a cast of dozens, have been spent making a license exception that implements that idea accurately without messing up the GCC community or its licensing structure.

  With jubilation today, I link to SFLC's announcement, the announcement from the FSF, the FAQ and Rationale for the exception and the final text of the exception itself. This sixteen-month long cooperation between the FSF, the SFLC, the GCC SC, and the GCC community has produced some fine licensing policy that will serve our community well for years to come. I am honored to have been a part of it, and a bit relieved that it is complete.

  Posted on Tuesday 27 January 2009 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

• 2009-01-15: Launchpad's License Will Be AGPLv3

  Last week, I asked Karl Fogel, Canonical's newly hired Launchpad Ombudsman, if Launchpad will use the AGPLv3. His eyes said “yes” but his words were something like: Canonical hasn't announced the license choice yet. I was excited to learn this morning from him that Launchpad's license will be AGPLv3.

  This is exciting news. Launchpad is precisely the type of application that we designed the AGPLv3 for, and Launchpad is rapidly becoming a standard in the next generation of Free Software project hosting. Over the last year, I've felt much trepidation that Launchpad would be “another SourceForge”: that great irony of a proprietary platform becoming the canonical method for Free Software project hosting. It seems now the canonical and the Canonical method for hosting will be Launchpad, and it will respect the freedom of network users of the service.

  Given that they'd already announced plans to liberate Launchpad, it's not really surprising that Canonical has selected the AGPLv3. I would guess their primary worry about releasing the source was ensuring that competitors don't sprout up and fail to share their improvements back with the community of users. AGPLv3 is specifically designed for this situation.

  I'm glad we've made a license that is getting adoption by top-tier Free Software projects like this one. Critics keep saying that AGPLv3 is a marginal license of limited interest. I hope this license choice by Canonical will show them again that they continue to be mistaken.

  Thanks to Karl, Matthew Revell, Mark Shuttleworth himself, and all the others at Canonical who are helping make this happen.

  Posted on Thursday 15 January 2009 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2009-01-14: LGPL'ing of Qt Will Encourage More Software Freedom

  The decision between the GPL or LGPL for a library is a complex one, particularly when that library solves a new problem or an old problem in a new way. TrollTech faced this decision for the Qt library, and Nokia (who acquired Trolltech last year) has now reconsidered the question and come to a different conclusion. Having followed this situation since even before Qt was GPL'd, I was glad that we have successfully encouraged the reconsideration of this decision.

  Years ago, RMS wrote what many consider the definitive essay on this subject, entitled Why you shouldn't use the Lesser GPL for your next library. A few times a year, I find myself rereading that essay because I believe it puts forward some good points to think about when making this decision.

  Nevertheless, there is a strong case for the LGPL in many situations. Sometimes, pure copyleft negatively impacts the goal of maximal software freedom. The canonical example, of course, is the GNU C Library (which was probably the first program ever LGPL'd).

  Glibc was LGPL'd, in part, because it was unlikely at the time that anyone would adopt a fully FaiF (Free as in Freedom) operating system that didn't allow any proprietary applications. Almost every program on a Unix-like system combines with the C library, and if it were GPL'd, all applications would be covered by the GPL. Users of the system would have freedom, but encouraging the switch would be painful because they'd have to give up all proprietary software all at once.

  The GNU authors knew that there would be proprietary software for quite some time, as our community slowly replaced each application with freedom-respecting implementations. In the meantime, better that proprietary software users have a FaiF C library and a FaiF operating system to use (even with proprietary applications) while work continued.

  We now face a similar situation in the mobile device space. Most mobile devices used today are locked down, top to bottom. It makes sense to implement the approach we know works from our two decades of experience — liberate the operating system first and the applications will slowly follow.

  This argument informs the decision about Qt's licensing. Qt and its derivatives are widely used as graphics toolkits in mobile devices. Until now, Qt was licensed under GPL (and before that various semi-Free licenses). Not only did the GPL create a “best is the enemy of the good” situation, but those companies that rejected the GPL could simply license a proprietary copy from TrollTech, which further ghettoized the GPL'd versions. All that is now changing.

  Beyond encouraging FaiF mobile operating systems, this change to LGPL yields an important side benefit. While the proprietary relicensing business is a common and legitimate business model to fund further development, it also has some negative social side effects. The codebase often lives in a silo, discouraging contributions from those who don't receive funding from the company who controls the canonical upstream.

  A change to LGPL sends a loud and clear message — the proprietary relicensing business for Qt is over. Developers who have previously rejected Qt because it was not community-developed might want to reconsider that position in light of this news. We don't know yet how the new Qt community will be structured, but it's now clear that Nokia, Qt's new copyright holder, no longer has a vested interest in proprietary relicensing. The opportunity for a true software freedom community around Qt's code base has maximum potential at this moment. A GUI programmer I am not; but I hope those who are will take a look and see how to create the software freedom development community that Qt needs.

  Posted on Wednesday 14 January 2009 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

2008

December

• 2008-12-24: It's a Wonderful FLOSS!

  I suppose it's time for me to confess. For a regular humbug who was actually memory-leak-hunting libxml2 at the office until 21:30 on December 24th, I'm still quite a sucker for Frank Capra movies. Most people haven't seen any of them except It's a Wonderful Life. Like a lot of people, I see that film annually one way or the other, too.

  Fifteen years ago, I wrote a college paper on Capra's vision and worldview; it's not surprising someone who has devoted his life to Free Software might find resonance in it. Capra's core theme is simple (some even call it simplistic): An honest, hard-working idealist will always overcome if he never loses sight of community and simply refuses any temptation of corruption.

  I don't miss the opportunity to watch It's a Wonderful Life when it inevitably airs each year. (Meet John Doe sometimes can be found as well around this time of year — catch that one too if you can.) I usually perceive something new in each viewing.

  (There are It's a Wonderful Life spoilers below here; if you actually haven't seen it, stop here.)

  This year, what jumped out at me was the second of the three key speeches that George Bailey gives in the film. This occurs during the bank run, when Building and Loan investors are going to give up on the organization and sell their shares immediately at half their worth. I quote the speech in its entirety:

  You're thinking of this place all wrong. As if I had the money back in a safe. The money's not here. Your money's in Joe's house; that's right next to yours. And in the Kennedy house, and Mrs. Macklin's house, and a hundred others. Why, you're lending them the money to build, and then, they're going to pay it back to you as best they can. Now what are you going to do? Foreclose on them?

  [Shareholders decide to go to Potter and sell. Bailey stops the mob.]

  Now wait; now listen. Now listen to me. I beg of you not to do this thing. If Potter gets hold of this Building and Loan there'll never be another decent house built in this town. He's already got charge of the bank. He's got the bus line. He got the department stores. And now he's after us. Why?

  Well, it's very simple. Because we're cutting in on his business, that's why, and because he wants to keep you living in his slums and paying the kind of rent he decides. Joe, you had one of those Potter houses, didn't you? Well, have you forgotten? Have you forgotten what he charged you for that broken-down shack?

  Ed, you know! You remember last year when things weren't going so well, and you couldn't make your payments? You didn't lose your house, did you? Do you think Potter would have let you keep it?

  Can't you understand what's happening here? Don't you see what's happening? Potter isn't selling. Potter's buying! And why? Because we're panicking and he's not. That's why. He's picking up some bargains. Now, we can get through this thing all right. We've got to stick together, though. We've got to have faith in each other.

  Perhaps this quote jumped out on me because all the bank run jokes made this year. However, that wasn't the first thing that came to mind. Instead, I thought immediately of Microsoft's presence at OSCON this year and the launch of their campaign to pretend they haven't spent the last ten years trying destroy all of Free Software and Open Source.

  In the film, Potter eventually convinces George to come by his office for a meeting, offers him some fine cigars, and tells him that George's ship has come in because Potter is ready to give him a high paying job. George worries that the Building and Loan will fail if he takes the job. Potter's (non)response is: Confounded, man, are you afraid of success!?

  It's going to get more tempting to make deals with Microsoft. We're going to feel like their sudden (seemingly) positive interest in us — like Potter's sudden interest in George — is something to make us proud. It is, actually, but not for the obvious reason. We're finally a viable threat to the future of proprietary software. They've reached the stage where they know they can't kill us. They are going to try to buy us, try to corrupt us, try to do anything they can to convince us to give up our principles just to make our software a little better or a little more successful. But we can do those things anyway, on our own, in the fullness of time.

  Never forget why they are making the offer. Microsoft is unique among proprietary software companies: they are the only ones who have actively tried to kill Open Source and Free Software. It's not often someone wants to be your friend after trying to kill you for ten years, but such change is cause for suspicion. George was smart enough to see this and storm out of Potter's office, saying: You sit around here and spin your little webs and think the whole world revolves around you and your money! Well, it doesn't, Mr. Potter!. To Microsoft, I'd say: and that goes for you, too!

  Posted on Wednesday 24 December 2008 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

• 2008-12-09: One gpg --gen-key per Decade

  Today is an interesting anniversary (of sorts) for my cryptographic infrastructure. Nine years ago today, I generated the 1024 bit DSA key, DB41B387, that has been my GPG key every day since then. I remember distinctly that on the 350 MhZ machine I used at the time, it took quite a while to generate, even though I made sure the entropy pool remained nice and full by pounding on the keyboard.

  The horribleness of the recent Debian vulnerability meant that I have spent a much time this year pondering the pedigree my personal cryptographic infrastructure. Of course, my key was far too old to have been generated on a Debian-based system that had that particular vulnerability. However, the issue that really troubled me this past summer was this:

  Some DSA keys may be compromised by only their use. A strong key (i.e., generated with a ‘good’ OpenSSL) but used locally on a machine with a ‘bad’ OpenSSL must be considered to be compromised. This is due to an ‘attack’ on DSA that allows the secret key to be found if the nonce used in the signature is reused or known.

  Not being particularly hard core on cryptographic knowledge — most of my expertise comes from only one class I took 11 years ago on Encryption, Compression, and Secure Hashing in graduate school — I found this alarming and tried my best to do some ancillary reading. It seems that DSA keys, in many ways, are less than optimal. It seems (to my mostly uneducated eye) in skimming academic papers that DSA keys are tougher to deploy right and keep secure, which leads to these sorts of possible problems.

  I've resolved to switch entirely to RSA keys. The great thing about RSA is its simplicity and ease of understanding. I grok factoring and understand better the complexity situation of the factoring problem (this time, from the two graduate courses I took on Complexity Theory, so my comfort is more solid :). I also find it intriguing that a child can learn how to factor in grade school, yet we can't teach a computer to do it efficiently. (By contrast, I didn't learn the discrete logarithm problem until my Freshman year of college, and I still have to look up the details to remind myself.) So, the “simplicity brings clarity” idea hints that RSA is a better choice.

  Fact is, there was only one reason why I revoked my ancient RSA keys and generated DSA ones in the 1990s. The RSA patent and the strict licensing of that patent by RSA Data Security, Inc. made it impossible to implement RSA in Free Software back then. So, when I switched from proprietary PGP to GPG, my keys wouldn't import. Indeed, that one RSA patent alone set back the entire area of Free Software cryptography at least ten years.

  So, when I decided this evening that I'd need to generate a new key and begin promulgating it at key-signing parties sometime before DB41B387 turns ten, I realized I actually have the freedom to choose my encryption algorithm now! Sadly, it took almost these entire nine years to get there. Our community did not only have to wait out this unassailable patent. (RSA is among the most novel and non-obvious ideas that most computer professionals will ever seen in their lives). Once the RSA patent finally expired⁰, we had to then slowly but surely implement and deploy it in cryptographic programs, from scratch.

  I'm still glad that we're free of the RSA patent, but I fear among the mountain of “software patents” granted each year, that the “new RSA” — a perfectly valid, non-obvious and novel patent that reads on software and fits both the industry's and patent examiner's definition of “high quality” — is waiting to be discovered and used as a weapon to halt Free Software again. When I finally type gpg --gen-key (now with --expert mode!) for the first time in nine years, I hope I'll only experience the gladness of being able to generate an RSA key, and succeed in ignoring the fact that RMS' old essay about this issue remains a cautionary tale to this very day. Software patents are a serious long-term threat and must be eradicated entirely for the sake of software freedom. The biggest threat among them will always be the “valid”, “high quality” software patents, not the invalid, poor quality ones.

  ---

  ⁰ Technically speaking, RSA didn't need to expire. In a seemingly bizarre move, RSA Data Security, Inc. granted a Free license to the patent a few weeks before the actual expiration date. To this day, I believe the same theory I espoused at the time: their primary goal in doing this was merely to ruin all the “RSA is Free” parties that had been planned.

  Posted on Tuesday 09 December 2008 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

• 2008-12-04: The FLOSS License Drafter's Responsibility to the Community

  I finally set aside some time to read my old boss' open letter responding to criticisms of the FDL process. I read gladly his discussion of the responsibilities of software freedom license stewardship.

  I've been involved with the drafting of a number of FLOSS licenses (and exceptions to existing licenses). For example, I helped RMS a little with the initial FDL 1.0 drafting (the license at issue here); I was a catalyst for the creation of Artistic 2.0 and advised that process; and, I was heavily involved with the creation of the AGPL, and somewhat with the GPLv3. From these experiences, I know that, just like when a core developer gets annoyed when kibitzed by a user who just downloaded the program and is missing something obvious, we license drafters are human and often have the “did this person even read all the stuff we've written on this issue?” knee-jerk response to criticism. However, we all try to put that aside, and be ready to respond and take seriously any reasonable criticism. I am glad that RMS has done so here. The entity that controls future versions of a license for which authors often use an “or later” term holds great power. As the clichéd Spiderman saying goes, with great power, comes great responsibility.

  The FSF as a whole, and RMS in particular, have always know this well and take it very seriously. Indeed, years ago, when I was still at FSF, RMS and I wrote an essay together on a closely related issue. This recent response on FDL reiterates some of those points, but with a real-world example explaining the decision making process regarding the reasonable exercise of that power to, in turn, grant rights and freedoms rather than take them away.

  The key quote from his letter that stands out to me is: our commitment is that our changes to a license will stick to the spirit of that license, and will uphold the purposes for which we wrote it. This point is fundamental. As FLOSS license drafters, we must always, as RMS says, abide by the highest ethical standards to uphold the spirit that spurred the creation of these licenses.

  Far from being annoyed, I'm grateful for those who assume the worst of intentions and demand that we justify ourselves. For my part, I try to answer every question I get at conferences and in email about licensing policy as best I can with this point in mind. We in the non-profit licensing sector of the FLOSS world have a duty to the community of FLOSS users and programmers to defend their software freedom. I try to make every decision, on licensing policy (or, indeed, any issue) with that goal in mind. I know that my colleagues at the FSF and at the many other not-for-profit organizations always do the same, too.

  Posted on Thursday 04 December 2008 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

• 2008-12-01: AGPL Declared DFSG-Free

  Crossposted with autonomo.us.

  Late last week, the FTP Masters of Debian — who, absent a vote of the Debian developers, make all licensing decisions — posted their ruling that AGPLv3 is DFSG-Free. I was glad to see this issue was finally resolved after months of confusion; the AGPLv3 is now approved by all known FLOSS licensing ruling bodies (FSF, OSI, and Debian).

  It was somewhat fitting that the AGPLv3 was approved by Debian within a week of the one year anniversary of AGPLv3's release. This year of AGPLv3 has shown very rapid adoption of the AGPL. Even conservative numbers show an adoption rate of 15 projects per month. I expect the numbers to continue a steady, linear climb as developers begin to realize that the AGPL is the “copyleft of the Cloud”.

  Posted on Monday 01 December 2008 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

November

• 2008-11-20: podjango: A Minimalist Django Application for Podcast Publishing

  I had yet to mention in my blog that I now co-host a podcast at SFLC. I found myself, as we launched the podcast last week, in a classic hacker situation of having one project demand the need to write code for a tangentially related project.

  Specifically, we needed a way to easily publish show notes and otherwise make available the podcast on the website and in RSS feeds. Fortunately, we already had a few applications we'd written using Django. I looked briefly at django podcast, but the interface was a bit complicated, and I didn't like its (over)use of templates to do most of the RSS feeding.

  The small blogging application we'd hacked up for this blog was so close to what we needed, that I simply decided to fork it and make it into a small podcast publisher. It worked out well, and I've now launched a Free Software project called podjango under the AGPLv3.

  Most of the existing code will be quite obvious to any Django hacker. The only interesting thing to note is that I made some serious effort for the RSS feeds. First, I heavily fleshed out the minimal example for an iTunesFeed generator in the Django documentation. It's currently a bit specific to this podcast, but should be easily abstracted. I did a good amount of research on the needed fields for the iTunes RSS and Media RSS and what should be in them. (Those feedforall.com tutorials appear to be the best I could find on this.)

  Second, I did about six hours of work to build what I called our ominbus RSS feed. The most effort went into building an RSS feed that includes disparate Django application components, but this thread on query set manipulation from django-users referenced from Michael Angela's blog was very helpful. I was glad, actually, that the ultimate solution centered around complicated features of Python. Being an old-school Perl hacker, I love when the solution is obvious once you learn a feature of the language that you didn't know before. (Is that the definition of programming language snobbery? ;)

  It also turns out that Fabian Scherschel (aka fabsh) had started working on on a Django podcast application too, and he's going to merge in his efforts with podjango. I preemptively apologize publicly, BTW, that I didn't reach out to the django-podcast guys before starting a new project. However, I'm sure fabsh and I both would be happy to cooperate with them if they want to try to merge the codebases (although I don't want to use a non-Free software platform like Google Code to host any project I work on ;). Anyway, I really think RSS feeds should be implemented using generators in Python code rather than in templates, though, and I think the user interface should be abstracted away from as many details for the DTD fields as possible. Thus, it may turn out that we and django-podcast have incompatible design goals.

  Anyway, I hope the code we've released is useful, and I'm glad for Fabian to take over as project lead. I need to move onto other projects, and hope that others will be interested in generalizing and improving the code under Fab's leadership. I'm happy to help it along, so please subscribe to the mailing list if you're interested.

  Posted on Thursday 20 November 2008 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

• 2008-11-13: GPLv3/AGPLv3 Adoption: If It Happened Too Fast, I'd Be Worried

  Since the release of GPLv3, technology pundits have been opining about how adoption is unlikely, usually citing Linux's still-GPLv2 status as (often their only) example. Even though I'm a pro-GPLv3 (and, specifically, pro-AGPLv3) advocate, I have never been troubled by slow adoption, as long as it remained on a linear upswing from release day onward (which it has).

  Only expecting linear growth is a simple proposition, really. Free, Libre and Open Source Software (FLOSS) projects do not always have the most perfectly organized of copyright inventories, nor is the licensing policy of the project the daily, primary focus of the developers. Indeed, most developers have traditionally seen a licensing decision as something you think about once and never revisit!

  In some cases, such as with many of the packages in FSF's GNU project, there is a single entity copyright holder with a policy agenda, and such organizations can (and did) immediately relicense large codebases under GPLv3. However, in most projects, individual contributors keep their own copyrights, and the relicensing takes time and discussion, which must compete with the daily work of making better code.

  Relicensing from GPLv2-or-later

  GPLv2-or-later packages can be relicensed to GPLv3-or-later, or GPLv3-only, basically instantaneously. However, wholesale relicensing by a project leader would be downright rude. We're a consensus-driven community, and any project leader worth her title would not unilaterally relicense without listening to the community. In fact, it's somewhat unlikely a project leader would relicense any existing GPLv2-or-later copyrights under GPLv3-only (or GPLv3-or-later, for that matter) without the consent of the contributor who holds those copyrights. Even though that consent isn't needed, getting it anyway is a nice, consensus-building thing to do.

  In fact, I think most projects prefer to slowly change the license in various subparts of the work, as those parts are changed and improved. That approach saves time from having to do a “bombing run” patch that changes all the notices across the project, and also reflects reality a bit better⁰.

  Of course, once you change one copyrightable part of a larger work to GPLv3-or-later, the effective license of the whole work is GPLv3-or-later, even if some parts could be extracted and distributed under GPLv2-or-later. So, in essence, GPLv2-or-later projects that have started taking patches licensed under GPLv3-or-later have effectively migrated to GPLv3¹. This fact alone, BTW, is why I believe strongly that GPLv3 adoption statistics sites (like Palamida's) have counts that underestimate adoption. Such sites are almost surely undercounting this phenomena. (It's interesting to note that even with such likely undercounting, Palamida's numbers show a sure and steady linear increase in GPLv3 and AGPLv3 adoption.)

  Relicensing from GPLv2-only

  Relicensing from GPLv2-only is a tougher case, and will take longer for a project that undertakes it. Such relicensing requires some hard work, as a project leader will have to account for the copyright inventory and ensure that she has permission to relicense. This job, while arduous, is not impossible (as many pundits have suggested).

  But even folks like Linus Torvalds himself are thinking about how to get this done. Recently, I began using git more regularly. I noticed that Linus designed git's license to leave open an easily implemented possibility for future GPLv3 licensing. Even the bastion of GPLv2-only-ville wants options for GPLv3-relicensing left open.

  Not Rushing Is a Good Thing

  Software freedom licenses define the rules for our community; they are, in essence, a form of legislation that each project constructs for itself. One “country” (i.e., the GNU project) has changed all its “laws” quickly because it's located on the epicenter of where those “laws” were drafted. Indeed, most of us who were deeply involved with the GPLv3 process were happy to change quickly, because we watched the license construction happen draft-by-draft, and we understood deeply the policy questions and how they were addressed.

  However, most FLOSS developers aren't FLOSS licensing wonks like I and my colleagues at the FSF are. So, we always understood that developers would need time to grok the new license, and that they would prefer to wait for its final release before they bothered. (Not everyone wants to “run the daily snapshot in production”, after all.) The developers should indeed take their time. As a copyleft advocate, I'd never want a project to pick new rules they aren't ready for, or set legal terms they don't fully understand yet.

  The adoption rate of GPLv3 and AGPLv3 seems to reflect this careful and reasoned approach. Pundits can keep saying that the new license has failed, but I'm not going take those comments seriously until the pundits can prove that this linear growth — a product of each project weighing the options slowly and carefully to come a decision and then starting the slow migration — has ended. For the moment, though, we seem right on course.

  ---

  ⁰Merely replacing the existing GPLv2-or-later notice to read “GPLv3-or-later” (or GPLv3-only) has little effect. In our highly-archived Internet world, the code that was under GPLv2-or-later will always be available somewhere. Since GPLv2 is irrevocable, you can't take away someone's permanent right to copy, modify, distribute the work under GPLv2. So, until you actually change the code, the benefit of a relicense is virtually non-existent. Indeed, its only actual value is to remind your co-developers of the plan to license as GPLv3-or-later going forward, and make it easy for them to license their changes under GPLv3-or-later.

  ¹I also suspect that many projects that are doing this may not be clearly explaining the overall licensing of the project to their users. A side-project that I work on during the weekends called PokerSource is actually in the midst of slow migration from GPLv3-or-later to AGPLv3-or-later. I have carefully explained our license migration and its implications in the toplevel LICENSE file, and encourage other projects to follow that example.

  Posted on Thursday 13 November 2008 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

September

• 2008-09-20: A Day to Focus on Software Freedom and Reject Proprietary Software

  Today is International Software Freedom Day. I plan to spend the whole day writing as much Free Software as I can get done. I have read about lots of educational events teaching people how to use and install Free Software, and those sound great. I am glad to read stories about how well the day is being spent by many, and I can only hope to have contributed as much as people who spend the day, for example, teaching kids to use GNU/Linux.

  What troubles me, though, is the some events today are sponsored by companies that produce proprietary software. I notice that even the official Software Freedom Day site lists various proprietary (or semi-proprietary) software companies as sponsors. Indeed, I declined an invitation to an event sponsored and hosted by a proprietary software company.

  Today is about saying no to proprietary software, at least for one day. We live in the real world, of course, and some days we have to be willing to set our political beliefs aside to negotiate with proprietary software companies. But, on Software Freedom Day, I hope that our community will send a message to proprietary (or semi-proprietary) software companies that we reject user subjugation and favor software freedom instead.

  Posted on Saturday 20 September 2008 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

• 2008-09-04: GPL, The 2-clause BSD of Network Services

  Crossposted with autonomo.us.

  So often, a particular strategy becomes dogma. Copyleft licensing constantly allures us in this manner. Every long-term software freedom advocate I have ever known — myself included — has spent periods of time slipping on the comfortable shoes of belief that copyleft is the central catalyst for software freedom.

  Copyleft indeed remains a successful strategy in maximizing software freedom because it backs up a community consensus on software sharing with the protection of the law. However, most people do not comply with the GPL merely because they fear the consequences of copyright infringement. Rather, they comply for altruistic reasons: because it advances their own freedom and the freedom of the people around them.

  Indeed, it is so important to remember that many of the FLOSS programs we use every day are not copylefted, and do not actually have any long-term proprietary forks (for me, Subversion, Trac and Twisted come to mind quickly). Examples like this helped me to again re-eradicate some clouded thinking about copyleft as central tenant.

  With this mindset fresh, Mike Linksvayer and I had an excellent discussion last month that solidified this connection to network services, and specifically, the licenses for network services software. Many GPL'd network service software give no source to users, but that may have little to do with the authors' “failure to upgrade” to the AGPL. In other words, the non-source availability of network service applications that are otherwise licensed in freedom is probably unrelated to the lack of network-freedom provisions in the license.

  In fact, more likely, the network service world now mimics the early days of the BSD licenses. Deployers are “proprietarizing” by default merely because there is no social effect to encourage release of modified source. Often, they likely haven't considered the complex issues of network service freedom, and are following the common existing practices. Advent of the GPL did help encourage software sharing in the community, but the general change in social standards that accompanied the GPL probably had a more substantial impact.

  Therefore, improved social standards will help improve source sharing in network services. We need to encourage, and more importantly, make it easy for network service deployers to make source of network applications available, regardless of their particular FLOSS license. No existing non-AGPL FLOSS licenses prohibit making the source available to network users. Network providers can and should simply do it voluntarily out of respect for their users. Developers of network service software, even if they do not choose the AGPL, should make it easy for the deployers to give source to their users. I hope to assist in this regard more directly before the end of 2008.

  Posted on Thursday 04 September 2008 by Bradley M. Kuhn.

  Comment on this post in this identi.ca conversation.

• 2008-09-02: GNU's Birthday

  Twenty-five years ago this month, I had just gotten my first computer, a Commodore 64, and was learning the very basics (quite literally) of programming. Unfortunately for my education, it would be a full eight years before I'd be permitted to see any source code to a computer program that I didn't write myself. I often look back at those eight years and consider that my most formative years of programming learning were wasted, since I was not permitted to study the programs written by the greatest minds.

  Fortunately for all the young programmers to come after me, something else was happening in an office at an MIT building in September 1983 that would make sure everyone would have the freedom to study code, and the freedom to improve it and contribute to the global library of software development knowledge. Richard Stallman announced that he would start the GNU project, a complete operating system that would give all its users freedom.

  I got involved with Free Software in 1992. At the time, I was the one student in my university who had ever heard of GNU and the recently released kernel named Linux. My professors knew of “that Stallman guy” but were focused primarily on academic research. Fortunately for me, they nevertheless gave me free reign over the systems to turn them into what might have been, in late 1992, one of the first Computer Science labs running entirely Free Software.

  Much more has happened since even then. To commemorate all that has come since Stallman's announcement, my colleagues at the FSF, home of the GNU project, released a video for this historic 25 year anniversary. It took twenty-five years, and a fight at the BBC over DRM, but now even a famous, accomplished actor like Stephen Fry is interested in the work that Stallman began way back in a year when Michael Jackson was a musical phenomenon and not merely a punchline of a joke.

  These days, I have almost weekly moments of surprise that people outside of the Software Freedom Movement have actually heard of what I do for a living. When Matt Lee (whom I got to know when he came up through the ranks in the 2000's as I did in the 1990's as a new FSF volunteer) told me a few months ago that Stephen Fry had enthusiastically and immediately agreed to make this video, it was yet another moment of surprise. We now live in a movement that impacts everyone in the industrialized world, because nearly everyone who has access to electricity also must use a computer to interact with daily life. So many people are impacted by the problems of proprietary software that Stallman noticed in 1983 impacting his small developer community. Thanks to the work of thousands, we now have the opportunity to welcome new groups into a computing world that can give them freedom. I'm happy that the friendly face of a talented and accomplished entertainer and world-class actor is here to welcome them.

  Posted on Tuesday 02 September 2008 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

August

• 2008-08-20: Compliance Advice Core-Dumped

  For ten years, I've been building up a bunch of standard advice on GPL compliance. Usually, I've found myself repeating this advice on the phone, again and again, to another new GPL violator who screwed it all up, just like the last one did. In the hopes that we will not have to keep giving this advice one-at-a-time to each violator, my colleagues and I have finally gotten an opportunity to write out in detail our best advice on the subject.

  Somewhere around 2004 or so, I thought that all of the GPL enforcement was going to get easier. After Peter Brown, Eben Moglen, David Turner and I had formalized FSF's GPL Compliance Lab, and Dan Ravicher and I had taught a few CLE classes to lawyers in the field, we believed that the world was getting a clue about GPL compliance. Many people did, of course, and we constantly welcome new groups of well-educated people in the commercial space who comply with the GPL correctly and who interact positively with our community.

  However, the interest in FLOSS keeps growing, rapidly. So, for every new citizen who does the research ahead of time and learns the rules, there are dozens who don't. The education effort is therefore forever ongoing because the newbies always seem to outnumber the old hands. It's our own copyleft version of Eternal September. The whole space is now big enough that one-by-one education in our traditional way can no longer scale.

  Hopefully, publishing some guidelines for GPL compliance will help the education effort scale. If you redistribute GPL'd software commercially in any way, or you are a lawyer who represents people that do, please spend the time to familiarize yourself with this information. If you have ideas on how we can expand this document, we would of course love to hear from you.

  Update (on 2008-08-26): Thanks for all the feedback we've gotten from the community. We've been glad to update the document to incorporate your suggestions.

  Posted on Wednesday 20 August 2008 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

• 2008-08-16: If The Worst of Us Wins, The Best of Us Surely Will

  There has been much chatter and coverage about the court decision related to the Artistic License decision last week. Having spent a decade worrying about the Artistic License, I was surprised and relieved to see this decision.

  One of the first tasks I undertook in the late 1990s in the world of Software Freedom licenses were issues surrounding the Artistic License. My first Software Freedom community was the Perl one, but my second was the licensing wonks. Therefore, I walked the line for many years, as I considered the poor drafting of the Original Artistic License. As the Perl6 process started in 2000, I chaired the Licensing Committee, and wrote all of the licensing RFCs in the Perl6 process, including RFC 211, which collected all the historical arguments about bad drafting of the Artistic License and argued that we change the Artistic License.

  Last year, I was silent about the lower court decision, because I'd known for years that the Original Artistic License was a poorly drafted and confusing license. I frankly was not surprised that a court had considered it problematic. Of course, I was glad for the appeal, and that there was a widely supported amicus brief arguing that the Artistic License should be treated appropriately as a copyright license. However, I had already prepared myself to live with the fact that the my greatest licensing fears had come true: the most poorly drafted FLOSS license had been the first for a USA court to consider, and that court had seen what we all saw — a license that was confusing and could not be upheld due to lack of clarity.

  I was overjoyed last week to see that the Federal Circuit ruled that even a poorly drafted copyright license like that must be taken seriously and that the copyright holder could seek remedies under copyright law. Now that I have seen this decision, I feel confident that the rest of our licenses will breeze through the courts, should the need arise. We've been arguing for a decade that the Artistic license is problematic, and even Larry Wall (its author) admitted that his intent wasn't necessarily to draft a good license but to inspire people to contact him for additional permissions outside the GPL. Nevertheless, he drafted a license that the USA courts clearly see as a valid copyright license. The bottom bar has been set, and since all our other licenses are much clearer, it will be smooth sailing here on out.

  (Please note, if you are a fan of the Artistic License, the Artistic License 2.0 is a much better option and is recommended. Despite the decision, we should still cease using the Original Artistic License now that we have 2.0.)

  Posted on Saturday 16 August 2008 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

July

• 2008-07-23: When Will Hosting Sites Allow AGPLv3 Code?

  At the OSCON Google Open Source Update, Chris Dibona reiterated his requirement to see significant adoption before code.google.com will host AGPLv3 projects (his words). I asked him to tell us how tall we in the AGPLv3 community need to be to ride this ride, but unfortunately he reiterated only the bar of “significant adoption”. I therefore am redoubling my efforts to encourage projects to switch to the AGPLv3, and for our community to build a list of AGPLv3'd projects, so that we can convince them.

  Chris argues that including AGPLv3 would encourage of license proliferation. On their surface, his arguments seem to be valid. I don't like license proliferation, either. Indeed, I have been a proponent of reducing license proliferation since around 2000 — long before it was fashionable, and when the OSI itself was the primary purveyor of license proliferation. I'm very glad that everyone has gotten on the same page about this, and would certainly not want to change my position now that we've reached consensus.

  However, AGPLv3 is not an example of license proliferation for three reasons. First, AGPLv3 is a license published by an organization (my old employers, the FSF) that has a 24 year history of publishing — indeed, inventing — the most popular and major licenses available in the FLOSS world. To compare them to (as some have) Nokia, who published merely a vanity license with an OSI rubber stamp is simply not a valid comparison.

  Second, the history of AGPL itself shows that proliferation is not at work here. AGPL was first drafted and published in early 2002, and has been in constant use since then. It filled a niche for users who were clamoring for a specific license to address a clear concern related to software freedom. I grant that the license is adopted by a small community, but GPL itself started with minimal interest (i.e., only in the GNU project). Also, licenses that are “GPL plus various special exceptions” that deal with tightly confined areas are, similar to AGPLv3, of interest to only small groups currently. There is no reason to reject a license that has a strong level of interest in a small community, particularly if it is — as GPL+exceptions and AGPLv3 are — compatible with existing licenses like GPLv3. In these cases, we should understand the reasons its user community picks it. In the APGLv3 case, the license addresses important FLOSS principles under serious study by our community. Any license that is actually redundant couldn't pass this test; AGPLv3 can.

  Finally, the AGPLv3 is the outcome of a public process in which Google itself (as well as many others) participated. Indeed, it was the original intent of the GPLv3 drafters to include the Affero clause in the GPLv3 itself. The committees (on which Google served) convinced RMS and other drafters to not include the clause, and that is why it was put into a separate license. We must consider the fairness issue: some members of the community asked us to not include the Affero clause in GPLv3; others wanted it. The parts of the community who didn't want the clause should be accepting of the idea that another publicly-audited license to address this concern should be published for the slighted community.

  Therefore, in this post, I am asking for help: will someone maintain a website that specifically tracks AGPLv3 adoption (as opposed to other sites that try to track everything)? I was going to do it myself, but since I'm the author of the Affero clause and a primary advocate in AGPLv3 adoption, I think it would better if someone else did it. Please email me if you are interested in this volunteer task. I'll update this post once we have a team of folks willing to work on this.

  Posted on Wednesday 23 July 2008 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

• 2008-07-22: Welte Receives Open Source Award for GPL Enforcement

  About two hours ago, Harald Welte received the 2008 Open Source Award entitled the Defender of Rights. (Open Source awards are renamed for each individual who receives them.) This award comes on the heels of the FSF Award for the Advancement of Free Software in March. I am glad that GPL enforcement work is now receiving the recognition it deserves.

  When I started doing GPL enforcement work in 1999, and even when, two years later, it became a major center of my work (as it remains today), the violations space was a very lonely place to work. During that early period, I and my team at FSF were the only people actively enforcing the GPL on behalf of the Software Freedom Movement. When Harald started gpl-violations.org in 2004, it was a relief to finally see someone else taking GPL violations as seriously as I and my colleagues at the FSF had been for so many years.

  Of course, it was no surprise when Harald received the FSF award earlier this year. This Open Source Award now shows a broader recognition. In fact, I hope that this award is a harbinger to indicate that the larger FLOSS world has realized the tremendous value in consistent and serious GPL enforcement that some of us have done for so long. The copyleft is meaningless if it is not defended against those who ignore it, and I am glad that more of the FLOSS world has begun to see that.

  Posted on Tuesday 22 July 2008 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

• 2008-07-14: Autonomo.us Computing

  The Network Services committee that I alluded to recently in various interviews is now officially public and named: Autonomo.us. (Thanks to one of the committee members, Evan Prodromou, who donated the domain name. ) Autonomo.us is officially endorsed by the FSF.

  I've written before about how discussions began at FSF in January 2002 to address the “ASP loophole of the GPL”. In those months that followed, when I came up with the idea for what would (later be named) the Affero clause, I naïvely thought that a license term for the software would “solve” the Software as a Service (SaaS) problem. Indeed, I considered the problem fully addressed upon publication of the original AGPL, and it was much later before I realized the problem was more complex.

  The AGPLv3 is only one (albeit essential) part of what must be a multi-pronged strategy to address the freedom implications and concerns of SaaS. At Auotonomo.us, we have published The Franklin Street Statement on Freedom and Network Services (named for the place it was declared — the location of post-Temple-Place FSF offices). The Statement is a manifesto (of sorts) outlining the concerns that must be addressed and the beginnings of some ideas for solutions. I hope you will read it and begin considering this issue if you haven't already, and that you will endorse the statement if you already understand the issue. We hope to be publishing more on that site as the year goes on!

  Posted on Monday 14 July 2008 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

• 2008-07-03: Like Twitter, but with Freedom Inside

  A company called Control Yourself, led by Evan Prodromou (who serves with me and many others on the FSF-endorsed Freedom for Network Services Committee) yesterday launched a site called identi.ca. It's a microblogging service similar to Twitter, but it is designed to respect the rights and freedoms of its users.

  I'm personally excited because the software for the system, Laconica, is under the license that I originally drafted back in 2002, the Affero GPL (which was updated as part of the GPLv3 process, and is now available as AGPLv3). This marks the first time I've seen a company release its product under a network service freedom-defending license from the start.

  His launch comes at an interesting time. Twitter has had no Jabber-based updates for more than a month, and Identica allows updates via Jabber. Thus, in a way, it's more fully featured than Twitter is right now!

  Posted on Thursday 03 July 2008 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

June

• 2008-06-28: Does This Mean We've “Made It” as a Social Cause?

  I got a phone call yesterday from someone involved with one of the many socially responsible investment houses. It appears that in some (thus far, small) corners of the socially responsible investment community, they've begun the nascent stages of adding “willingness to contribute to FLOSS” to the consideration map of social responsibility. This is an issue that has plagued me personally for many years, and I was excited to receive the call.

  When I graduated high school and read my first book on personal financial management, I learned how to invest for retirement in mutual funds. The book mentioned the (then) somewhat new practice of “socially responsible investing”, which immediately intrigued me. The author argued, however, that it was silly to make investment decisions based on personal beliefs. I immediately disagreed with that, but I discovered that his secondary point was actually accurate: beyond the Big Issues (weapons manufacturing, tobacco, etc.), it was tough to find a fund that actually shared your personal beliefs.

  Once I did some research, I discovered that it wasn't actually as bad as that, because there actually is a pretty good consensus on what is and is not socially responsible (or, at least, the general consensus in this regard seems to match my personal beliefs, anyway). However, I did discover a gaping hole in the social responsible investment agenda. The biggest social issue in my personal life — the issue of software freedom — was never on others' radar screens as a “socially responsible issue”.

  For example, in 1996, when I had my first opportunity to roll a 401(k) into an investment of my own choosing, I discovered a troubling fact. Every single socially responsible fund, when I looked at their stocks held (sorted by percentage), Microsoft was always in the top ten, and Oracle in the top twenty. Indeed, on most socially responsible axes, Microsoft and Oracle look good: they treat their employees reasonably well, they don't generally build products that actively kill people (although many of us die inside a little bit every time we use proprietary software), and, heck, if they use more DRM, they can ship their software and documentation via the network and won't even ship as many CDs to fill up landfills. This kind of thinking about “socially responsible” ignores how the proprietariness of the company's technology negatively impacts people outside of the company. Nevertheless, for years, I've held my nose and put my retirement money in these funds, content on the compromised idea that at least I don't have my retirement savings in oil companies.

  I tell this backstory to communicate how glad I was to get the call from an employee of a socially responsible investment house. This fellow was actually investigating the FLOSS credentials of various companies and trying to bring it forward as a criterion when considering how socially responsible their practices are. He seemed genuinely interested in bringing this forward as part of a social agenda for his company. I told him: every great idea starts as a conversation between two people, and enthusiastically answered his queries.

  It was clear FLOSS considerations are new and not widely adopted as a factor in the socially responsible investing world, but I am glad that at least someone in that world is thinking about these questions. Of course, I agree that in grand scheme, FLOSS issues should not be ranked too highly — certainly issues of environmental sustainability and human rights have a higher and more immediate social impact⁰. However, given that Microsoft so often ends up in the top ten of “good socially responsible investments”, FLOSS issues are clearly ranked far too low in the calculation.

  Hopefully, this phone call I took yesterday shows we're entering an era where FLOSS issues are on the socially responsible criteria list for investors. I further hope this blog entry doesn't stop socially responsible investors and fund managers from contacting me in the future to get advice on how socially responsible various companies are. I debated whether to write about this call publicly, but ultimately went for it, since it's an issue I think deserves some net.attention. So many of us, FLOSS fans included, must now must manage our own retirement accounts, since pension funds have generally given way to self-directed retirement savings options. If you have a fund with a socially responsible investment company, take this opportunity to give them a call or send them a letter to tell them you'd like to see FLOSS issues on the criteria list. If you don't yet invest in with a socially responsible company, consider switching to one, as they clearly will be the first to add FLOSS-related criteria to their investing agenda.

  ---

  ⁰I have never believed myself that FLOSS is the most important social justice issue in the grand scheme. I struggled for years with the question of whether to devote my career to a social cause that wasn't top priority; things like human rights and environmental sustainability certainly deserve more immediate attention. However, it turned out that my skills, knowledge, background and talent are clearly uniquely tuned to Computer Science in general and FLOSS in particular, and therefore I can have the greatest positive impact focusing on this rather than would-be higher priority causes. If only we could get people in these other movements to at least see that they are better off not using Microsoft for their own operations (in my experience, NGOs and NPOs are more likely to stick with proprietary software than for-profit companies), but that's an agenda for another blog entry.

  Posted on Saturday 28 June 2008 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

• 2008-06-20: Stop Obsessing and Just Do It: VoIP Encryption Is Easier than You Think

  Ian Sullivan showed me an article that he read about eavesdropping on Internet telephony calls. I'm baffled at the obsession about this issue on two fronts. First, I am amazed that people want to hand their phone calls over to yet another proprietary vendor (aka Skype) using unpublished, undocumented non-standard protocols and who respects your privacy even less than the traditional PSTN vendors. Second, I don't understand why cryptography experts believe we need to develop complicated new technology to solve this problem in the medium term.

  At SFLC, I set up the telephony system as VoIP with encryption on every possible leg. While SFLC sometimes uses Skype, I don't, of course, because it is (a) proprietary software and (b) based on an undocumented protocol, (c) controlled by a company that has less respect for users' privacy than the PSTN companies themselves. Indeed, security was actually last on our list for reasons to reject Skype, because we already had a simple solution for encrypting our telephony traffic: All calls are made through a VPN.

  Specifically, at SFLC, I set up a system whereby all users have an OpenVPN connection back to the home office. From there, they have access to register a SIP client to an internal Asterisk server living inside the VPN network. Using that SIP phone, they could call any SFLC employee, fully encrypted. That call continues either on the internal secured network, or back out over the same VPN to the other SIP client. Users can also dial out from there to any PSTN DID.

  Of course, when calling the PSTN, the encryption ends at SFLC's office, but that's the PSTN's fault, not ours. No technological solution — save using a modem to turn that traffic digital — can easily solve that. However, with minimal effort, and using existing encryption subsystems, we have end-to-end encryption for all employee-to-employee calls.

  And it could go even further with a day's effort of work! I have a pretty simple idea on how to have an encrypted call to anyone who happens to have a SIP client and an OpenVPN client. My plan is to make a public OpenVPN server that accepts connection from any host at all, that would then allow encrypted “phone the office” calls to any SFLC phone with any SIP client anywhere on the Internet. In this way, anyone wishing end-to-end phone encryption to the SFLC need only connect to that publicly accessible OpenVPN and dial our extensions with their SIP client over that line. This solution even has the added bonus that it avoids the common firewall and NAT related SIP problems, since all traffic gets tunneled through the OpenVPN: if OpenVPN (which is, unlike SIP, a single-port UDP/IP protocol) works, SIP automatically does!

  The main criticism of this technique regards the silliness of two employees at a conference in San Francisco bouncing all the way through our NYC offices just to make a call to each other. While the Bandwidth Wasting Police might show up at my door someday, I don't actually find this to be a serious problem. The last mile is always the problem in Internet telephony, so a call that goes mostly across a single set of last mile infrastructure in a particular municipality is no worse nor better than one that takes a long haul round trip. Very occasionally, there is a half second of delay when you have a few VPN-based users on a conference call together, but that has a nice social side effect of stopping people from trying to interrupt each other.

  Finally, the article linked above talks about the issue of variable bit rate compression changing packet size such that even encrypted packets yield possible speech information, since some sounds need larger packets than others. This problem is solved simply for us with two systems: (a) we use µ-law, a very old, constant bit rate codec, and (b) a tiny bit of entropy is added to our packets by default, because the encryption is occurring for all traffic across the VPN connection, not just the phone call itself. Remember: all the traffic is going together across the one OpenVPN UDP port, so an eavesdropper would need to detangle the VoIP traffic from everything else. Indeed, I could easily make (b) even stronger by simply having the SIP client open another connection back to the asterisk host and exchange payloads generated from /dev/random back and forth while the phone call is going on.

  This is really one of those cases where the simpler the solution, the more secure it is. Trying to focus on “encryption of VoIP and VoIP only” is what leads us to the kinds of vulnerabilities described in that article. VoIP isn't like email, where you always need an encryption-unaware delivery mechanism between Alice and Bob. I believe I've described a simple mechanism that can allow anyone with an Asterisk box, an OpenVPN server, and an Internet connection to publish to the world easy instructions for phoning them securely with merely a SIP client plus and OpenVPN client. Why don't we just take the easy and more secure route and do our VoIP this way?

  Posted on Friday 20 June 2008 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

April

• 2008-04-10: The GPL is a Tool to Encourage Freedom, Not an End in Itself

  I was amazed to be involved in yet another discussion recently regarding the old debate about the scope of the GPL under copyright law. The debate itself isn't amazing — these debates have happened somewhere every six months, almost on cue, since around 1994 or so. What amazed me this time is that some people in the debate believed that the GPL proponents intend to sneakily pursue an increased scope for copyright law. Those who think that have completely misunderstood the fundamental idea behind the GPL.

  I'm disturbed by the notion that some believe the goal of the GPL is to expand copyrightability and the inclusiveness of derivative works. It seems that so many forget (or maybe they never even knew) that copyleft was invented to hack copyright — to turn its typical applications to software inside out. The state of affairs that software is controlled by draconian copyright rules is a lamentable reality; copyleft is merely a tool that diffuses the proprietary copyright weaponry.

  But, if it were possible to really consider reduction in copyright control over software, then I don't know of a single GPL proponent who wouldn't want to bilaterally reduce copyright's scope for software. For example, I've often proposed, since around 2001, that perhaps copyright for software should only last three years, non-renewable, and that it require all who wished to distribute non-public-domain software to register the source with the Copyright Office. At the end of the three years, the Copyright Office would automatically publish that now public-domain source to the world.

  If my hypothetical system were the actual (and only) legal regime for software, and were equally applied to all software — from the fully Free to the most proprietary — I'd have no sadness at all that opportunities for GPL enforcement ended after three years, and that all GPL'd software fell into the public domain on that tight schedule, because proprietary software and FLOSS would have the same treatment. Meanwhile, great benefit would be gained for the freedom of all software users. In short, GPL is not an end in itself, and I wouldn't want to ignore the actual goal — more freedom for software users — merely to strengthen one tool in that battle.

  In one of my favorite films, Kevin Smith's Dogma, Chris Rock's character, Rufus, argues that it's better to have ideas than beliefs, because ideas can change when the situation does, but beliefs become ingrained and are harder to shake. I'm not a belief-less person, but I certainly hold the GPL and the notion of copyleft firmly in the “idea” camp, not the “belief” one. It's unfortunate that the entrenched interests outside of software are (more or less) inadvertently strengthening software copyright, too. Thus, in the meantime, we must hold steadfast to the GPL going as far as is legally permitted under this ridiculously expansive copyright system we have. But, should a real policy dialogue open on the reduction software copyright's scope, GPL proponents will be the first in line to encourage such bilateral reduction.

  Posted on Thursday 10 April 2008 by Bradley M. Kuhn.

  Submit comments on this post to <bkuhn@ebb.org>.

January

• 2008-01-24: When your apt-mirror is always downl