Software Freedom Law Center

December 7, 2009 by Bradley M. Kuhn

The Anatomy of a Modern GPL Violation

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

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

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

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

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

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

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

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

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

Posted by Bradley M. Kuhn on December 7, 2009

Tags: gpl, copyright, enforcement, licensing

November 9, 2009 by Bradley M. Kuhn

GPL Enforcement: Don't Jump to Conclusions, But Do Report Violations

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted by Bradley M. Kuhn on November 9, 2009

Tags: infringement, gpl, copyright

November 4, 2009 by Bradley M. Kuhn

Android/Linux's Future and Advancement of Mobile Software Freedom

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

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

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

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

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

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

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

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

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

Posted by Bradley M. Kuhn on November 4, 2009

Tags: technology, mobile

October 26, 2009 by Bradley M. Kuhn

Software Freedom on Mobile Devices

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

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

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

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

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

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

Posted by Bradley M. Kuhn on October 26, 2009

Tags: licensing

October 19, 2009 by Bradley M. Kuhn

“Open Core” Is the New Shareware

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted by Bradley M. Kuhn on October 19, 2009

Tags: gpl, copyright, licensing

October 11, 2009 by Bradley M. Kuhn

Denouncing vs. Advocating: In Defense of the Occasional Denouncement

[ Crossposted from Bradley M. Kuhn's personal blog. ]

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted by Bradley M. Kuhn on October 11, 2009

Tags: advocacy

July 29, 2009 by Bradley M. Kuhn

Microsoft Releases GPL'd Software (Again): Does This Change Anything?

[ Crossposted from Bradley M. Kuhn's personal blog. ]

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

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

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

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

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

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

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

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

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

Posted by Bradley M. Kuhn on July 29, 2009

Tags: xen, gpl, enforcement, licensing, microsoft

July 17, 2009 by Bradley M. Kuhn

Microsoft Patent Aggression Continues Against Free Software

[ Crossposted from Bradley M. Kuhn's personal blog. ]

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

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

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

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

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

Posted by Bradley M. Kuhn on July 17, 2009

Tags: patents

June 29, 2009 by Bradley M. Kuhn

Considerations on Patents that Read on Language Infrastructure

[ Crossposted from Bradley M. Kuhn's personal blog. ]

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

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

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

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

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

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

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

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

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

Finally, I close with the advice that I and my colleagues at SFLC constantly give Free Software projects: don't be paralyzed with fear over software patents. There are likely some USA patents that read on any software you write. Make good choices (like avoiding C#, as RMS suggests, and favoring languages like Perl, Python, PHP and C), and get on with your work. If, as a non-profit Free Software developer, someone writes you a threatening letter about patents or sues you for patent infringement, write to <help@softwarefreedom.org>; that's what SFLC is there for.

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

Posted by Bradley M. Kuhn on June 29, 2009

Tags: licensing, patents, community

May 12, 2009 by Bradley M. Kuhn

Support Your Friendly Neighborhood FLOSS Charities

[ Crossposted from Bradley M. Kuhn's personal blog. ]

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

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

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

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

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

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

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

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

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

Posted by Bradley M. Kuhn on May 12, 2009

Tags: community, non-profits