lacuny.org

Blog post by Lysandra Ohrstrom. Please email any comments on this entry to <Lohrstrom@softwarefreedom.org>.

New York Times reporters John Markoff and Ashlee Vance correctly pointed out that nations, private corporations, and even bands of rogue programmers are capable of covertly tunneling into information systems, by exploiting bugs in a program's source code in their January 20th story, "Fearing Hackers Who Leave no Trace."

Unfortunately, this paragraph appears more than half way through the story. Rather than address the real reasons that proprietary systems are so vulnerable to security breaches or the comparative protections afforded by free software, Vance and Markoff stuck to the usual formula of the Times' technology stories: the "intellectual property" parable. The good guys ("innovative," commercial technology companies like Google and Cisco) struggle to protect the integrity of their source code--their "crown jewels"--from the nefarious designs of the bad guys (hackers).

"If hackers could steal those key instructions and copy them, they could easily dull the company's competitive edge in the marketplace," Vance and Markoff write. "More insidiously, if attackers were able to make subtle, undetected changes to that code, they could essentially give themselves secret access to everything the company and its customers did with that software.”

The ability to make "subtle, undetected changes" to a system's source code is indeed the cause of frequent security breaches, but it is much harder for ill-intentioned hackers to "leave no trace" in free software. The solution is not to block access to source code, as the authors imply, but keep it open so that anyone can detect modifications, see who made them, and why. The reason closed, proprietary systems have proven to be less secure than free software alternatives over the years is more to do with the absence of a third-party audit function and accountability trail, than threats from "hackers."

I can only assume the confusing tangle of inaccuracies, contradictory conclusions, and false assumptions Markoff and Vance reported were fed to them by a PR agent or cobbled together after a day-long conference hosted by the Homeland Security Council. Vance quotes a member of the Council's advisory board, Jeff Moss, in the article he co-wrote with Markoff and in a separate story published under his own byline on January 21, "If your Password is 123456, Just Make It HackMe." Vance describes him as a security expert in the first story and the founder of a popular hackers conference in the second.

As a non-profit law firm for Free and Open Source Software programmers, the SFLC admittedly has a stake in promoting the projects developed by its clients. So rather than take my word for it, listen to the comments of readers like Wai Yip Tung from San Francisco. "This article have a very confused idea around source code and security," Tung writes in a comment. "Have you ever heard of Open Source software? (e.g. Firefox) Everyone has access to its source code but it does not make it any less secure. In fact security expert have an opposite opinion. It is critical that source code is available for audit by a wide range of people before we can have confidence of its security. This is a worthless article in my opinion. It stroke fear in the wrong places and shed little light on where the vulnerability really is.

I have to disagree that their effort was entirely worthless. Markoff and Vance inadvertently ended up writing an unqualified endorsement of free software in The New York Times.

Clarification: The "hackers" who break into computers with the intent to cause harm are distinct from from the community of programmers who create clever solutions to bugs in source code. A more accurate label for the activity in this story is malicious hacking or cracking.

Blog post by Lysandra Ohrstrom. Please email any comments on this entry to <Lohrstrom@softwarefreedom.org>.

The 2010 Consumer Electronics Show (CES) was the best of times and the worst of times for the free software movement.

It proved that the first stage of the revolution that the SFLC, and many others, have long predicted, is complete: free software has been embraced by commercial developers and is now powering a much wider range of embedded devices than any single proprietary program. Behind any one of the smartphones, eBook Readers, netbooks and LCD-televisions that debuted last week at CES is almost certainly a Free and Open Source Software (FOSS) application or platform.

But it also highlighted the extent to which proprietary software developers have taken advantage of the ability to adapt, improve, and customize free software in embedded devices that deny customers these very same freedoms. This is the paradox of free software's growing popularity: anyone can view, modify, and distribute source code, whatever their intentions.

Now that free software is inside almost everything, it is time for users to learn about their rights under free software licenses to protect their freedom to share, tinker, and adapt the devices they buy.

These values, ingrained into our consciousness in kindergarten, are the ones that drive free software innovation and that many of the commercial developers at CES have benefited from, yet hope their customers will forget.

Most of the eBook Readers at CES use free software in locked-down devices that restrict customers' access to certain publications, prevent them from sharing, and violate their privacy. Telecommunications companies have harnessed Android in the battle for a larger share of the smartphone market and collaborated on applications with FOSS programmers while preventing customers the right to chose between carriers. These companies have a vested interest in limiting the functionality of the devices they sell so consumers buy the next model in a couple of years, rather than improve the one they already own.

Individuals can reclaim the rights they take for granted in other commodities by educating themselves and choosing to buy the most free devices whenever possible.

While none of the smartphones or e-readers on the market is perfect, there are options that allow users to retain more choice and control of how a device functions and what content they can access. Choosing a Nokia N900 or a free Android phone over a carrier-subsidized, locked-down model gives customers the option of running any application and making modifications so it is more useful. Readers can chose an open-format e-reader over an alternative that only allows them to download books in proprietary format.

Owners of open-format e-readers can download public-domain content, such as "A Tale of Two Cities," for free from a variety of sources and be able to read and re-read it whenever they want, on multiple devices, forever. Amazon, on the other hand, charges Kindle-owners a license fee for the privilege of reading the free Dickens' classic on their e-readers. Amazon also reserves the right to revoke this license at any time and yank the free book from Kindle-customers who already paid to download it.

At CES 2011, the SFLC predicts that commercial software developers will continue to distract users from these basic rights with sleeker, smaller, and smarter devices that run on free software. The SFLC will continue to fight against people who violate the terms of the GPL by using FOSS in locked-down devices that restrict, rather than empower users. But the second stage of the revolution will be won by individuals who educate themselves about their rights in order to realize the full benefit of free software.

Blog post by Eben Moglen. Please email any comments on this entry to <eben@softwarefreedom.org>.

I spent last Thursday and Friday in Brussels, attending the European Commission’s Oral Hearing in the competition investigation of the acquisition of Sun Microsystems by Oracle. The proceedings at the Oral Hearing were confidential; I cannot write about the presentations made there by others. I can, however, summarize the three points I made during my brief presentation on Friday; my previous written submission to the commission is already available. I want to explain what I said and where I think we stand now that the Oral Hearing is over.

Blog post by Bradley M. Kuhn. Please email any comments on this entry to <bkuhn@softwarefreedom.org>.

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.

Blog post by Bradley M. Kuhn. Please email any comments on this entry to <bkuhn@softwarefreedom.org>.

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.