Yesterday 00 02 04 06 08 10 12 14 16 18 20 22 
2020-08-12 22:41:57
Next Page: 25

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

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


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 owner0. 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 apply1, 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 (which I do, BTW, because it's the only online forum I'm assured that I'll actually read and respond to.)

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

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


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

0 Update on 2020-04-09: At the time I wrote the text above, I was writing for a specific organization where I worked at the time, who held this position. I trusted lawyers I spoke to at the time, who insisted that GPLv2's failure to mention cryptography meant that “scripts used to control compilation and installation of the executable” necessarily did not include. I believed these lawyers, and shouldn't have. Lawyers I've talked to since then — many, many lawyers ” have taught me since that my 2010 view lacked nuance. The point is the issue of cryptographic lock-down is an open question


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, Conservancy is 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.)


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 from 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 at 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.
Sponsored by the GNOME Foundation!

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.


Conservancy's First Blog Post   


[ Crossposted from Conservancy's blog. ]

As can be seen in today's announcement, today is my first day as full-time Executive Director at the Software Freedom Conservancy. For four years, I have worked part-time on nights, weekends, and lunch times to keep Conservancy running and to implement and administer the services that Conservancy provides to its member projects. It's actual quite a relief to now have full-time attention available to carry out this important work.

From the start, one of my goals with Conservancy has been to run the non-profit organization as transparently as possible. At times, I've found that when time is limited, keeping the public informed about all your work is often the first item to fall too far down on the action item list. Now that Conservancy is my primary, daily focus, I hope to increase its transparency as much as possible.

Specifically, I plan to keep a regular blog about activities of the Conservancy. I've found that a public blog is a particular convenient way to report to the public in a non-onerous way about the activities of an organization. Indeed, we usually ask those developers whose work is funded through Conservancy to keep a blog about their activities, so that the project's community and the public at large can get regular updates about the work. I should hold myself to no less a standard!

I encourage everyone to subscribe to the full Conservancy site RSS feed, where you'll receive both news items and blog posts from the Conservancy. There are also separate feeds available for just news and just blog posts. Also, if you're a subscriber to my personal blog, I will cross-post these blog posts there, although my posts on Conservancy's blog will certainly be a proper subset of my entire personal blog.


Canonical, Ltd. Finally On Record: Seeking Open Core   


I've written before about my deep skepticism regarding the true motives of Canonical, Ltd.'s advocacy and demand of for-profit corporate copyright assignment without promises to adhere to copyleft. I've often asked Canonical employees, including Jono Bacon, Amanda Brock, Jane Silber, Mark Shuttleworth himself, and — in the comments of this very blog postMatt Asay to explain (a) why exactly they demand copyright assignment on their projects, rather than merely having contributors agree to the GNU GPL formally (like projects such as Linux do), and (b) why, having received a contributor's copyright assignment, Canonical, Ltd. refuses to promise to keep the software copylefted and never proprietarize it (FSF, for example, has always done the latter in assignments). When I ask these questions of Canonical, Ltd. employees, they invariably artfully change the subject.

I've actually been asking these questions for at least a year and a half, but I really began to get worried earlier this year when Mark Shuttleworth falsely claimed that Canonical, Ltd.'s copyright assignment was no different than the FSF's copyright assignment. That event made it clear to me that there was a job of salesmanship going on: Canonical, Ltd. was trying to sell something to community that the community doesn't want nor need, and trying to reuse the good name of other people and organizations to do it.

Since that interview in February, Canonical, Ltd. has launched a manipulatively named product called “Project Harmony”. They market this product as a “summit” of sorts — purported to have no determined agenda other than to discuss the issue of contributor agreements and copyright assignment, and come to a community consensus on this. Their goal, however, was merely to get community members to lend their good names to the process. Indeed, Canonical, Ltd. has oft attempted to use the involvement of good people to make it seem as if Canonical, Ltd.'s agenda is endorsed by many. In fact, FSF recently distanced itself from the process because of Canonical, Ltd.'s actions in this regard. Simon Phipps had similarly distanced himself before that.

Nevertheless, it seems Canonical, Ltd. now believes that they've succeed in their sales job, because they've now confessed their true motive. In an IRC Q&A session last Thursday0, Shuttleworth finally admits that his goal is to increase the amount of “Open Core” activity. Specifically, Shuttleworth says at 15:21 (and following):

[C]ompare Qt and Gtk, Qt has a contribution agreement, Gtk doesn't, for a while, back in the bubble, Sun, Red Hat, Ximian and many other companies threw money at Gtk and it grew and improved very quickly but, then they lost interest, and it has stagnated. Qt was owned by Trolltech it was open source (GPL) but because of the contribution agreement they had many options including proprietary licensing, which is just fine with me alongside the GPL and later, because they owned Qt completely, they were an attractive acquisition for Nokia, All in all, the Qt ecosystem has benefitted and the Gtk ecosystem hasn't.

It takes some careful analysis to parse what's going on here. First of all, Shuttleworth is glossing over a lot of complicated Qt history. Qt started with a non-FaiF license (QPL), which later became a GPL-incompatible Free Software license. After a few years of this oddball, license-proliferation-style software freedom license, Trolltech stumbled upon the “Open Core” model (likely inspired by MySQL AB), and switched to GPL. When Nokia bought Trolltech, Nokia itself discovered that full-on “Open Core” was bad for the code base, and (as I heralded at the time) relicensed the codebase to LGPL (the same license used by Gtk). A few months after that, Nokia abandoned copyright assignment completely for Qt as well! (I.e., Shuttleworth is just wrong on this point entirely.) In fact, Shuttleworth, rather than supporting his pro-Open-Core argument, actually gave the prime example of Nokia/TrollTech's lesson learned: “don't do an Open-Core-style contributor agreement, you'll regret it”. (RMS also recently published a good essay on this subject).

Furthermore, Shuttleworth also ignores completely plenty of historical angst in communities that rely on Qt, which often had difficulty getting bugfixes upstream and other such challenges when dealing with a for-profit controlled “Open Core” library. (These were, in fact, among the reasons Nokia gave in May 2009 for the change in policy). Indeed, if the proprietary relicensing business is what made Trolltech such a lucrative acquisition for Nokia, why did they abandon the business model entirely within four months of the acquisition?

Although, Shuttleworth's “lucrative acquisition” point has some validity. Namely, “Open Core” makes wealthy, profit-driven types (e.g., VCs) drool. Meanwhile, people like me, Simon Phipps, NASA's Chris Kemp, John Mark Walker, Tarus Balog and many others are either very skeptical about “Open Core”, or dead-set against it. The reason it's meeting with so much opposition is because “Open Core” is a VC-friendly way to control all the copyright “assets” while pretending to actually have the goal of building an Open Source community. The real goal of “Open Core”, of course, is a bait-and-switch move. (Details on that are beyond the scope of this post and well covered in the links I've given.)

As to Shuttleworth's argument of Gtk stagnation, after my trip this past summer to GUADEC, I'm quite convinced that the GNOME community is extremely healthy. Indeed, as Dave Neary's GNOME Census shows, the GNOME codebases are well-contributed to by various corporate entities and (more importantly) volunteers. For-profit corporate folks like Shuttleworth and his executives tend not to like communities where a non-profit (in this case, the GNOME Foundation) shepherds a project and keeps the multiple for-profit interests at bay. In fact, he dislikes this so much that when GNOME was recently documenting its long standing copyright policies, he sent Silber to the GNOME Advisory Board (the first and only time Canonical, Ltd. sent such a high profile person to the Advisory Board) to argue against the long-standing GNOME community preference for no copyright assignment on its projects1. Silber's primary argument was that it was unreasonable for individual contributors to even ask to keep their own copyrights, since Canonical, Ltd. puts in the bulk of the work on their projects that require copyright assignment. Her argument was, in other words, an anti-software-freedom equality argument: a for-profit company is more valuable to the community than the individual contributor. Fortunately, GNOME Foundation didn't fall for this, continued its work with Intel to get the Clutter codebase free of copyright assignment (and that work has since succeeded). It's also particularly ironic that, a few months later, Neary showed that the very company making that argument contributes 22% less to the GNOME codebase than the volunteers Silber once argued don't contribute enough to warrant keeping their copyrights.

So, why have Shuttleworth and his staff been on a year-long campaign to convince everyone to embrace “Open Core” and give up all their rights that copyleft provides? Well, in the same IRC log (at 15:15) I quoted above, Shuttleworth admits that he has some work left to do to make Canonical, Ltd. profitable. And therein lies the connection: Shuttleworth admits Canonical, Ltd.'s profitability is a major goal (which is probably obvious). Then, in his next answer, he explains at great length how lucrative and important “Open Core” is. We should accept “Open Core”, Shuttleworth argues, merely because it's so important that Canonical, Ltd. be profitable.

Shuttleworth's argument reminds me of a story that Michael Moore (who famously made the documentary Roger and Me, and has since made other documentaries) told at a book-signing in the mid-1990s. Moore said (I'm paraphrasing from memory here, BTW):

Inevitably, I end up on planes next to some corporate executive. They look at me a few times, and then say: Hey, I know you, you're Roger Moore [audience laughs]. What I want to know, is what the hell have you got against profit? What's wrong with profit, anyway? The answer I give is simple: There's nothing wrong with profit at all. The question I'm raising is: What lengths are acceptable to achieve profit? We all agree that we can't exploit child labor and other such things, even if that helps profitability. Yet, once upon a time, these sorts of horrible policies were acceptable for corporations. So, my point is that we still need more changes to balance the push for profit with what's right for workers.

I quote this at length to make it abundantly clear: I'm not opposed to Canonical, Ltd. making a profit by supporting software freedom. I'm glad that Shuttleworth has contributed a non-trivial part of his personal wealth to start a company that employs many excellent FLOSS developers (and even sometimes lets those developers work on upstream projects). But the question really is: Are the values of software freedom worth giving up merely to make Canonical, Ltd. profitable? Should we just accept that proprietary network services like UbuntuOne, integrated on nearly every menu of the desktop, as reasonable merely because it might help Canonical, Ltd. make a few bucks? Do we think we should abandon copyleft's assurances of fair treatment to all, and hand over full proprietarization powers on GPL'd software to for-profit companies, merely so they can employ a few FLOSS developers to work primarily on non-upstream projects?

I don't think so. I'm often critical of Red Hat, but one thing they do get right in this regard is a healthy encouragement of their developers to start, contribute to, and maintain upstream projects that live in the community rather than inside Red Hat. Red Hat currently allows its engineers to keep their own copyrights and license them under whatever license the upstream project uses, binding them to the terms of the copyleft licenses (when the upstream project is copylefted). For projects generated inside Red Hat, after experimenting with the sorts of CLAs that I'm complaining about, they learned from the mistake and corrected it (although unfortunately, Red Hat hasn't universally corrected the problem). For the most part, Red Hat encourages outside contributors to give under their own copyright under the outbound license Red Hat chose for its projects (some of which are also copylefted). Red Hat's newer policies have some flaws (details of which are beyond the scope of this post), but it's orders of magnitude better than the copyright assignment intimidation tactics that other companies, like Canonical, Ltd., now employ.

So, don't let a friendly name like “Harmony” fool you. Our community has some key infrastructure, such as the copyleft itself, that actually keeps us harmonious. Contributor agreements aren't created equal, and therefore we should oppose the idea that contributor and assignment agreements should be set to the lowest common denominator to enable a for-profit corporate land-grab that Shuttleworth and other “Open Core” proponents seek. I also strongly advise the organizations and individuals who are assisting Canonical, Ltd. in this goal to stop immediately, particularly now that Shuttleworth has announced his “Open Core” plans.

Update (2010-10-18): In comments, many people have, quite correctly, argued that I have not proved that Canonical, Ltd. has plans to go “Open Core” with their copyright-assigned copyleft products. Such comments are correct; I intended this article to be an opinion piece, not a logical proof. I further agree that without absolute proof, the title of this blog post is an exaggeration. (I didn't change it, as that seemed disingenuous after the fact).

Anyway, to be clear, the only thing the chain of events described above prove is that Canonical, Ltd. wants “Open Core” as a possibility for the future. That part is trivially true: if they didn't want to reserve the possibility, they'd simply make a promise-back to keep the software as Free Software in their assignment. The only reason not to make an FSF-style promise-back is that you want to reserve the possibility of proprietary relicensing.

Meanwhile, even though I cannot construct a logical proof of it, I still believe the only possible explanation for this 1+ year marketing campaign described above is that Canonical, Ltd. is moving toward “Open Core” for those projects on which they are the sole copyright holder. I have asked others to offer alternative explanations of why Canonical, Ltd. is carrying out this campaign: I agree that there could exist another logical explanation other than the one I've presented. If someone can come up with one, then I would be happy to link to it here.

Finally, if Canonical, Ltd. comes out with a statement that they'll switch to using FSF's promise-back in their assignments, I will be very happy to admit I was wrong. The outcome I want is for individual developers to be treated right by corporations in control of particular codebases; I would much rather that happen than be correct in my opinions.

0I originally credited OMG Ubuntu as publishing Shutleworth's comments as an interview. Their reformatting of his comments temporarily confused me, and I thought they'd done an interview. Thanks to @gotunandan who pointed this out.

1Ironically, the debate had nothing to do with a Canonical, Ltd. codebase, since their contributions amount to so little (1%) of the GNOME codebase anyway. The debate was about the Clutter/Intel situation, which has since been resolved.

Responses Not In the Identica Thread:

  • Alex Hudson's blog post
  • Discussion on Hacker News
  • LWN comments
  • Matt Aslett's response and my response to him
  • Ingolf Schaefer's blog post, which only allows comments with a Google Account, so I comment below instead (to be clear, I'm not criticizing Ingolf's choice of Google-account-to-comment, especially since I make everyone who wants to comment here sign up for ;):

    Ingolf, you noted that you'd rather I not try to read between the lines to deduce that proprietary relicensing and/or “Open Core” is where Canonical, Ltd.'s marketing is leading. I disagree; I think it's useful to consider what seems a likely end-outcome here. My primary goal is to draw attention to it now in hopes of preventing it from happening. My best possible outcome is that I get proved wrong, and Canonical makes a promise-back in their assignment and/or CLA.

    Meanwhile, I don't think they can go “Open Core” and/or proprietary relicensing for all of Ubuntu, as you are saying. They aren't sole copyright holder in most of Ubuntu. The places where they can pursue these options is in Launchpad, pbuilder, upstart, and the other projects that require CLA and/or assignment.

    I don't know for sure that they'll do this, as I say above. I can deduce no other explanation. As I keep saying, if someone else has another possible explanation for Canonical, Ltd.'s behavior that I list above, I'm happy to link to it here. I can't see any other reason; they'd surely by now just made an FSF-style promise-back in their CLA if they didn't want to hold proprietarization as a possibility.


Free as in Freedom, Episode 0x07   


I realized that I should start regularly noting here on my blog when the oggcast that I co-host with Karen Sandler is released. There are perhaps folks who want content from my blog but haven't subscribed to the RSS feed of the show, and thus might want to know when new episodes come out. If this annoys people reading this blog, please let me know via email or identica.

In particular, perhaps readers won't like that, in these posts (which are going to be written after the show), I'm likely to drift off into topics beyond what was talked about on the show, and there may be “spoilers” for the oggcast in them. Again, if this annoys you (or if you like it) please let me know.

Today's FaiF episode is entitled Revoked?. The main issue of discussion is some recent confusions about the GPLv2 release of WinMTR. I was quoted in an article about the topic as well, and in the oggcast we discuss this issue at length.

To summarize my primary point in the oggcast: I'm often troubled when these issues come up, because I've seen these types of confusions so many times before in the last decade. (I've seen this particular one, almost exactly like this, at least five times.) I believe that those of us who focus on policy issues in software freedom need to do a better job documenting these sorts of issues.

Meanwhile, after we recorded the show I was thinking again about how Karen points out in the oggcast that the primary issues are legal ones. I don't really agree with that. These are policy questions, that are perhaps informed by legal analysis, and it's policy folks (and, specifically, Free Software project leaders) that should be guiding the discussion, not necessarily lawyers.

That's not to say that lawyers can't be policy folks as well; I actually think Karen and a few other lawyers I know are both. The problem is that if we simply take things like GPL on their face — as if they are unchanging laws of nature that simply need to be interpreted — we miss out on the fact that licenses, too, can have bugs and can fail to work the way that they should. A lawyer's job is typically to look at a license, or a law, or something more or less fixed in its existence and explain how it works, and perhaps argue for a particular position of how it should be understood.

In our community, activists and project leaders who set (or influence) policy should take such interpretations as input, and output plans to either change the licenses and interpretation to make sure they properly match the goals of software freedom, or to build up standards and practices that work within the existing licensing and legal structure to advance the goal of building a world where all published software is Free Software.

So, those are a few thoughts I had after recording; be sure to listen to FaiF 0x07 available in ogg and mp3 formats.


Questioning The Original Analysis On The Bionic Debate   


I was hoping to avoid having to comment further on this problematic story. I figured a comment as a brief statement was enough when it was just a story on the Register. But, it's now hit a major tech news outlet, and I feel that, given that I'm typically the first person everyone in the Free Software world comes to ask if something is a GPL violation, I'm going to get asked about this soon, so I might as well preempt the questions with a blog post, so I can answer any questions about it with this URL.

In short, the question is: Does Bionic (the Android/Linux default C library developed by Google) violate the GPL by importing “scrubbed” headers from Linux? For those of you seeking TL;DR version: You can stop now if you expect me to answer this question; I'm not going to. I'm just going to show that the apparent original analysis material that started this brouhaha is a speculative hypothesis which would require much more research to amount to anything of note.

Indeed, the kind of work needed to answer these questions typically requires the painstaking work of a talented developer working very closely with legal counsel. I've done analysis like this before for other projects. The only one I can easily talk about publicly is the ath5k situation. (If you want to hear more on that, you can listen to an old oggcast where I discussed this with Karen Sandler or read papers that were written on the subject back where I used to work.)

Anyway, most of what's been written about this subject of the Linux headers in Bionic has been poorly drafted speculation. I suppose some will say this blog post is no better, since I am not answering any questions, but my primary goal here is to draw attention that absolutely no one, as near as I can tell, has done the incredibly time consuming work to figure out anything approaching a definitive answer! Furthermore, the original article that launched this debate (Naughton's paper, The Bionic Library: Did Google Work Around the GPL?) is merely a position paper for a research project yet to be done.

Naughton's full paper gives some examples that would make a good starting point for a complete analysis. It's disturbing, however, that his paper is presented as if it's a complete analysis. At best, his paper is a position statement of a hypothesis that then needs the actual experiment to figure things out. That rigorous research (as I keep reiterating) is still undone.

To his credit, Naughton does admit that only the kind of analysis I'm talking about would yield a definitive answer. You have to get almost all the way through his paper to get to:

Determining copyrightability is thus a fact-specific, case-by-case exercise. … Certainly, sorting out what is and isn’t subject to GPLv2 in Bionic would require at least a file-by-file, and most likely line-by-line, analysis of Bionic — a daunting task[.]
Of course, in that statement, Naughton makes the mistake of subtly including an assumption in the hypothesis: he fails to acknowledge clearly that it's entirely possible the set of GPLv2-covered work found in Bionic could be the empty set; he hasn't shown it's not the empty set (even notwithstanding his very cursory analysis of a few files).

Yet, even though Naughton admits full analysis (that he hasn't done) is necessary, he nevertheless later makes sweeping conclusions:

The 750 Linux kernel header files … define a complex overarching structure, an application programming interface, that is thoughtfully and cleverly designed, and almost assuredly protected by copyright.
Again, this is a hypothesis, that would have be tested and proved with evidence generated by the careful line-by-line analysis Naughton himself admits is necessary. Yet, he doesn't acknowledge that fact in his conclusions, leaving his readers (and IMO he's expecting to dupe lots of readers unsophisticated on these issues) with the impression he's shown something he hasn't. For example, one of my first questions would be whether or not Bionic uses only parts of Linux headers that are required by specification to write POSIX programs, a question that Naughton doesn't even consider.

Finally, Naughton moves from the merely shoddy analysis to completely alarmist speculation with:

But if Google is right, if it has succeeded in removing all copyrightable material from the Linux kernel headers, then it has unlocked the Linux kernel from the restrictions of GPLv2. Google can now use the “clean” Bionic headers to create a non-GPL’d fork of the Linux kernel, one that can be extended under proprietary license terms. Even if Google does not do this itself, it has enabled others to do so. It also has provided a useful roadmap for those who might want to do the same thing with other GPLv2-licensed [sic] programs, such as databases.

If it turns out that Google has succeeded in making sure that the GPLv2 does not apply to Bionic, then Google's success is substantially more narrow. The success would be merely the extraction of the non-copyrightable facts that any C library needs to know about Linux to make a binary run when Linux happens to be the kernel underneath. Now, it should be duly noted that there already exist two libraries under the LGPL that have already implemented that (namely, glibc, and uClibc — the latter of which Naughton's cursory research apparently didn't even turn up). As it stands, anyone who wants to write user-space applications on a Linux-based system already can; there are multiple C library choices available under the weak copyleft license, LGPL. Google, for its part, believes they've succeed at is to make a permissively licensed third alternative, which is an outcome that would be no surprise to us who have seen something like it done twice before.

In short, everyone opining here seems to be conflating a lot of issues. There are many ways to interface with Linux. Many people, including me, believe quite strongly that there is no way to make a subprogram in kernel space (such as a device driver) without the terms of the GPLv2 applying to it. But writing a device driver is a specialized task that's very different from what most Linux users do. Most developers who “use Linux” — by which they typically mean write a user space program that runs on a GNU/Linux operating system — have (at most) weak copyleft (LGPL) terms to follow due to glibc or uClibc. I admit that I sometimes feel chagrin that proprietary applications can be written for GNU/Linux (and other Linux-based) systems, but that was a strategic decision that RMS made (correctly) at the start of the GNU project one that the Linux project, for its part, has also always sought.

I'm quite sure no one — including hard-core copyleft advocates like me — expects nor seeks the GPLv2 terms to apply to programs that interface with Linux solely as user-space programs that runs on an operating system that uses Linux as its kernel. Thus, I'd guess that even if it turned out that Google made some mistakes in this regard for Bionic, we'd all work together to rectify those mistakes so that the outcome everyone intended could occur.

Moreover, to compare the specifics of this situation to other types of so-called “copyleft circumvention techniques” is just link-baiting that borders on trolling. Google wasn't seeking to circumvent the GPL at all; they were seeking to write and/or adapt a permissively licensed library that replaced an LGPL'd one. I'm of course against that task on principle (I think Google should have just used glibc and/or uClibc and required LGPL-compliance by applications). But, to deny that it's possible to rewrite a C library for Linux under a license that isn't GPLv2 would also imply immediately the (incorrect) conclusion that uClibc and glibc are covered by the GPLv2, and we are all quite sure they aren't; even Naughton himself admits that (regarding glibc).

Google may have erred; no one actually knows for sure at this time. But the task they sought to do has been done before and everyone intended it to be permitted. The worst mistake of which we might ultimately accuse Google is inadvertently taking a copyright-infringing short-cut. If someone actually does all the research to prove that Google did so, I'd easily offer a 1,000-to-1 bet to anyone that such a copyright infringement could be cleared up easily, that Bionic would still work as a permissively licensed C library for Linux, and the implications of the whole thing wouldn't go beyond: “It's possible to write your own C library for Linux that isn't covered by the GPLv2” — a fact which we've all known for a decade and a half anyway.

Update (2011-03-20): Many people, including slashdot, have been linking to this comment by RMS on LKML about .h files. It's important to look carefully at what RMS is saying. Specifically, RMS says that sometimes #include'ing a .h file creates a copyright derivative work, and sometimes it doesn't; it depends on the details. Then, RMS goes to talk on some rules of thumb that can help determine the outcome of the question. The details are what matters; and those are, as I explain in the main post above, what requires careful analysis done jointly and in close collaboration between a developer and a lawyer. There is no general rule of thumb that always immediately leads one to the right answer on this question.


Ditching Copyleft to Compete with a Fork?   


I was disturbed today to read that Oracle will seek to relicense all OpenOffice code under the Apache-2.0 license and move OpenOffice into the Apache Software Foundation.

I've written recently about how among the permissive licenses, my favorite is clearly the Apache License 2.0. However, I think that one should switch from a copyleft license to a permissive one only in rare circumstances and with the greatest of care.

Obviously, in this case, I oppose Oracle's relicense of under Apache-License-2.0. It is probably obvious why I feel that way, but I shall explain nonetheless, just in case. I'm going to mostly ignore the motives for doing so, which I think are obvious: Oracle (and IBM, who are quoted in support of this move) for their own reasons don't like The Document Foundation fork (LibreOffice) of This is a last-ditch effort by IBM and Oracle to thwart the progress of that fork, which has been reported as quite successful and many distributions have begun to adopt LibreOffice. (Even non-software sites sites like Metafilter have users discussing changing to LibreOffice .)

Anyway, as you might suspect, I'm generally against the idea of relicensing from a copyleft to a non-copyleft license in most situations. In fact, I generally take the stance that you should go with the strictest copyleft possible unless there's a strong reason not to. This is well-argued in RMS' essay on the LGPL itself, and I won't repeat those arguments here. Frankly, if I were picking a license for and/or LibreOffice from start, I'd pick AGPLv3-or-later, because of the concern that it could be turned into a Google Docs-like web service. But, what I'd do is obviously irrelevant. was put out under LGPLv3, and that was its license for some time. LGPL was presumably chosen to allow proprietary plugins to That might be useful and perhaps a reasonable trade-off decision, since one of the goals of the project is to woo users away from Microsoft's tools which presumably permit proprietary plugins too. Thus, an argument can be made that the situation is vaguely analogous to the C Library situation that inspired LGPL's creation.

But, what does a change from a weak copyleft like LGPLv3 to a fully permissive license do? Specifically, it allows not only proprietary plugins using the's defined plugin interfaces, but also for any sort of plugin that reaches into code in any way. Even worse, a permissive license allows for direct integration of into larger proprietary systems that might offer other desktop suite applications hitherto unimplemented in Free Software.

It's my belief that this license change, if successful in its goals, may help foster a bit of a tragedy of the commons for the core codebase. The codebase is already well known for being somewhat unwieldy and time-consuming to learn. Those who take the time to learn it, but who aren't Free Software enthusiasts, may quickly decide that it's better for them to use that rare knowledge to proprietarize the codebase rather than contribute to the public Free Software versions. The LGPLv3 currently keeps such developers “honest”; the Apache-License-2.0 will not.

Perhaps most importantly, the major consequence to consider is the the ultimate impact on the LibreOffice fork. To consider that impact, we have to look at the instigators of the relicense. IBM and Oracle both now will have a vested interest in maintaining a “barely adequate” public Apache-2.0-licensed codebase while keeping the best stuff in their proprietary versions. has actually always suffered from this very tragedy, but historically the regime was held up by mandatory copyright assignment to Oracle (and a semi-exclusive proprietary license from Oracle to IBM) rather than a permissive license. On the surface, then, this seems subtly like the kind of improvement I've written about before — namely — at least a public permissive license puts everyone on equal footing, whereas copyleft with a single for-profit proprietary relicensor gives special powers to the for-profit.

And, frankly, but for the existence of LibreOffice, I think I probably would have concluded that an Apache-2.0 relicense of was the lesser of two evils. However, LibreOffice's very existence and momentum turns those two evils into a false dichotomy. Specifically, there's now a third alternative: LibreOffice is a vibrant, open, easy-to-contribute-to, non-copyright-assigned LGPLv3'd codebase now. In that community, the LGPLv3 is the shared and equal agreement; no one has special rights to the code outside of LibreOffice's license. Free Software communities, in fact, always rely on an equitable shared agreement to assure good governance and project health.

Actually, relicensing part of the codebase out from under LibreOffice may actually be the most insidious attack Oracle and IBM could make on the project. Unilateral relicense is the single most destabilizing action you can take against a Free Software community, particularly if the relicense comes from wholly outside the community. Indeed, in my time at various copyright-holding Free Software organizations, I've seen situations where I was helping support a relicensing effort by the copyright holder. In every case, I've seen leaders who could have done a unilateral relicense chose to first consult the community before taking the action to ensure that there weren't any key community members who dissented. Just because you have the right to do something doesn't mean it's the correct action to take, and Free Software leaders know this well; that's why they very rarely act unilaterally on anything.

Meanwhile, in this situation today, we have a copyright holder (Oracle) whose primary goal in relicensing is, in fact, to cause the outcome that Free Software leaders seek to avoid; Oracle is relicensing to undermine a successful Free Software project that relies on its copyrighted code.

Nevertheless, I'm not too worried. I believe the LibreOffice community is strong and grows stronger every day. Since their license is LGPLv3, and they continue to add new code, the fact that most of the underlying code is suddenly available under Apache-2.0 license may matter a lot today, but it will matter less and less with each passing day of new commits under LGPLv3.

In fact, I hope the LibreOffice folks will use this relicense to their advantage. Specifically, I suggest they take an Apache-2.0 license of Oracle's code, which is an LGPLv3-compatible license, and relicense the whole project to LGPLv3-or-later0, so they have an easy way (years from now) to switch to LGPLv4, GPLv3, or AGPLv4 if they want to. (BTW, they already have an easy way to switch to GPLv3, since LGPLv3 permits this, and even to AGPLv3 thereafter (via GPLv3§13).)

Note finally that there is one other benefit of this action: according to TDF, some code that had previously been proprietary is coming with the Apache-2.0-licensed code dump. This alone may make it all worthwhile, and given the points I make above, I think the ultimate outcome, long term, will be all positive for the LGPL'd LibreOffice codebase.

(I'd like note finally that I'm not the only one to point out that Oracle's action would be different if LibreOffice didn't exist. Sean Michael Kerner said something similar.)

Update (on 2011-06-02): This comment on the Apache/OpenOffice issue by my friend Jeremy Allison was so well written that I felt compelled to update this blog post with it. He's made the comment on the blog of Rob Wier, who appears to be IBM's pointman for handling the politics of this situation.

If you take a careful look linguistically at what IBM's been saying about this situation, I hope you'll notice how politically manipulative it is. Unlike Oracle, which acts like a big gorilla that browbeats their customers, IBMers are a politically aware group of folks deeply skilled at rhetoric. The Free Software community should feel honored that IBM sends skilled diplomats to deal with us, but we shouldn't be fooled by what they are saying. As Jeremy points out, this is about copyleft vs. non-copyleft. We've got a vibrant, weak-copyleft community going now, and IBM and Oracle are making a final attempt to disrupt it.

For example, look carefully at how Wier uses the verb “blessed” to refer to FSF's recent announcement of its licensing recommendations. Of course, he quotes FSF out of context, and doesn't quote this part of FSF's recommendations:

When you contribute to an existing project, you should usually release your modified versions under the same license as the original work. It's good to cooperate with the project's maintainers, and using a different license for your modifications often makes that cooperation very difficult. You should only do that when there is a strong reason to justify it.

The existing license of and LibreOffice is LGPLv3. Oracle, in coordination with IBM, unilaterally changed the license out from under the community, rather than cooperating with the existing licensing. Oracle of course had the legal right to do so as copyright holder, but this was an act in conflict with the existing community in a moral sense, even if, again, it was a permissible act under the OO.o “community” guidelines.

0 Update on 2011-06-05: idoric pointed out to me that the LibreOffice website says it's LGPLv3-or-later. The LibreOffice website is a bit misleading on in some places on this point. idoric later pointed out that the better description is on the LibreOffice Get Involved for Developers page, which makes it clear that the effective license of Libreoffice is LGPLv3, but the community has chosen (LGPLv3-or-later|MPL) for new contributions. I don't really understand why the dual license with MPL makes sense; I presume it's there to help out pro-software-patent companies that might want to avoid the patent provisions of LGPLv3. It's a shame really, so in some ways, I'm slightly glad that LibreOffice is stuck on LGPLv3 as the effective license, even if it is LGPLv3-only. That brings me back to what I suggest in the main body of the post: relicensing the Apache-2.0 license code from Oracle as LGPLv3-or-later would presumably allow the effective license of the whole codebase to be LGPLv3-or-later.


Project Harmony (and “Next Generation Contributor Agreements”) Considered Harmful   


Update on 2014-06-10:While this article is about a specific series of attempts to “unify” CLAs and ©AAs into a single set of documents, the issues raised below cover the gamut of problems that are encountered in many CLAs and ©AAs in common use today in FLOSS projects. Even though it appears that both Project Harmony and its reincarnation Next Generation Contributor Agreements have both failed, CLAs and ©AAs are increasing in popularity among FLOSS projects, and developers should begin action to oppose these agreements for their projects.

Update on 2013-09-05: Project Harmony was recently relaunched under the name the Next Generation of Contributor Agreements. AFAICT, it's been publicly identified as the same initiative, and its funding comes from the same person. I've verified that everything I say below still applies to their current drafts available from the Contributor Agreements project. I also emailed this comments to the leaders of that project before it started, but they wouldn't respond to my policy questions.

Much advertising is designed to convince us to buy or use of something that we don't need. When I hear someone droning on about some new, wonderful thing, I have to worry that these folks are actually trying to market something to me.

Very soon, you're likely to see a marketing blitz for this thing called Project Harmony (which just released its 1.0 version of document templates). Even the name itself is marketing: it's not actually descriptive, but is so named to market a “good feeling” about the project before even knowing what it is. (It's also got serious namespace collision, including with a project already in the software freedom community.)

Project Harmony markets itself as fixing something that our community doesn't really consider broken. Project Harmony is a set of document templates, primarily promulgated and mostly drafted by corporate lawyers, that entice developers to give control of their software work over to companies.

My analysis below is primarily about how these agreements are problematic for individual developers. An analysis of the agreements in light of companies or organizations using them between each other may have the same or different conclusions; I just haven't done that analysis in detail so I don't know what the outcome is.

[ BTW, I'm aware that I've failed to provide a TL;DR version of this article. I tried twice to write one and ultimately decided that I can't. Simply put, these issues are complex, and I had to draw on a decade of software freedom licensing, policy, and organizational knowledge to fully articulate what's wrong with the Project Harmony agreements. I realize that sounds like a It was hard to write — it should be hard to read justification, but I just don't know how to summarize these Gordian problems in a pithy way. I nevertheless hope developers will take the time to read this before they sign a Project Harmony agreement, or — indeed — any CLA or ©AA. ]

Copyright Assignment That Lacks Real Assurances

First of all, about half of Project Harmony is copyright assignment agreements ( ©AAs). Assigning copyright completely gives the work over to someone else. Once the ©AA is signed, the work ceases to belong to the assignor. It's as if that work was done by the assignee. There is admittedly some value to copyright assignment, particularly if developers want to ensure that the GPL or other copyleft is enforced on their work and they don't have time to do it themselves. (Although developers can also designate an enforcement agent to do that on their behalf even if they don't assign copyright, so even that necessity is limited.)

One must immensely trust an assignee organization. Personally, I've only ever assigned some of my copyrights to one organization in my life: the Free Software Foundation, because FSF is the only organization I ever encountered that is institutionally committed to DTRT'ing with copyrights in a manner similar to my personal moral beliefs.

First of all, as I've written about before, FSF's ©AA make all sorts of promises back to the assignor. Second, FSF is institutionally committed to the GPL and enforcing GPL in a way that advances FSF's non-profit advocacy mission for software freedom. All of this activity fits my moral principles, so I've been willing to sign FSF's ©AAs.

Yet, I've nevertheless met many developers who refuse to sign FSF's ©AAs. While many of such developers like the GPL, they don't necessarily agree with the FSF's moral positions. Indeed, in many cases, developers are completely opposed to assigning copyright to anyone, FSF or otherwise. For example, Linus Torvalds, founder of Linux, has often stated on record that he never wanted to do copyright assignments, for several reasons: [he] think[s] they are nasty and wrong personally, and [he]'d hate all the paperwork, and [he] thinks it would actually detract from the development model.

Obviously, my position is not as radical as Linus'; I do think ©AAs can sometimes be appropriate. But, I also believe that developers should never assign copyright to a company or to an organization whose moral philosophy doesn't fit well with their own.

FSF, for its part, spells out its moral position in its ©AA itself. As I've mentioned elsewhere, and as Groklaw recently covered in detail, FSF's ©AA makes various legally binding promises to developers who sign it. Meanwhile, Project Harmony's ©AAs, while they put forward a few options that look vaguely acceptable (although they have problems of their own discussed below), make no such promises mandatory. I have often times pointed Harmony's drafters to the terms that FSF has proposed should be mandatory in any for-profit company's ©AA, but Harmony's drafters have refused to incorporate these assurances as a required part of Harmony's agreements. (Note that such assurances would still be required for the CLA options as well; see below for details why.)

Regarding ©AAs, I'd like to note finally that FSF does not require ©AAs for all GNU packages. This confusion is so common that I'd like to draw attention to it, even thought it's only a tangential point in this context. FSF's ©AA is only mandatory, to my knowledge, on those GNU packages where either (a) FSF employees developed the first versions or (b) the original developers themselves asked to assign copyright to FSF, upon their project joining GNU. In all other cases, FSF assignment is optional. Some GNU projects, such as GNOME, have their own positions regarding ©AAs that differ radically from FSF's. I seriously doubt that companies who adopt Project Harmony's agreement will ever be as flexible on copyright assignment as FSF, nor will any of the possible Project Harmony options be acceptable to GNOME's existing policy.

Giving Away Rights to Give Companies Warm Fuzzies?

Project Harmony, however, claims that the important part isn't its ©AA, but its Contributor License Agreement (CLA). To briefly consider the history of Free Software CLAs, note that the Apache CLA was likely the first CLA used in the Free Software community. Apache Software Foundation has always been heavily influenced by IBM and other companies, and such companies have generally sought the “warm fuzzies” of getting every contributor to formally assent to a complex legal document that asserts various assurances about the code and gives certain powers to the company.

The main point of a CLA (and a somewhat valid one) is to ensure that the developers have verified their right to contribute the code under the specified copyright license. Both the Apache CLA and Project Harmony's CLA go to great length and verbosity to require developers to agree that they know the contribution is theirs. In fact, if a developer signs one of these CLA's, the developer makes a formal contract with the entity (usually a for-profit company) that the developer knows for sure that the contribution is licensed under the specified license. The developer then takes on all liability if that fact is in any way incorrect or in dispute!

Of course, shifting away all liability about the origins of the code is a great big “warm fuzzy” for the company's lawyers. Those lawyers know that they can now easily sue an individual developer for breach of contract if the developer was wrong about the code. If the company redistributes some developer's code and ends up in an infringement suit where the company has to pay millions of dollars, they can easily come back and sue the developer0. The company would argue in court that the developer breached the CLA. If this possible outcome doesn't immediately worry you as an individual developer signing a Project Harmony CLA for your FLOSS contribution, it should.

“Choice of Law” & Contractual Arrangement Muddies Copyright Claims

Apache's CLA doesn't have a choice of law clause, which is preferable in my opinion. Most lawyers just love a “choice of law” clause for various reasons. The biggest reason is that it means the rules that apply to the agreement are the ones with which the lawyers are most familiar, and the jurisdiction for disputes will be the local jurisdiction of the company, not of the developer. In addition, lawyers often pick particular jurisdictions that are very favorable to their client and not as favorable to the other signers.

Unfortunately, all of Project Harmony's drafts include a “choice of law” clause1. I expect that the drafters will argue in response that the jurisdiction is a configuration variable. However, the problem is that the company decides the binding of that variable, which almost always won't be the binding that an individual developer prefers. The term will likely be non-negotiable at that point, even though it was configurable in the template.

Not only that, but imagine a much more likely scenario about the CLA: the company fails to use the outbound license they promised. For example, suppose they promised the developers it'd be AGPL'd forever (although, no such option actually exists in Project Harmony, as described below!), but then the company releases proprietarized versions. The developers who signed the CLA are still copyright holders, so they can enforce under copyright law, which, by itself, would allow the developers to enforce under the laws in whatever jurisdiction suits them (assuming the infringement is happening in that jurisdiction, of course).

However, by signing a CLA with a “choice of law” clause, the developers agreed to whatever jurisdiction is stated in that CLA. The CLA has now turned what would otherwise be a mundane copyright enforcement action operating purely under the developer's local copyright law into a contract dispute between the developers and the company under the chosen jurisdiction's laws. Obviously that agreement might include AGPL and/or GPL by reference, but the claim of copyright infringement due to violation of GPL is now muddied by the CLA contract that the developers signed, wherein the developers granted some rights and permission beyond GPL to the company.

Even worse, if the developer does bring action in a their own jurisdiction, their own jurisdiction is forced to interpret the laws of another place. This leads to highly variable and confusing results.

Problems for Individual Copyright Enforcement Against Third-Parties

Furthermore, even though individual developers still hold the copyrights, the Project Harmony CLAs grant many transferable rights and permissions to the CLA recipient (again, usually a company). Even if the reasons for requiring that were noble, it introduces a bundle of extra permissions that can be passed along to other entities.

Suddenly, what was once a simple copyright enforcement action for a developer discovering a copyleft violation becomes a question: Did this violating entity somehow receive special permissions from the CLA-collecting entity? Violators will quickly become aware of this defense. While the defense may not have merit (i.e., the CLA recipient may not even know the violator), it introduces confusion. Most legal proceedings involving software are already confusing enough for courts due to the complex technology involved. Adding something like this will just cause trouble and delays, further taxing our already minimally funded community copyleft enforcement efforts.

Inbound=Outbound Is All You Need

Meanwhile, the whole CLA question actually is but one fundamental consideration: Do we need this? Project Harmony's answer is clear: its proponents claim that there is mass confusion about CLAs and no standardization, and therefore Project Harmony must give a standard set of agreements that embody all the options that are typically used.

Yet, Project Harmony has purposely refused to offer the simplest and most popular option of all, which my colleague Richard Fontana (a lawyer at Red Hat who also opposes Project Harmony) last year dubbed inbound=outbound. Specifically, the default agreement in the overwhelming majority of FLOSS projects is simply this: each contributor agrees to license each contribution using the project's specified copyright license (or a license compatible with the project's license).

No matter what way you dice Project Harmony, the other contractual problems described above make true inbound=outbound impossible because the CLA recipient is never actually bound formally by the project's license itself. Meanwhile, even under its best configuration, Project Harmony can't adequately approximate inbound=outbound. Specifically, Project Harmony attempts to limit outbound licensing with its § 2.3 (called Outbound License). However, all the copyleft versions of this template include a clause that say: We [the CLA recipient] agree to license the Contribution … under terms of the … licenses which We are using on the Submission Date for the Material. Yet, there is no way for the contributor to reliably verify what licenses are in use privately by the entity receiving the CLA. If the entity is already engaged in, for example, a proprietary relicensing business model at the Submission Date, then the contributor grants permission for such relicensing on the new contribution, even if the rest of § 2.3 promises copyleft. This is not a hypothetical: there have been many cases where it was unclear whether or not a company was engaged in proprietary relicensing, and then later it was discovered that they had been privately doing so for years. As written, therefore, every configuration of Project Harmony's § 2.3 is useless to prevent proprietarization.

Even if that bug were fixed, the closest Project Harmony gets to inbound=outbound is restricting the CLA version to “FSF's list of ‘recommended copyleft licenses’”. However, this category makes no distinction between the AGPL and GPL, and furthermore ultimately grants FSF power over relicensing (as FSF can change its list of recommended copylefts at will). If the contributors are serious about the AGPL, then Project Harmony cannot assure their changes stay AGPL'd. Furthermore, contributors must trust the FSF for perpetuity, even more than already needed in the -or-later options in the existing FSF-authored licenses. I'm all for trusting the FSF myself in most cases. However, because I prefer plain AGPLv3-or-later for my code, Project Harmony is completely unable to accommodate my licensing preferences to even approximate an AGPL version of inbound=outbound (even if I ignored the numerous problems already discussed).

Meanwhile, the normal, mundane, and already widely used inbound=outbound practice is simple, effective, and doesn't mix in complicated contract disputes and control structures with the project's governance. In essence, for most FLOSS projects, the copyright license of the project serves as the Constitution of the project, and doesn't mix in any other complications. Project Harmony seeks to give warm fuzzies to lawyers at the expense of offloading liability, annoyance, and extra hoop-jumping onto developers.

Linux Hackers Ingeniously Trailblazed inbound=outbound

Almost exactly 10 years ago today, I recall distinctly attending the USENIX 2001 Linux BoF session. At that session, Ted Ts'o and I had a rather lively debate; I claimed that FSF's ©AA assured legal certainty of the GNU codebase, but that Linux had no such assurance. (BTW, even I was confused in those days and thought all GNU packages required FSF's ©AA.) Ted explained, in his usual clear and bright manner, that such heavy-handed methods shouldn't be needed to give legal certainty to the GPL and that the Linux community wanted to find an alternative.

I walked away skeptically shaking my head. I remember thinking: Ted just doesn't get it. But I was wrong; he did get it. In fact, many of the core Linux developers did. Three years to the month after that public conversation with Ted, the Developer's Certificate of Origin (DCO) became the official required way to handle the “CLA issue” for Linux and it remains the policy of Linux today. (See item 12 in Linux's Documentation/SubmittingPatches file.)

The DCO, in fact, is the only CLA any FLOSS project ever needs! It implements inbound=outbound in a simple and straightforward way, without giving special powers over to any particular company or entity. Developers keep their own copyright and they unilaterally attest to their right to contribute and the license of the contribution. (Developers can even sign a ©AA with some other entity, such as the FSF, if they wish.) The DCO also gives a simple methodology (i.e., the Signed-off-by: tag) for developers to so attest.

I admit that I once scoffed at the (what I then considered naïve) simplicity of the DCO when compared to FSF's ©AA. Yet, I've been since convinced that the Linux DCO clearly accomplishes the primary job and simultaneously fits how most developers like to work. ©AA's have their place, particularly when the developers find a trusted organization that aligns with their personal moral code and will enforce copyleft for them. However, for CLAs, the Linux DCO gets the important job done and tosses aside the pointless and pro-corporate stuff.

Frankly, if I have to choose between making things easy for developers and making them easy for corporate lawyers, I'm going to chose the former every time: developers actually write the code; while, most of the time, company's legal departments just get in our way. The FLOSS community needs just enough CYA stuff to get by; the DCO shows what's actually necessary, as opposed to what corporate attorneys wish they could get developers to do.

What about Relicensing?

Admittedly, Linux's DCO does not allow for relicensing wholesale of the code by some single entity; it's indeed the reason a Linux switch to GPLv3 will be an arduous task of public processes to ensure permission to make the change. However, it's important to note that the Linux culture believes in GPLv2-only as a moral foundation and principle of their community. It's not a principle I espouse; most of my readers know that my preferred software license is AGPLv3-or-later. However, that's the point here: inbound=outbound is the way a FLOSS community implements their morality; Project Harmony seeks to remove community license decision-making from most projects.

Meanwhile, I'm all for the “-or-later” brand of relicensing permission; GPL, LGPL and AGPL have left this as an option for community choice since GPLv1 was published in late 1980s. Projects declare themselves GPLv2-or-later or LGPLv3-or-later, or even (GPLv1-or-later|Artistic) (ala Perl 5) to identify their culture and relicensing permissions. While it would sometimes be nice to have a broad post-hoc relicensing authority, the price for that's expensive: abandonment of community clarity regarding what terms define their software development culture.

An Anti-Strong-Copyleft Bias?

Even worse, Project Harmony remains biased against some of the more fine-grained versions of copyleft culture. For example, Allison Randal, who is heavily involved with Project Harmony, argued on Linux Outlaws Episode 204 that Most developers who contribute under a copyleft license — they'd be happy with any copyleft license — AGPL, GPL, LGPL. Yet there are well stated reasons why developers might pick GPL rather than LGPL. Thus, giving a for-profit company (or non-profit that doesn't necessarily share the developers' values) unilateral decision-making power to relicense GPL'd works under LGPL or other weak copyleft licenses is ludicrous.

In its 1.0 release, Project Harmony attempted to add a “strong copyleft only” option. It doesn't actually work, of course, for the various reasons discussed in detail above. But even so, this solution is just one option among many, and is not required as a default when a project is otherwise copylefted.

Finally, it's important to realize that the GPLv3, AGPLv3, and LGPLv3 already offer a “proxy option”; projects can name someone to decide the -or-later question at a later time. So, for those projects that use any of the set { LGPLv3-only, AGPLv3-only, GPLv3-only, GPLv2-or-later, GPLv1-or-later, or LGPLv2.1-or-later }, the developers already have mechanisms to move to later versions of the license with ease — by specifying a proxy. There is no need for a CLA to accomplish that task in the GPL family of licenses, unless the goal is to erode stronger copylefts into weaker copylefts.

This is No Creative Commons, But Even If It Were, Is It Worth Emulation?

Project Harmony's proponents love to compare the project to Creative Commons, but the comparison isn't particularly apt. Furthermore, I'm not convinced the FLOSS community should emulate the CC license suite wholesale, as some of the aspects of the CC structure are problematic when imported back into FLOSS licensing.

First of all, Larry Lessig (who is widely considered a visionary) started the CC licensing suite to bootstrap a Free Culture movement that modeled on the software freedom movement (which he spent a decade studying). However, Lessig made some moral compromises in an attempt to build a bridge to the “some rights reserved” mentality. As such, many of the CC licenses — notably those that include the non-commercial (NC) or no-derivatives (ND) terms — are considered overly restrictive of freedom and are therefore shunned by Free Culture activists and software freedom advocates alike.

Over nearly decade, such advocates have slowly begun to convince copyright holders to avoid CC's NC and ND options, but CC's own continued promulgation of those options lend them undue legitimacy. Thus, CC and Project Harmony make the same mistake: they act amorally in an attempt to build a structure of licenses/agreements that tries to bridge a gulf in understanding between a FaiF community and those only barely dipping their toe in that community. I chose the word amoral, as I often do, to note a situation where important moral principles exist, but the primary actors involved seek to remove morality from the considerations under the guise of leaving decision-making to the “magic of the marketplace”. Project Harmony is repeating the mistake of the CC license suite that the Free Culture community has spent a decade (and counting) cleaning up.


Please note that IANAL and TINLA. I'm just a community- and individual-developer- focused software freedom policy wonk who has some grave concerns about how these Project Harmony Agreements operate. I can't give you a fine-grained legal analysis, because I'm frankly only an amateur when it comes to the law, but I am an expert in software freedom project policy. In that vein — corporate attorney endorsements notwithstanding — my opinion is that Project Harmony should be abandoned entirely.

In fact, the distinction between policy and legal expertise actually shows the root of the problem with Project Harmony. It's a system of documents designed by a committee primarily comprised of corporate attorneys, yet it's offered up as if it's a FLOSS developer consensus. Indeed, Project Harmony itself was initiated by Amanda Brock, a for-profit corporate attorney for Canonical, Ltd, who is remains involved in its drafting. Canonical, Ltd. later hired Mark Radcliffe (a big law firm attorney, who has defended GPL violators) to draft the alpha revisions of the document, and Radcliffe remains involved in the process. Furthermore, the primary drafting process was done secretly in closed meetings dominated by corporate attorneys until the documents were almost complete; the process was not made publicly open to the FLOSS community until April 2011. The 1.0 documents differ little from the drafts that were released in April 2011, and thus remain to this day primarily documents drafted in secrecy by corporate attorneys who have only a passing familiarity with software freedom culture.

Meanwhile, I've asked Project Harmony's advocates many times who is in charge of Project Harmony now, and no one can give me a straight answer. One is left to wonder who decides final draft approval and what process exists to prevent or permit text for the drafts. The process which once was in secrecy appears to be now in chaos because it was opened up too late for fundamental problems to be resolved.

A few developers are indeed actively involved in Project Harmony. But Project Harmony is not something that most developers requested; it was initiated by companies who would like to convince developers to passively adopt overreaching CLAs and ©AAs. To me, the whole Project Harmony process feels like a war of attrition to convince developers to accept something that they don't necessarily want with minimal dissent. In short, the need for Project Harmony has not been fully articulated to developers.

Finally, I ask, what's really broken here? The industry has been steadily and widely adopting GNU and Linux for years. GNU, for its part, has FSF assignments in place for much of its earlier projects, but the later projects (GNOME, in particular) have either been against both ©AA's and CLA's entirely, or are mostly indifferent to them and use inbound=outbound. Linux, for its part, uses the DCO, which does the job of handling the urgent and important parts of a CLA without getting in developers' way and without otherwise forcing extra liabilities onto the developers and handing over important licensing decisions (including copyleft weakening ones) to a single (usually for-profit) entity.

In short, Project Harmony is a design-flawed solution looking for a problem.

Further Reading

0Project Harmony advocates will likely claim to their § 5, “Consequential Damage Waiver” protects developers adequately. I note that it explicitly leaves out, for example, statutory damages for copyright infringement. Also, some types of damages cannot be waived (which is why that section shouts at the reader TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW). Note my discussion of jurisdictions in the main text of this article, and consider the fact that the CLA recipient will obviously select a jurisdiction where the fewest possible damages can be waived. Finally, note that the OR US part of that § 5 is optionally available, and surely corporate attorneys will use it, which means that if they violate the agreement, there's basically no way for you to get any damages from them, even if they their promise to keep the code copylefted and fail.

1Note: Earlier versions of this blog post conflated slightly “choice of venue” with “choice of law”. The wording has been cleared up to address this problem. Please comment or email me if you believe it's not adequately corrected.


FaiFCast Release, and Submit to FOSDEM Legal & Policy Issues DevRoom   


Today Karen Sandler and I released Episode 0x1E of the Free as in Freedom oggcast (available in ogg and mp3 formats). There are two important things discussed on that oggcast that I want to draw your attention to:

Submit a proposal for the Legal & Policy Issues DevRoom CFP

Tom Marble, Richard Fontana, Karen Sandler, and I are coordinating the Legal and Policy Issues DevRoom at FOSDEM 2012. The Call for Participation for the DevRoom is now available. I'd like to ask anyone reading this blog post who has an interest in policy and/or legal issues related to software freedom to submit a talk by Friday 30 December 2011, by emailing <>.

We only have about six slots for speakers (it's a one-day DevRoom), so we won't be able to accept all proposals. I just wanted to let everyone know that so you don't flame me if you submit and get rejected. Meanwhile, note that our goal is to avoid the “this is what copyrights, trademarks and patents are” introductory talks. Our focus is on complex issues for those already informed about the basics. We really felt that the level of discourse about legal and policy issues at software freedom conferences needs to rise.

There are, of course, plenty of secret membership clubs 0, even some with their own private conferences, where these sorts of important issues are discussed. I personally seek to move high-level policy discussion and debate out of the secret “old-boys” club backrooms and into a public space where the entire software freedom community can discuss openly important legal and policy questions in the community. I hope this DevRoom is a first step in that direction!

Issues & Questions List for the Software Freedom Non-Profits Debate

I've made reference recently to debates about the value of non-profit organizations for software freedom projects. In FaiFCast 0x1E, Karen and I discuss the debate in depth. As part of that, as you'll see in the show notes, I've made a list of issues that I think were fully conflated during the recent debates. I can't spare the time to opine in detail on them right now (although Karen and I do a bit of that in the oggcast itself), but I did want to copy the list over here in my blog, mainly to list them out as issues worth thinking about in a software freedom non-profit:

  • Should a non-profit home decide what technical infrastructure is used for a software freedom project? And if so, what should it be?
  • If the non-profit doesn't provide technological services, should non-profits allow their projects to rely on for-profits for technological or other services?
  • Should a non-profit home set political and social positions that must be followed by the projects? If so, how strictly should they be enforced?
  • Should copyrights be held by the non-profit home of the project, or with the developers, or a mix of the two?
  • Should the non-profit dictate licensing requirements on the project? If so, how many licenses and which licenses are acceptable?
  • Should a non-profit dictate strict copyright provenance requirements on their projects? If not, should the non-profit at least provide guidelines and recommendations?

This list of questions is far from exhaustive, but I think it's a pretty good start.

0 Admittedly, I've got a proverbial axe to grind about these secretive membership-only groups, since, for nearly all of them, I'm persona non grata. My frustration level in this reached a crescendo when, during a session at LinuxCon Europe recently, I asked for the criteria to join one such private legal issues discussions group, and I was told the criteria themselves were secret. I pointed out to the coordinators of the forum that this wasn't a particularly Free Software friendly way to run a discussion group, and they simply changed the subject. My hope is that this FOSDEM DevRoom can be a catalyst to start a new discussion forum for legal and policy issues related to software freedom that doesn't have this problem.

BTW, just to clarify: I'm not talking about FLOSS Foundations as one of these secretive, members-only clubs. While the FLOSS Foundations main mailing list is indeed invite-only, it's very easy to join and the only requirement is: “if you repost emails from this list publicly, you'll probably be taken off the mailing list”. There is no “Chatham House Rule” or other silly, unenforceable, and spend-inordinate-amount-of-times-remembering-how-to-follow rules in place for FLOSS Foundations, but such silly rulesets are now common with these other secretive legal issues meeting groups.

Finally, I know I haven't named publicly the members-only clubs I'm talking about here, and that's by design. This is the first time I've mentioned them at all in my blog, and my hope is that they'll change their behaviors soon. I don't want to publicly shame them by name until I give them a bit more time to change their behaviors. Also, I don't want to inadvertently promote these fora either, since IMO their very structure is flawed and community-unfriendly.

Update: Some have claimed incorrectly that the text in the footnote above somehow indicates my unwillingness to follow the Chatham House Rule (CHR). I refuted that on, noting that the text above doesn't say that, and those who think it does have simply misunderstood. My primary point (which I'll now state even more explicitly) is that CHR is difficult to follow, particularly when it is mis-applied to a mailing list. CHR is designed for meetings, which have a clear start time and a finish time. Mailing lists aren't meetings, so the behavior of CHR when applied to a mailing list is often undefined.

I should furthermore note that people who have lived under CHR for a series of meetings also have similar concerns as mine. For example, Allison Randal, who worked under CHR on Project Harmony noted:

The group decided to adopt Chatham House Rule for our discussions. … At first glance it seems quite sensible: encourage open participation by being careful about what you share publicly. But, after almost a year of working under it, I have to say I’m not a big fan. It’s really quite awkward sometimes figuring out what you can and can’t say publicly. I’m trying to follow it in this post, but I’ve probably missed in spots. The simple rule is tricky to apply.

I agree with Allison.


Cutting Through The Anti-Copyleft Political Ruse   


I'd like to thank Harald Welte for his reasoned and clear blog post about GPL enforcement which I hope helps to clear up some of the confusions that I also wrote about recently.

Harald and I appear to agree that all enforcement actions should request, encourage, and pressure companies toward full FLOSS compliance. Our only disagreement, therefore, is on a minor strategy point. Specifically, Harald believes that the “reinstatement of rights lever” shouldn't be used to require compliance on all FLOSS licenses when resolving a violation matter, and I believe such use of that lever is acceptable in some cases. In other words, Harald and I have only a minor disagreement on how aggressively a specific legal tools should be utilized. (I'd also note that given Harald's interpretation of German law, he never had the opportunity to even consider using that tool, whereas it's always been a default tool in the USA.) Anyway, other than this minor side point, Harald and I appear to otherwise be in full in agreement on everything else regarding GPL enforcement.

Specifically, one key place where Harald and I are in total agreement is: copyright holders who enforce should approve all enforcement strategies. In every GPL enforcement action that I've done in my life, I've always made sure of that. Indeed, even while I'm a very minor copyright holder in BusyBox (just a few patches), I still nevertheless defer to Erik Andersen (who holds a plurality of the BusyBox copyrights) and Denys Vlasenko (who is the current BusyBox maintainer) about enforcement strategy for BusyBox.

I hope that Harald's post helps to end this silly recent debate about GPL enforcement. I think the overflowing comment pages can be summarized quite succinctly: some people don't like copyleft and don't want it enforced. Others disagree, and want to enforce. I've written before that if you support copyleft, the only logically consistent position is to also support enforcement. The real disagreement here, thus, is one about whether or not people like copyleft: that's an age-old debate that we just had again.

However, the anti-copyleft side used a more sophisticated political strategy this time. Specifically, copyleft opponents are attempting to scapegoat minor strategy disagreements among those who do GPL enforcement. I'm grateful to Harald for cutting through that ruse. Those of us that support copyleft may have minor disagreements about enforcement strategy, but we all support GPL enforcement and want to see it continue. Copyleft opponents will of course use political maneuvering to portray such minor disagreements as serious policy questions. Copyleft opponents just want to distract the debate away from the only policy question that matters: Is copyleft a good force in the world for software freedom? I say yes, and thus I'm going to keep enforcing it, until there are no developers left who want to enforce it.


GPL Violations Are Still Pretty Common, You Know?   


As I've written about before, I am always amazed when suddenly there is widespread interest in, excitement over, and focus on some particular GPL violation. I've spent most of my adult life working on copyleft compliance issues, so perhaps I've got an overly unique perspective. It's just that I've seen lots of GPL violations every single day since the late 1990s. Even now, copyleft compliance remains a regular part of my monthly work. Even though it's now only one task among many that I work on every day, I'm still never surprised nor shocked by some violation.

When some GPL violation suddenly becomes a “big story”, it reminds me of celebrity divorces. There are, of course, every single day, hundreds (maybe even thousands) of couples facing the conclusion that their marriage has ended. It's a tragedy for their families, and they'll spend years recovering. The divorce impacts everyone they know: both their families, and all their friends, too. Everyone's life who touches the couple is impacted in some way or other.

Of course, the same is true personally for celebrities when they divorce. The weird thing is, though, that people who don't even know these celebrities want to read about the divorce and know the details. It's exciting because the media tells us that we really want to know all the details and follow the drama every step of the way. It's disturbing that our culture sympathizes more with the pain of the rich and famous than the pain of our everyday neighbors.

Like divorce, copyleft violations are very damaging, but failure to comply with the copyleft licenses impacts three specific sets of people who directly touch the issue: the people whose copyright are infringed, the people who infringed the copyrights, and the people who received infringing articles. Everyone else is just a spectator0.

That said, my heart goes out to ever user who is sold software that they can't study, improve and share. I'm doubly concerned when those people were legally entitled to those rights, and an infringer snatched them away by failing to comply with copyleft licenses. I also have great sympathy for the individual copyright holders who licensed their works under GPL, yet find many infringers ignoring the rather simple and reasonable requirements of GPL.

But, I don't think gawking has any value. My biggest post-mortem complaint about SCO was not the FUD: that was obviously wrong and we knew the community would prevail. The constant gawking took away time that we could have spent writing more Free Software and doing good work in the software freedom community. So, from time to time, I like to encourage everyone to avoid gawking. (Unless, of course, you're doing it with the GNU implementation of AWK. :)

So, when you read GPL violation stories, even when they seem novel, remember that they're mundane tragedies. It's good someone's working on it, but they don't necessarily deserve the inordinate attention that they sometimes get.

Update, morning of 2012-09-18: Someone asked me to state more clearly how I felt about Red Hat's GPL enforcement action against TwinPeaks1. I carefully avoided saying that above last night, but I suppose I'm going to get asked so often that I might as well say. Plus, the answer is actually quite simple: I simply don't know until the action completes. I only believe that GPL enforcement is morally legitimate if compliance with the GPL is paramount above all other goals. I have never seen Red Hat enforce the GPL before, so I don't know the pecking order of their goals. The proof of the pudding is in the eating, and the proof in the enforcement is whether compliance is obtained. In short, if I were the Magic 8-Ball of GPL compliance, I'd say “Reply hazy, ask again later”2.

0 Obviously, there's a large negative impact that many seemingly “small” GPL violations, in aggregate, will together have on the entire software freedom community. But, I'm examining the point narrowly in the main text above. For example, imagine if the only GPL violation in the history of the world were done by one company, on one individual's copyrights, and only one customer ever purchased the infringing product. While I'd still value pursuit of that violation (and I would even help such a copyright holder pursue the matter), even I'd have to readily admit that the impact on the software freedom community of that one violation is rather limited.

Indeed, the larger policy impact of violations comes from the aggregate effect. That's why I've long argued that it's important to deal with the giant volume of GPL violations rather than focus on any one specific matter, even if that matter looks like a “big one”. It's just too easy sometimes to think one particular copyright holder, or one particular program, or one particular product deserves an inordinate amount of attention, but such undue focus is likely an outgrowth of familiarity breeding a bit too much contempt. I occasionally temporarily fall into that trap, so it makes me sad when others do as well.

1 What bugs me most is that I have yet to see a good Twin Peaks parody (ala Twin Beaks) of this whole court case. I suppose I'm just too old; I was in high school when the entire nation was obsessed with David Lynch's one hit TV series.

2 cf15290cc2481dbeacef75a3b8a87014e056c256a1aa485e8684c8c5f4f77660


The Punditocracy of Unelected Technocrats   


All this past week, people have been emailing and/or pinging me on IRC to tell me to read the article, The Meme Hustler by Evgeny Morozov. The article is quite long, and while my day-job duties left me TL;DR'ing it for most of the week, I've now read it, and I understand why everyone kept sending me the article. I encourage you not to TL;DR it any longer yourself.

Morozov centers his criticisms on Tim O'Reilly, but that's not all the article is about. I spend my days walking the Free Software beat as a (self-admitted) unelected politician, and I've encounter many spin doctors, including O'Reilly — most of whom wear the trappings of advocates for software freedom. As Morozov points out, O'Reilly isn't the only one; he's just the best at it. Morozov's analysis of O'Reilly can help us understand these P.T. Barnum's in our midst.

In 2001, I co-wrote Freedom or Power? with RMS in response to O'Reilly's very Randian arguments (which Morozov discusses). I remember working on that essay for (literally) days with RMS, in-person at the FSF offices (and at his office at MIT), while he would (again, literally) dance around the room, deep in thought, and then run back to the screen where I was writing to suggest a new idea or phrase to add. We both found it was really difficult to craft the right rhetoric to refute O'Reilly's points. (BTW, most people don't know that there were two versions of my and RMS' essay; the original one was published as a direct response to O'Reilly on his own website. One of the reasons RMS and I redrafted as a stand-alone piece was that we saw our original published response actually served to increase uptake of O'Reilly's position. We decided the issue was important enough it needed a piece that would stand on its own indefinitely to defend that key position.)

Meanwhile, I find it difficult to express more than a decade later how turbulent that time was for hard-core Free Software advocates, and how concerted the marketing campaign against us was. While we were in the middle of the Microsoft's attacks that GPL was an unAmerican cancer, we also had O'Reilly's the freedom that matters is the freedom to pick one's own license meme propagating fast. There were dirty politics afoot at the time, too: this all occurred during the same three-month period when Eric Raymond called me an inmate taking over the asylum. In other words, the spin doctors were attacking software freedom advocates from every side! Morozov's article captures a bit of what it feels like to be on the wrong side of a concerted, organized PR campaign to manipulate public opinion.

However, I suppose what I like most about Morozov's article is it's the first time I've seen discussed publicly and coherently a rhetorical trick that spin doctors use. Notice when you listen to a pundit at their undue sense of urgency; they invariably act as if what's happening now is somehow (to use a phrase the pundits love): “game changing”. What I typically see is such folks use urgency as a reason to make compromises quickly. Of course, the real goal is a get-rich-(or-famous)-quick scheme for themselves — not a greater cause. The sense of urgency leaves many people feeling that if they don't follow the meme, they'll be left in the dust. A colleague of mine once described this entrancing effect as dream-like, and that desire to stay asleep and keep dreaming is what lets the hustlers keep us under their spell.

I've admittedly spent more time than I'd like refuting these spin doctors (or, as Morozov also calls them, meme hustlers). Such work seems unfortunately necessary because Free Software is in an important, multi-decade (but admittedly not urgent :) battle of cooption (which, BTW, every social justice movement throughout history has faced). The tide of cooption by spin doctors can be stemmed only with constant vigilance, so I practice it.

Still, this all seems a cold, academic way to talk about the phenomenon. For these calculating Frank Luntz types, winning is enough; rhetoric, to them, is almost an end in itself (which I guess one might dub “Cicero 2.0”). For those of us who believe in the cause, the “game for the game's sake” remains distasteful because there are real principles at stake for us. Meanwhile, the most talented of these meme hustlers know well that what's a game to them matters emotionally to us, so they use our genuine concern against us at every turn. And, to make it worse, there's more of them out there than most people realize — usually carefully donning the trappings of allies. Kudos to Morozov for reminding us how many of these emperors have no clothes.


The Trade-offs of Unpaid Free Software Labor   


I read with interest Ashe Dryden's blog post entitled The Ethics of Unpaid Labor and the OSS Community0, and I agree with much of it. At least, I agree with Dryden much more than I agree with Hanson's blog post that inspired Dryden's, since Hanson's seems almost completely unaware of the distinctions between Free Software funding in non-profit and for-profit settings, and I think Dryden's criticism that Hanson's view is narrowed by “white-male in a wealthy country” privilege is quite accurate. I think Dryden does understand the distinctions of non-profit vs. for-profit Free Software development, and Dryden's has an excellent discussion on how wealthy and powerful individuals by default have more leisure time to enter the (likely fictional) Free Software development meritocracy via pure volunteer efforts.

However, I think two key points remain missing in the discussions so far on this topic. Specifically, (a) the issue of license design as it relates to non-monetary compensation of volunteer efforts and (b) developers' goals in using volunteer Free Software labor to bootstrap employment. The two issues don't interrelate that much, so I'll discuss them separately.

Copyleft Requirements as “Compensation” For Volunteer Contribution

I'm not surprised that this discussion about volunteer vs. paid labor is happening completely bereft of reference to the licenses of the software in question. With companies and even many individuals so rabidly anti-copyleft recently, I suspect that everyone in the discussion is assuming that the underlying license structure of these volunteer contributions is non-copyleft.

Strong copyleft's design, however, deals specifically with the problems inherent in uncompensated volunteer labor. By avoiding the possibility of proprietary derivatives, copyleft ensures that volunteer contributions do have, for lack of a better term, some strings attached: the requirement that even big and powerful companies that use the code treat the lowly volunteer contributor as a true equal.

Companies have resources that allows them to quickly capitalize on improvements to Free Software contributed by volunteers, and thus the volunteers are always at an economic disadvantage. Requiring that the companies share improvements with the community ensures that the volunteers' labor don't go entirely uncompensated: at the very least, the volunteer contributor has equal access to all improvements.

This phenomenon is in my opinion an argument for why there is less risk and more opportunity for contributors to copylefted codebases. Copyleft allows for some level of opportunity to the volunteer contributor that doesn't necessarily exist with non-copylefted codebases (i.e., the contributor is assured equal access to later improvements), and certainly doesn't exist with proprietary software.

Volunteer Contribution As Employment Terms-Setting

An orthogonal issue is this trend that employers use Free Software contribution as a hiring criterion. I've frankly found this trend disturbing for a wholly different reason than those raised in the current discussed. Namely, most employers who hire based on past Free Software contribution don't employ these developers to work on Free Software!

Free Software is, frankly, in a state of cooption. (Open Source itself, as a concept, is part of that cooption.) As another part of that cooption, teams of proprietary software (or non-released, secret software) developers use methodologies and workflows that were once unique to Free Software. Therefore, these employers want to know if job candidates know those workflows and methodologies so that the employer can pay the developer to stop using those techniques for the good of software freedom and instead use them for proprietary and/or secretive software development.

When I was in graduate school, one of the reasons I keenly wanted to be a core contributor to Free Software was not to just get paid for any software development, but specifically to gain employment writing software that would be Free Software. In those days, you picked a codebase you liked because you wanted to be employed to work on that upstream codebase. In fact, becoming a core contributor for a widely used copylefted codebase was once commonly a way to ensure you'd have your pick of jobs being paid to work on that codebase.

These days, most developers, even though they are required to use some Free Software as part of their jobs, usually are assigned work on some non-Free Software that interacts with that Free Software. Thus, the original meme, that began in the early 1990s, of volunteer for a Free Software codebase so you can later get paid to work on it, has recently morphed into volunteer to work on Free Software so you can get a job working on some proprietary software. That practice is a complete corruption and cooption of the Free Software culture.

All that said, I do agree with Dryden that we should do more funding at the entry-level of Free Software development, and the internships in particular, such as those through the OPW are, as Dryden writes, absolutely essential to solve the obvious problem of under-representation by those with limited leisure time for volunteer contribution. I think such funding is best when it's done as part of a non-profit rather than a for-profit settings, for reasons that would require yet another blog post to explain.

0Please note that I haven't seen any of the comments on Dryden's blog post or many of the comments that spawned it, because as near as I can tell, I can't use Disqus without installing proprietary software on my computer, through its proprietary Javascript. If someone can tell me how to read Disqus discussions without proprietary Javascript, I'd appreciate it.


GCC, LLVM, Copyleft, Companies, and Non-Profits   


[ Please keep in mind in reading this post that while both FSF and Conservancy are mentioned, and that I have leadership roles at both organizations, these opinions on, as always, are my own and don't necessarily reflect the view of FSF and/or Conservancy. ]

Most people know I'm a fan of RMS' writing about Free Software and I agree with most (but not all) of his beliefs about software freedom politics and strategy. I was delighted to read RMS' post about LLVM on the GCC mailing list on Friday. It's clear and concise, and, as usual, I agree with most (but not all) of it, and I encourage people to read it. Meanwhile, upon reading comments on LWN on this post, I felt the need to add a few points to the discussion.

Firstly, I'm troubled to see so many developers, including GCC developers, conflating various social troubles in the GCC community with the choice of license. I think it's impossible to deny that culturally, the GCC community faces challenges, like any community that has lasted for so long. Indeed, there's a long political history of GCC that even predates my earliest involvement with the Free Software community (even though I'm now considered an old-timer in Free Software in part because I played a small role — as a young, inexperienced FSF volunteer — in helping negotiate the EGCS fork back into the GCC mainline).

But none of these politics really relate to GCC's license. The copyleft was about ensuring that there were never proprietary improvements to the compiler, and AFAIK no GCC developers ever wanted that. In fact, GCC was ultimately the first major enforcement test of the GPL, and ironically that test sent us on the trajectory that led to the current situation.

Specifically, as I've spoken about in my many talks on GPL compliance, the earliest publicly discussed major GPL violation was by NeXT computing when Steve Jobs attempted and failed (thanks to RMS' GPL enforcement work) to make the Objective C front-end to GCC proprietary. Everything for everyone involved would have gone quite differently if that enforcement effort had failed.

As it stands, copyleft was upheld and worked. For years, until quite recently (in context of the history of computing, anyway), Apple itself used and relied on the Free Software GCC as its primary and preferred Objective C compiler, because of that enforcement against NeXT so long ago. But, that occurrence also likely solidified Jobs' irrational hatred of copyleft and software freedom, and Apple was on a mission to find an alternative compiler — but writing a compiler is difficult and takes time.

Meanwhile, I should point out that copyleft advocates sometimes conflate issues in analyzing the situation with LLVM. I believe most LLVM developers when they say that they don't like proprietary software and that they want to encourage software freedom. I really think they do. And, for all of us, copyleft isn't a religion, or even a belief — it's a strategy to maximize software freedom, and no one (AFAICT) has said it's the only viable strategy to do that. It's quite possible the strategy of LLVM developers of changing the APIs quickly to thwart proprietarization might work. I really doubt it, though, and here's why:

I'll concede that LLVM was started with the best of academic intentions to make better compiler technology and share it freely. (I've discussed this issue at some length with Chris Lattner directly, and I believe he actually is someone who wants more software freedom in the world, even if he disagrees with copyleft as a strategy.) IMO, though, the problem we face is exploitation by various anti-copyleft, software-freedom-unfriendly companies that seek to remove every copyleft component from any software stack. Their reasons for pursuing that goal may or may not be rational, but its collateral damage has already become clear: it's possible today to license proprietary improvements to LLVM that aren't released as Free Software. I predict this will become more common, notwithstanding any technical efforts of LLVM developers to thwart it. (Consider, by way of historical example, that proprietary combined works with Apache web server continue to this very day, despite Apache developers' decades of we'll break APIs, so don't keep your stuff proprietary claims.)

Copyleft is always a trade-off between software freedom and adoption. I don't admonish people for picking the adoption side over the software freedom side, but I do think as a community we should be honest with ourselves that copyleft remains the best strategy to prevent proprietary improvements and forks and no other strategy has been as successful in reaching that goal. And, those who don't pick copyleft have priorities other than software freedom ranked higher in their goals.

As a penultimate point, I'll reiterate something that Joe Buck pointed out on the LWN thread: a lot of effort was put in to creating a licensing solution that solved the copyleft concerns of GCC plugins. FSF's worry for more than a decade (reaching back into the late 1990s) was that a GCC plugin architecture would allow writing to an output file GCC's intermediate representation, which would, in turn, allow a wholly separate program to optimize the software by reading and writing that file format, and thus circumvent the protections of copyleft. The GCC Runtime Library Exception (GCC RTL Exception) is (in my biased opinion) an innovative licensing solution that solves the problem — the ironic outcome: you are only permitted to perform proprietary optimization with GCC on GPL'd software, but not on proprietary software.

The problem was that the GCC RTL Exception came too late. While I led the GCC RTL Exception drafting process, I don't take the blame for delays. In fact, I fought for nearly a year to prioritize the work when FSF's outside law firm was focused on other priorities and ignored my calls for urgency. I finally convinced everyone, but the work got done far too late. (IMO, it should have been timed for release in parallel with GPLv3 in June 2007.)

Finally, I want to reiterate that copyleft is a strategy, not a moral principle. I respect the LLVM developers' decision to use a different strategy for software freedom, even if it isn't my preferred strategy. Indeed, I respect it so much that I supported Conservancy's offer of membership to LLVM in Software Freedom Conservancy. I still hope the LLVM developers will take Conservancy up on this offer. I think that regardless of a project's preferred strategy for software freedom — copyleft or non-copyleft — that it's important for the developers to have a not-for-profit charity as a gathering place for developers, separate from their for-profit employer affiliations.

Undue for-profit corporate influence is the biggest problem that software freedom faces today. Indeed, I don't know a single developer in our community who likes to see their work proprietarized. Developers, generally speaking, want to share their code with other developers. It's lawyers and business people with dollar signs in their eyes who want to make proprietary software. Those people sometimes convince developers to make trade-offs (which I don't agree with myself) to work on proprietary software (— usually in exchange for funding some of their work time on upstream Free Software). Meanwhile, those for-profit-corporate folks frequently spread lies and half-truths about the copyleft side of the community — in an effort to convince developers that their Free Software projects “won't survive” if those developers don't follow the exact plan The Company proposes. I've experienced these manipulations myself — for example, in April 2013, a prominent corporate lawyer with an interest in LLVM told me to my face that his company would continue spreading false rumors that I'd use LLVM's membership in Conservancy to push the LLVM developers toward copyleft, despite my public statements to the contrary. (Again, for the record, I have no such intention and I'd be delighted to help LLVM be led in a non-profit home by its rightful developer leaders, whichever Open Source and Free Software license they chose.)

In short, the biggest threat to the future of software has always been for-profit companies who wish to maximize profits by exploiting the code, developers and users while limiting their software freedom. Such companies try every trick in pursuit of that goal. As such, I prefer copyleft as a strategy. However, I don't necessarily admonish those who pick a different strategy. The reason that I encourage membership of non-copylefted projects in Conservancy (and other 501(c)(3) charities) is to give those projects the benefits of a non-profit home that maximize software freedom using the project's chosen strategy, whatever it may be.


Help Fund Open-Wash-Free Zones   


Recently, I was forwarded an email from an executive at a 501(c)(6) trade association. In answering a question about accepting small donations for an “Open Source” project through their organization, the Trade Association Executive responded Accepting [small] donations [from individuals] is possible, but [is] generally not a sustainable way to raise funds for a project based on our experience. It's extremely difficult … to raise any meaningful or reliable amounts.

I was aghast, but not surprised. The current Zeitgeist of the broader Open Source and Free Software community incubated his disturbing mindset. Our community suffers now from regular and active cooption by for-profit interests. The Trade Association Executive's fundraising claim — which probably even bears true in their subset of the community — shows the primary mechanism of cooption: encourage funding only from a few, big sources so they can slowly but surely dictate project policy.

Today, more revenue than ever goes to the development of code released under licenses that respect software freedom. That belabored sentence contains the key subtlety: most Free Software communities are not receiving more funding than before, in fact, they're probably receiving less. Instead, Open Source became a fad, and now it's “cool” for for-profit companies to release code, or channel funds through some trade associations to get the code they want written and released. This problem is actually much worse than traditional open-washing. I'd call this for-profit cooption its own subtle open-washing: picking a seemingly acceptable license for the software, but “engineering” the “community” as a proxy group controlled by for-profit interests.

This cooption phenomenon leaves the community-oriented efforts of Free Software charities underfunded and (quite often) under attack. These same companies that fund plenty of Open Source development also often oppose copyleft. Meanwhile, the majority of Free Software projects that predate the “Open Source Boom” didn't rise to worldwide fame and discover a funding bonanza. Such less famous projects still struggle financially for the very basics. For example, I participate in email threads nearly every day with Conservancy member projects who are just trying to figure out how to fund developers to a conference to give a talk about their project.

Thus, a sad kernel of truth hides in the Trade Association Executive's otherwise inaccurate statement: big corporate donations buy influence, and a few of our traditionally community-oriented Free Software projects have been “bought” in various ways with this influx of cash. The trade associations seek to facilitate more of this. Unless we change our behavior, the larger Open Source and Free Software community may soon look much like the political system in the USA: where a few lobbyist-like organizations control the key decision-making through funding. In such a structure, who will stand up for those developers who prefer copyleft? Who will make sure individual developers receive the organizational infrastructure they need? In short, who will put the needs of individual developers and users ahead of for-profit companies?

Become a Conservancy Supporter!

The answer is simple: non-profit 501(c)(3) charities in our community. These organizations that are required by IRS regulation to pass a public support test, which means they must seek large portions of their revenue from individuals in the general public and not receive too much from any small group of sources. Our society charges these organizations with the difficult but attainable tasks of (a) answering to the general public, and never for-profit corporate donors, and (b) funding the organization via mechanisms appropriate to that charge. The best part is that you, the individual, have the strongest say in reaching those goals.

Those who favor for-profit corporate control of “Open Source” projects will always insist that Free Software initiatives and plans just cannot be funded effectively via small, individual donations. Please, for the sake of software freedom, help us prove them wrong. There's even an easy way that you can do that. For just $10 a month, you can join the Conservancy Supporter program. You can help Conservancy stand up for Free Software projects who seek to keep project control in the hands of developers and users.

Of course, I realize you might not like my work at Conservancy. If you don't, then give to the FSF instead. If you don't like Conservancy nor the FSF, then give to the GNOME Foundation. Just pick the 501(c)(3) non-profit charity in the Free Software community that you like best and donate. The future of software freedom depends on it.


Why Greet Apple's Swift 2.0 With Open Arms?   


Apple announced last week that its Swift programming language — a currently fully proprietary software successor to Objective C — will probably be partially released under an OSI-approved license eventually. Apple explicitly stated though that such released software will not be copylefted. (Apple's pathological hatred of copyleft is reasonably well documented.) Apple's announcement remained completely silent on patents, and we should expect the chosen non-copyleft license will not contain a patent grant. (I've explained at great length in the past why software patents are a particularly dangerous threat to programming language infrastructure.)

Apple's dogged pursuit for non-copyleft replacements for copylefted software is far from new. For example, Apple has worked to create replacements for Samba so they need not ship Samba in OSX. But, their anti-copyleft witch hunt goes back much further. It began when Richard Stallman himself famously led the world's first GPL enforcement effort against NeXT, and Objective-C was liberated. For a time, NeXT and Apple worked upstream with GCC to make Objective-C better for the community. But, that whole time, Apple was carefully plotting its escape from the copyleft world. Fortuitously, Apple eventually discovered a technically brilliant (but sadly non-copylefted) research programming language and compiler system called LLVM. Since then, Apple has sunk millions of dollars into making LLVM better. On the surface, that seems like a win for software freedom, until you look at the bigger picture: their goal is to end copyleft compilers. Their goal is to pick and choose when and how programming language software is liberated. Swift is not a shining example of Apple joining us in software freedom; rather, it's a recent example of Apple's long-term strategy to manipulate open source — giving our community occasional software freedom on Apple's own terms. Apple gives us no bread but says let them eat cake instead.

Apple's got PR talent. They understand that merely announcing the possibility of liberating proprietary software gets press. They know that few people will follow through and determine how it went. Meanwhile, the standing story becomes: Wait, didn't Apple open source Swift anyway?. Already, that false soundbite's grip strengthens, even though the answer remains a resounding No!. However, I suspect that Apple will probably meet most of their public pledges. We'll likely see pieces of Swift 2.0 thrown over the wall. But the best stuff will be kept proprietary. That's already happening with LLVM, anyway; Apple already ships a no-source-available fork of LLVM.

Thus, Apple's announcement incident hasn't happened in a void. Apple didn't just discover open source after years of neutrality on the topic. Apple's move is calculated, which led various industry pundits like O'Grady and Weinberg to ask hard questions (some of which are similar to mine). Yet, Apple's hype is so good, that it did convince one trade association leader.

To me, Apple's not-yet-executed move to liberate some of the Swift 2.0 code seems a tactical stunt to win over developers who currently prefer the relatively more open nature of the Android/Linux platform. While nearly all the Android userspace applications are proprietary, and GPL violations on Android devices abound, at least the copyleft license of Linux itself provides the opportunity to keep the core operating system of Android liberated. No matter how much Swift code is released, such will never be true with Apple.

I'm often pointing out in my recent talks how complex and treacherous the Open Source and Free Software political climate became in the last decade. Here's a great example: Apple is a wily opponent, utilizing Open Source (the cooption of Free Software) to manipulate the press and hoodwink the would-be spokespeople for Linux to support them. Many of us software freedom advocates have predicted for years that Free Software unfriendly companies like Apple would liberate more and more code under non-copyleft licenses in an effort to create walled gardens of seeming software freedom. I don't revel in my past accuracy of such predictions; rather, I feel simply the hefty weight of Cassandra's curse.


Exercising Software Freedom in the Global Email System   


[ This post was cross-posted on Conservancy's blog. ]

In this post, I discuss one example of how a choice for software freedom can cause many strange problems that others will dismiss. My goal here is to explain in gory detail how proprietary software biases in the computing world continue to grow, notwithstanding Open Source ballyhoo.

Two decades ago, nearly every company, organization, entity, and tech-minded individual ran their own email server. Generally speaking, even back then, nearly all the software for both MTAs and MUAs were Free Software0. MTA's are the mail transport agents — the complex software that moves email around from one Internet domain to another. MUAs are the mail user agents, sometimes called mail clients — the local programs with which users manipulate their own email.

I've run my own MTA since around 1993: initially with sendmail, then with exim for a while, and with Postfix since 1999 or so. Also, everywhere I've worked throughout my entire career since 1995, I've either been in charge of — or been the manager of the person in charge of — the MTA installation for the organization where I worked. In all cases, that MTA has always been Free Software, of course.

However, the world of email has changed drastically during that period. The most notable change in the email world is the influx of massive amounts of spam, which has been used as an excuse to implement another disturbing change. Slowly but surely, email service — both the MTA and the MUA — have been outsourced for most organizations. Specifically, either (a) organizations run proprietary software on their own computers to deal with email and/or (b) people pay a third-party to run proprietary and/or trade-secret software on their behalf to handle the email services. Email, generally speaking, isn't handled by Free Software all that much anymore.

This situation became acutely apparent to me this earlier this month when Conservancy moved its email server. I had plenty of warning that the move was needed1, and I'd set up a test site on the new server. We sent and received some of our email for months (mostly mailing list traffic) using that server configured with a different domain ( When the shut-off day came, I moved's email officially. All looked good: I had a current Debian, with a new version of Postfix and Dovecot on a speedier host, and with better spam protection settings in Postfix and better spam filtering with a newer version of SpamAssassin. All was going great, thanks to all those great Free Software projects — until the proprietary software vendors threw a spanner in our works.

For reasons that we'll never determine for sure2, the IPv4 number that our new hosting provide gave us was already listed on many spam blacklists. I won't debate the validity of various blacklists here, but the fact is, for nearly every public-facing, pure-blacklist-only service, delisting is straightforward, takes about 24 hours, and requires at most answering some basic questions about your domain name and answering a captcha-like challenge. These services, even though some are quite dubious, are not the center of my complaint.

The real peril comes from third-party email hosting companies. These companies have arbitrary, non-public blacklisting rules. More importantly, they are not merely blacklist maintainers, they are MTA (and in some cases, even MUA) providers who sell their proprietary and/or trade-secret hosted solutions as a package to customers. Years ago, the idea of giving up that much control of what happens to your own email would be considered unbelievable. Today, it's commonplace.

And herein lies the fact that is obvious to most software freedom advocates but indiscernible by most email users. As a Free Software user, with your own MTA on your own machine, your software only functions if everyone else respects your right to run that software yourself. Furthermore, if the people you want to email are fully removed from their hosting service, they won't realize nor understand that their hosting site might block your emails. These companies have their customers fully manipulated to oppose your software freedom. In other words, you can't appeal to those customers (the people you want to email), because you're likely the only person to ever raise this issue with them (i.e., unless they know you very well, they'll assume you're crazy). You're left begging to the provider, whom you have no business relationship with, to convince them that their customers want to hear from you. Your voice rings out indecipherable from the spammers who want the same permission to attack their customers.

The upshot for Conservancy? For days, Microsoft told all its customers that Conservancy is a spammer; Microsoft did it so subtly that the customers wouldn't even believe it if we told them. Specifically, every time I or one of my Conservancy colleagues emailed organizations using Microsoft's “Exchange Online”, “Office 365” or similar products to host email for their domain4, we got the following response:

        Sep  2 23:26:26 pine postfix/smtp[31888]: 27CD6E12B: to=,[]:25, delay=5.6, delays=0.43/0/0.16/5, dsn=5.7.1, status=bounced (host[] said: 550 5.7.1 Service unavailable; Client host [] blocked using FBLW15; To request removal from this list please forward this message to (in reply to RCPT TO command))

Oh, you ask, did you forward your message to the specified address? Of course I did; right away! I got back an email that said:

Hello ,

Thank you for your delisting request SRXNUMBERSID. Your ticket was received on (Sep 01 2015 06:13 PM UTC) and will be responded to within 24 hours.

Once we passed the 24 hour mark with no response, I started looking around for more information. I also saw a suggestion online that calling is the only way to escalate one of those tickets, so I phoned 800-865-9408 and gave V-2JECOD my ticket number and she told that I could only raise these issues with the “Mail Flow Team”. She put me on hold for them, and told me that I was number 2 in the queue for them so it should be a few minutes. I waited on hold for just under six hours. I finally reached a helpful representative, who said the ticket was the lowest level of escalation available (he hinted that it would take weeks to resolve at that level, which is consistent with other comments about this problem I've seen online). The fellow on the phone agreed to escalate it to the highest priority available, and said within four hours, Conservancy should be delisted. Thus, ultimately, I did resolve these issues after about 72 hours. But, I'd spent about 15 hours all-told researching various blacklists, email hosting companies, and their procedures3, and that was after I'd already carefully configured our MTA and DNS to be very RFC-compliant (which is complicated and confusing, but absolutely essential to stay off these blacklists once you're off).

Admittedly, this sounds like a standard Kafkaesque experience with a large company that almost everyone in post-modern society has experienced. However, it's different in one key way: I had to convince Microsoft to allow me to communicate with their customers who are paying Microsoft for proprietary and/or trade-secret software and services, ostensibly to improve efficiency of their communications. Plus, since Microsoft, by the nature of their so-called spam blocking, doesn't inform their customers whom they've blocked, I and my colleagues would have just sounded crazy if we'd asked our contacts to call their provider instead. (I actually considered this, and realized that we might negatively impact relationships with professional contacts.)

These problems do reduce email software freedom by network effects. Most people rely on third-party proprietary email software from Google, Microsoft, Barracuda, or others. Therefore, most people, don't exercise any software freedom regarding email services. Since exercising software freedom for email slowly becomes a rarer and rarer (rather than norm it once was), society slowly but surely pegs those who do exercise software freedom as “random crazy people”.

There are a few companies who are seeking to do email hosting in a way that respects your software freedom. The real test of such companies is if someone technically minded can get the same software configured on their own systems, and have it work the same way. Yet, in most cases, you go to one of these companies' Github pages and find a bunch of stuff pushed public, but limited information on how to configure it so that it functions the same way the hosted service does. RMS wrote years ago that Free Software cannot properly succeed without Free Documentation, and in many of these hosting cases: the hosting company is using fully upstreamed Free Software, but has configured the software in a way that is difficult to stumble upon by oneself. (For that reason, I'm committing to writing up tutorials on how Conservancy configured our mail server, so at least I'll be part of the solution instead of part of the problem.)

BTW, as I dealt with all this, I couldn't help but think of John Gilmore's activism efforts regarding open mail relays. While I don't agree with all of John's positions on this, his fundamental position is right: we must oppose companies who think they know better how we should configure our email servers (or on which IP numbers we should run those servers). I'd add a corollary that there's a serious threat to software freedom, at least with regard to email software, if we continue to allow such top-down control of the once beautifully decentralized email system.

The future of software freedom depends on issues like this. Imagine someone who has just learned that they can run their own email server, or bought some Free Software-based plug computing system that purports to be a “home cloud” service with email. There's virtually no chance that such users would bother to figure all this out. They'd see their email blocked, declare the “home cloud” solution useless, and would just get a,, or some other third-party email account. Thus, I predict that software freedom that we once had, for our MTAs and MUAs, will eventually evaporate for everyone except those tiny few who invest the time to understand these complexities and fight the for-profit corporate power that curtails software freedom. Furthermore, that struggle becomes Sisyphean as our numbers dwindle.

Email is the oldest software-centric communication system on the planet. The global email system serves as a canary in the coalmine regarding software freedom and network service freedom issues. Frighteningly, software now controls most of the global communications systems. How long will it be before mobile network providers refuse to terminate PSTN calls or SMS's sent from devices running modified Android firmwares like Replicant? Perhaps those providers, like large email providers, will argue that preventing robocalls (the telephone equivalent of SPAM) necessitates such blocking. Such network effects place so many dystopias on software freedom's horizon.

I don't deny that every day, there is more Free Software existing in the world than has ever existed before — the P.T. Barnum's of Open Source have that part right. The part they leave out is that, each day, their corporate backers make it a little more difficult to complete mundane tasks using only Free Software. Open Source wins the battle while software freedom loses the war.

0Yes, I'm intimately aware that Elm's license was non-free, and that the software freedom of PINE's license was in question. That's slightly relevant here but mostly orthogonal to this point, because Free Software MUAs were still very common then, and there were (ultimately successful) projects to actively rewrite the ones whose software freedom was in question

1For the last five years, one of Conservancy's Director Emeriti, Loïc Dachary, has donated an extensive amount of personal time and in-kind donations by providing Cloud server for Conservancy to host its three key servers, including the email server. The burden of maintaining this for us became too time consuming (very reasonably), and Loïc's asked us to find another provider. I want, BTW, to thank Loïc his for years of volunteer work maintaining infrastructure for us; he provided this service for much longer than we could have hoped! Loïc also gave us plenty of warning that we'd need to move. None of these problems are his fault in the least!

2The obvious supposition is that, because IPv4 numbers are so scarce, this particular IP number was likely used previously by a spammer who was shut down.

3I of course didn't count the time time on phone hold, as I was able to do other work while waiting, but less efficiently because the hold music was very distracting.

4If you want to see if someone's domain is a Microsoft customer, see if the MX record for their domain (say, points to


How Would Software Freedom Have Helped With VW?   


[ A version of this blog post was crossposted on Conservancy's blog. ]

Would software-related scandals, such as Volkswagen's use of proprietary software to lie to emissions inspectors, cease if software freedom were universal? Likely so, as I wrote last week. In a world where regulations mandate distribution of source code for all the software in all devices, and where no one ever cheats on that rule, VW would need means other than software to hide their treachery.

Universal software freedom is my lifelong goal, but I realized years ago that I won't live to see it. I suspect that generations of software users will need to repeatedly rediscover and face the harms of proprietary software before a groundswell of support demands universal software freedom. In the meantime, our community has invented semi-permanent strategies, such as copyleft, to maximize software freedom for users in our current mixed proprietary and Free Software world.

In the world we live in today, software freedom can impact the VW situation only if a few complex conditions are met. Let's consider the necessary hypothetical series of events, in today's real world, that would have been necessary for Open Source and Free Software to have stopped VW immediately.

First, VW would have created a combined or derivative work of software with a copylefted program. While many cars today contain Linux, which is copylefted, I am not aware of any cars that use Linux outside of the on-board entertainment and climate control systems. The VW software was not part of those systems, and VW engineers almost surely wrote the emissions testing mode code from scratch. Even if they included some non-copylefted Open Source or Free Software in it, those licenses don't require disclosure of any source code; VW's ability to conceal its bad actions with non-copylefted code is roughly identical to the situation of proprietary VW code before us. As a thought experiment, though, let's pretend, that VW based the nefarious code on Linux by writing a proprietary Linux module to trick the emissions testing systems.

In that case, VW would have violated the GPL. But that alone is far from enough to ensure anyone would catch VW. Indeed, GPL violations remain very prevalent, and only one organization enforces the GPL for Linux (full disclosure: that's Software Freedom Conservancy, where I work). That organization has such limited enforcement resources (only three people on staff, and enforcement is one of many of our programs), I suspect that years would pass before Conservancy had the resources to pursue the violation; Conservancy currently has hundreds of Linux GPL violations queued for action. Even once opened, most GPL violations take years to resolve. As an example, we are currently enforcing the GPL against one auto manufacturer who has Linux in their car. We've already spent hundreds of hours and the company to date continues to fail in their GPL compliance efforts. Admittedly, it's highly unlikely that particular violator has a GPL-violating Linux module specifically designed to circumvent automotive regulations. However, after enforcing the GPL in that case for more than two years, I still don't have enough data about their use of Linux to even know which proprietary Linux modules are present — let alone whether those modules are nefarious in any way other than as violating Linux's license.

Thus, in today's world, a “software freedom solution” to prevent the VW scandal must meet unbelievable preconditions: (a) VW would have to base all its software on copylefted Open Source and Free Software, and (b) an organization with a mission to enforce copyleft for the public good would require the resources to find the majority of GPL violators and ensure compliance in a timely fashion. This thought experiment quickly shows how much more work remains to advance and defend software freedom. While requirements of source code disclosure, such as those in copyleft licenses, are necessary to assure the benefits of software freedom, they cannot operate unless someone exercises the offers for source and looks at the details.

We live in a world where most of the population accepts proprietary software as legitimate. Even major trade associations, such as the OpenStack Foundation and the Linux Foundation, in the Open Source community laud companies who make proprietary software, as long as they adopt and occasionally contribute to some Free Software too. Currently, it feels like software freedom is winning, because the overwhelming majority in the software industry believe Open Source and Free Software is useful and superior in some circumstances. Furthermore, while I appreciate the aspirational ideal of voluntary Open Source, I find in my work that so many companies, just as VW did, will cheat against important social good policies unless someone watches and regulates. Mere adoption of Open Source won't work alone; we only yield the valuable results of software freedom if software is copylefted and someone upholds that copyleft.

Indeed, just as it has been since the 1980s, very few people believe that software freedom is of fundamental importance for all software users. Scandals, like VW's use of proprietary software to hide other bad acts, might slowly change opinions, but one scandal is rarely enough to permanently change public opinion. I therefore encourage those who support software freedom to take this incident as inspiration for a stronger stance, and to prepare yourselves for the long haul of software freedom advocacy.


Do You Like What I Do For a Living?   


[ A version of this blog post was crossposted on Conservancy's blog. ]

I'm quite delighted with my career choice. As an undergraduate and even in graduate school, I still expected my career extend my earlier careers in the software industry: a mixture of software developer and sysadmin. I'd probably be a DevOps person now, had I stuck with that career path.

Instead, I picked the charity route: which (not financially, but work-satisfaction-wise) is like winning a lottery. There are very few charities related to software freedom, and frankly, if (like me) you believe in universal software freedom and reject proprietary software entirely, there are two charities for you: the Free Software Foundation, where I used to work, and Software Freedom Conservancy, where I work now.

But software freedom is not merely an ideology for me. I believe the ideology matters because I see the lives of developers and users are better when they have software freedom. I first got a taste of this IRL when I attended the earliest Perl conferences in the late 1990s. My friend James and I stayed in dive motels and even slept in a rental car one night to be able to attend. There was excitement in the Perl community (my first Free Software community). I was exhilarated to meet in person the people I'd seen only as god-like hackers posting on perl5-porters. James was so excited he asked me to take a picture of him jumping as high as he could with his fist in the air in front of the main conference banner. At the time, I complained; I was mortified and felt like a tourist taking that picture. But looking back, I remember that James and I felt that same excitement and we just expressed it differently.

I channeled that thrill into finding a way that my day job would focus on software freedom. As an activist since my teenage years, I concentrated specifically on how I could preserve, protect and promote this valuable culture and ideology in a manner that would assure the rights of developers and users to improve and share the software they write and use.

I've enjoyed the work; I attend more great conferences than I ever imagined I would, where now people occasionally walk up to me with the same kind of fanboy reverence that I reserved for Larry Wall, RMS and the heroes of my Free Software generation. I like my work. I've been careful, however, to avoid a sense of entitlement. Since I read it in 1991, I have never forgotten RMS' point in the GNU Manifesto: 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., a point he continues in his regular speeches, by adding: I [could] just … give up those principles and start … writing proprietary software. I looked for another alternative, and there was an obvious one. I could leave the software field and do something else. Now I had no other special noteworthy skills, but I'm sure I could have become a waiter. Not at a fancy restaurant; they wouldn’t hire me; but I could be a waiter somewhere. And many programmers, they say to me, “the people who hire programmers demand [that I write proprietary software] and if I don’t do [it], I’ll starve”. It’s literally the word they use. Well, as a waiter, you’re not going to starve.

RMS' point is not merely to expose the false dilemma inherent in: I have to program, even if my software is proprietary, because that's what companies pay me to do, but also to expose the sense of entitlement in assuming a fundamental right to do the work you want. This applies not just to software authorship (the work I originally trained for) but also the political activism and non-profit organizational work that I do now.

I've spent most of my career at charities because I believe deeply that I should take actions that advance the public good, and because I have a strategic vision for the best methods to advance software freedom. My strategic goals to advance software freedom include two basic tenets: (a) provide structure for Free Software projects in a charitable home (so that developers can focus on writing software, not administration, and so that the projects aren't unduly influenced by for-profit corporations) and (b) uphold and defend Free Software licensing, such as copyleft, to ensure software freedom.

I don't, however, arrogantly believe that these two priorities are inherently right. Strategic plans work toward a larger goal, and pursing success of a larger ideological mission requires open-mindedness regarding strategies. Nevertheless, any strategy, once decided, requires zealous pursuit. It's with this mindset that I teamed up with my colleague, Karen Sandler, to form Software Freedom Conservancy.

Conservancy, like most tiny charities, survives on the determination of its small management staff. Karen Sandler, Conservancy's Executive Director, and I have a unique professional collaboration. She and I share a commitment to promoting and defending moral principles in the context of software freedom, along with an unrelenting work ethic to match. I believe fundamentally that she and I have the skills, ability, and commitment to meet these two key strategic goals for software freedom.

Yet, I don't think we're entitled to do this work. And, herein there's another great feature of a charity. A charity not only serves the public good; the USA IRS also requires that a charity be funded primarily by donations from the public.

I like this feature for various reasons. Particularly, in the context of the fundraiser that Conservancy announced this week, I think about it terms of seeking a mandate from the public. As Conservancy poises to begin its tenth year, Karen and I as its leaders stand at a crossroads. For financial reasons of the organization's budget, we've been thrust to test this question: Does the public of Free Software users and developers actually want the work that we do?.

While I'm nervous that perhaps the answer is no, I'm nevertheless not afraid to ask the question. So, we've asked. We asked all of you to show us that you want our work to continue. We set two levels, matching the two strategic goals I mentioned. (The second is harder and more expensive to do than the first, so we've asked many more of you to support us if you want it.)

It's become difficult in recent years to launch a non-profit fundraiser (which have existed for generations) and not think of the relatively recent advent of gofundme, Kickstarter, and the like. These new systems provide a (sadly, usually proprietary software) platform for people to ask the public: Is my business idea and/or personal goal worth your money?. While I'm dubious about those sites, I do believe in democracy enough to build my career on a structure that requires an election (of sorts). Karen and I don't need you to go to the polls and cast your ballot, but we do ask you consider if what we do for a living at Conservancy is worth US$10 per month to you. If it is, I hope you'll “cast a vote” for Conservancy and become a Conservancy supporter now.


Fighting For Social Justice Is a Major Contribution to Society   


I have something to say that I'm sure everyone is going to consider controversial. I've been meaning to say it for some time, and I realize that it's going to get some annoyance from all sides of this debate. Conservancy may lose Supporters over this, even though this is my personal blog and my personal opinion, and views expressed here aren't necessarily Conservancy's views. I've actually been meaning to write this publicly for a year. I just have to say it now, because there's yet another event on this issue caused yet another a war of words in our community.

If you follow the types of Free Software politics and issues that I do (which you probably do if you read my blog) you have heard the phrase — which has become globally common in general politics — “Social Justice Warrior”, often abbreviated SJW. As anyone who reads my blog probably already knows, SJW is used as a derogatory catch-all phrase referring to anyone who speaks up to on any cause, but particularly on racial or gender inequality. While the derogatory part seems superficially to refer to tactics rather than strategic positions, nevertheless many critics who use the phrase conflate (either purposely or not) some specific, poorly-chosen tactic (perhaps from long ago) of the few with the strategic goals of an entire movement.

Anyway, my argument in this post, which is why I expect it to annoy everyone equally, is not about some specific issue in any cause, but on a meta-issue. The meta-issue is the term “SJW” itself. The first time I heard the phrase (which, given my age, feels recent, even though it was probably four years ago), I actually thought it was something good; I first thought that SJW was a compliment. In fact, I've more-or-less spent my entire adult life wanting to be a social justice warrior, although I typically called it being a “social justice activist”.

First of all, I believe deeply in social justice causes. I care about equality, fairness, and justice for everyone. I believe software freedom is a social justice cause, and I personally have proudly called software freedom a social justice cause for more than a decade.

Second, I also believe in the zealous pursuit of causes that matter. I've believed fully and completely in non-violence since the mid-1980s, but I nevertheless believe there is a constant war of words in the politics surrounding any cause or issue, including software freedom. I am, therefore — for lack of a better word — a warrior, in those politics.

So, when I look at the three words on their face: Social. Justice. Warrior. Well, denotively, it describes my lifelong work exactly.

Connotatively, a warped and twisted manipulation of words has occurred. Those, who want to discredit the validity of various social justice causes, have bestowed a negative connotation on the phrase to create a social environment that makes anyone who wants to speak out about a cause automatically wrong and easily branded.

I've suggested to various colleagues privately over the last two years that we should coopt the phrase back to mean something good. Most have said that's a waste of time and beside the point. I still wonder whether they're right.

By communicating an idea that these social justice people are fighting against me and oppressing me, the messenger accusing a so-called SJW has a politically powerful, well-coopted message, carefully constructed for concision and confirmation bias. While I don't believe all that cooptive and manipulative power is wielded solely in the one three-word phrase, I do believe that the rhetorical trick that allows “SJW” to have a negative connotation is the same rhetorical power that has for centuries allowed the incumbent power structures to keep their control of those many social institutions that are governed chiefly by rhetoric.

And this is precisely why I just had to finally post something about this. I won a cultural power jackpot, merely by being born a middle-class Caucasian boy in the USA. Having faced some adversity in my life despite that luck, and then seeing how easy I had it compared to the adversity that others have faced, I become furious at how the existing power structures can brand people with — let's call it what is — a sophisticated form of name-calling that coopts a phrase like “social justice”, which until that time had a history of describing some of the greatest, most selfless, and most important acts of human history.

Yes, I know there are bigger issues at stake than just the words people use. But words matter. No matter how many people use the phrase negatively, I continue to strive to be a social justice warrior. I believe that's a good thing, in the tradition of all those who have fought for a cause they believed was right, even when it wasn't popular.


Sun, Oracle, Android, Google and JDK Copyleft FUD   


I have probably spent more time dealing with the implications and real-world scenarios of copyleft in the embedded device space than anyone. I'm one of a very few people charged with the task of enforcing the GPL for Linux, and it's been well-known for a decade that GPL violations on Linux occur most often in embedded devices such as mobile hand-held computers (aka “phones”) and other such devices.

This experience has left me wondering if I should laugh or cry at the news coverage and pundit FUD that has quickly come forth from Google's decision to move from the Apache-licensed Java implementation to the JDK available from Oracle.

As some smart commenters like Bob Lee have said, there is already at least one essential part of Android, namely Linux itself, licensed as pure GPL. I find it both amusing and maddening that respondents use widespread GPL violation by chip manufacturers as some sort of justification for why Linux is acceptable, but Oracle's JDK is not. Eventually, (slowly but surely) GPL enforcement will adjudicate the widespread problem of poor Linux license compliance — one way or the other. But, that issue is beside the point when we talk of the licenses of code running in userspace. The real issue with that is two-fold.

First, If you think the ecosystem shall collapse because “pure GPL has moved up the Android stack”, and “it will soon virally infect everyone” with copyleft (as you anti-copyleft folks love to say) your fears are just unfounded. Those of us who worked in the early days of reimplementing Java in copyleft communities thought carefully about just this situation. At the time, remember, Sun's Java was completely proprietary, and our goal was to wean developers off Sun's implementation to use a Free Software one. We knew, just as the early GNU developers knew with libc, that a fully copylefted implementation would gain few adopters. So, the earliest copyleft versions of Java were under an extremely weak copyleft called the “GPL plus the Classpath exception”. Personally, I was involved as a volunteer in the early days of the Classpath community; I helped name the project and design the Classpath exception. (At the time, I proposed we call it the “Least GPL” since the Classpath exception carves so many holes in strong copyleft that it's less of a copyleft than even the Lesser GPL and probably the Mozilla Public License, too!)

But, what does the Classpath exception from GNU's implementation have to with Oracle's JDK? Well, Sun, before Oracle's acquisition, sought to collaborate with the Classpath community. Those of us who helped start Classpath were excited to see the original proprietary vendor seek to release their own formerly proprietary code and want to merge some of it with the community that had originally formed to replace their code with a liberated alternative.

Sun thus released much of the JDK under “GPL with Classpath exception”. The reasons were clearly explained (URL linked is an archived version of what once appeared on Sun's website) on their collaboration website for all to see. You see the outcome of that in many files in the now-infamous commit from last week. I strongly suspect Google's lawyers vetted what was merged to made sure that the Android Java SDK fully gets the appropriate advantages of the Classpath exception.

So, how is incorporating Oracle's GPL-plus-Classpath-exception'd JDK different from having an Apache-licensed Java userspace? It's not that much different! Android redistributors already have strong copyleft obligations in kernel space, and, remember that Webkit is LGPL'd; there's also already weak copyleft compliance obligations floating around Android, too. So, if a redistributor is already meeting those, it's not much more work to meet the even weaker requirements now added to the incorporated JDK code. I urge you to ask anyone who says that this change will have any serious impact on licensing obligations and analysis for Android redistributors to please prove their claim with an actual example of a piece of code added in that commit under pure GPL that will combine in some way with Android userspace applications. I admit I haven't dug through the commit to prove the negative, but I'd be surprised if some Google engineers didn't do that work before the commit happened.

You may now ask yourself if there is anything of note here at all. There's certainly less here than most are saying about it. In fact, a Java industry analyst (with more than a decade of experience in the area) told me that he believed the decision was primarily technical. Authors of userspace applications on Android (apparently) seek a newer Java language implementation and given that there was a reasonably licensed Free Software one available, Google made a technical switch to the superior codebase, as it gives API users technically what they want while also reducing maintenance burden. This seems very reasonable. While it's less shocking than what the pundits say, technical reasons probably were the primary impetus.

So, for Android redistributors, are there any actual licensing risks to this change? The answer there is undoubtedly yes, but the situation is quite nuanced, and again, the problem is not as bad as the anti-copyleft crowd says. The Classpath exception grants very wide permissions. Nevertheless, some basic copyleft obligations can remain, albeit in a very weak-copyleft manner. It is possible to violate that weak copyleft, particularly if you don't understand the licensing of all third-party materials combined with the JDK. Still, since you must comply with Linux's license to redistribute Android, complying with the Classpath exception'd stuff will require only a simple afterthought.

Meanwhile, Sun's (now Oracle's) JDK, is likely nearly 100% copyright-held by Oracle. I've written before about the dangers of the consolidation of a copylefted codebase with a single for-profit, commercial entity. I've even pointed out that Oracle specifically is very dangerous in its methods of using copyleft as an aggression.

Copyleft is a tool, not a moral principle. Tools can be used incorrectly with deleterious effect. As an analogy, I'm constantly bending paper clips to press those little buttons on electronic devices, and afterwards, the tool doesn't do what it's intended for (hold papers together); it's bent out of shape and only good for the new, dubious purpose, better served by a different tool. (But, the paper clip was already right there on my desk, you see…)

Similarly, while organizations like Conservancy use copyleft in a principled way to fight for software freedom, others use it in a manipulative, drafter-unintended, way to extract revenue with no intention standing up for users' rights. We already know Oracle likes to use GPL this way, and I really doubt that Oracle will sign a pledge to follow Conservancy's and FSF's principles of GPL enforcement. Thus, we should expect Oracle to aggressively enforce against downstream Android manufacturers who fail to comply with “GPL plus Classpath exception”. Of course, Conservancy's GPL Compliance Project for Linux developers may also enforce, if the violation extends to Linux as well. But, Conservancy will follow those principles and prioritize compliance and community goodwill. Oracle won't. But, saying that means that Oracle has “its hooks” in Android makes no sense. They have as many hooks as any of the other thousands of copyright holders of copylefted material in Android. If anything, this is just another indication that we need more of those copyright holders to agree with the principles, and we should shun codebases where only one for-profit company holds copyright.

Thus, my conclusion about this situation is quite different than the pundits and link-bait news articles. I speculate that Google weighed a technical decision against its own copyleft compliance processes, and determined that Google would succeed in its compliance efforts on Android, and thus won't face compliance problems, and can therefore easily benefit technically from the better code. However, for those many downstream redistributors of Android who fail at license compliance already, the ironic outcome is that you may finally find out how friendly and reasonable Conservancy's Linux GPL enforcement truly is, once you compare it with GPL enforcement from a company like Oracle, who holds avarice, not software freedom, as its primary moral principle.

Finally, the bigger problem in Android with respect to software freedom is that the GPL is widely violated on Linux in Android devices. If this change causes Android redistributors to reevalute their willful ignorance of GPL's requirements, then some good may come of it all, despite Oracle's expected nastiness.

Update on 2016-01-06: I specifically didn't mention the lawsuit above because I don't actually think this whole situation has much to do with the lawsuit, but if folks do want to read my analysis of the Oracle v. Google lawsuit, these are my posts on it in reverse chronological order: [0], [1], [2], [3]. I figured I should add these links given that all the discussion on at least one forum discussing this blog post is about the lawsuit.


Key Charities That Advance Software Freedom Are Worthy of Your Urgent Support   


[ This blog was crossposted on Software Freedom Conservancy's website. ]

I've had the pleasure and the privilege, for the last 20 years, to be either a volunteer or employee of the two most important organizations for the advance of software freedom and users' rights to copy, share, modify and redistribute software. In 1996, I began volunteering for the Free Software Foundation (FSF) and worked as its Executive Director from 2001–2005. I continued as a volunteer for the FSF since then, and now serve as a volunteer on FSF's Board of Directors. I was also one of the first volunteers for Software Freedom Conservancy when we founded it in 2006, and I was the primary person doing the work of the organization as a volunteer from 2006–2010. I've enjoyed having a day job as a Conservancy employee since 2011.

These two organizations have been the center of my life's work. Between them, I typically spend 50–80 hours every single week doing a mix of paid and volunteer work. Both my hobby and my career are advancing software freedom.

I choose to give my time and work to these organizations because they provide the infrastructure that make my work possible. The Free Software community has shown that the work of many individuals, who care deeply about a cause but cooperate together toward a common goal, has an impact greater than any individuals can ever have working separately. The same is often true for cooperating organizations: charities, like Conservancy and the FSF, that work together with each other amplify their impact beyond the expected.

Both Conservancy and the FSF pursue specific and differing approaches and methods to the advancement of software freedom. The FSF is an advocacy organization that raises awareness about key issues that impact the future of users' freedoms and rights, and finds volunteers and pays staff to advocate about these issues. Conservancy is a fiscal sponsor, which means one of our key activities is operational work, meeting the logistical and organizational needs of volunteers so they can focus on the production of great Free Software and Free Documentation. Meanwhile, both Conservancy and FSF dedicated themselves to sponsoring software projects: the FSF through the GNU project, and Conservancy through its member projects. And, most importantly, both charities stand up for the rights of users by enforcing and defending copyleft licenses such as the GNU GPL.

Conservancy and the FSF show in concrete terms that two charities can work together to increase their impact. Last year, our organizations collaborated on many projects, such as the proposed FCC rule changes for wireless devices, jointly handled a GPL enforcement action against Canonical, Ltd., published the principles of community-oriented GPL enforcement, and continued our collaboration on We're already discussing lots of ways that the two organizations can work together in 2016!

I'm proud to give so much of my time and energy to both these excellent organizations. But, I also give my money as well: I was the first person in history to become an Associate Member of the FSF (back in November 2002), and have gladly paid my monthly dues since then. Today, I also signed up as an annual Supporter of Conservancy, because I'm want to ensure that Conservancy's meets its current pledge match — the next 215 Supporters who sign up before January 31st will double their donation via the match.

For just US$20 each month, you make sure the excellent work of both these organizations can continue. This is quite a deal: if you are employed, University-educated professional living in the industrialized world, US$20 is probably the same amount you'd easily spend on a meals at restaurants or other luxuries. Isn't it even a better luxury to know that these two organizations can have employ a years' worth of effort of standing up for your software freedom in 2016? You can make the real difference by making your charitable contribution to these two organizations today:

Please don't wait: both fundraising deadlines are just six days away!

Next Page: 25
00 02 04 06 08 10 12 14 16 18 20 22 
2020-08-12 22:41:57