Emerging Technologies

Is BusyBox Too Dangerous To Use?

Edward J. Naughton (enaughton@brownrudnick.com) — Fri, 3 Feb 2012 16:06:25 -0500

Rob Landley thinks so. One of the principal developers of BusyBox, Landley was a lead plaintiff in some of the enforcement actions brought by the Software Freedom Law Center a few years ago. He’s now leading up a project, called Toybox, to rewrite BusyBox and release it under a more permissive, non-GPL license. And for doing that, Landley’s drawn a lot of fire from free software advocates.

I wrote about the BusyBox lawsuits a few months ago. BusyBox itself is a lightweight set of utilities licensed under GPLv2 that is widely used in embedded Linux devices. It’s been a vital tool in a GPL enforcement campaign by the Software Freedom Law Center (SFLC) and Software Freedom Conservancy (SFC).

Those enforcement demands and lawsuits generally involved consumer devices such as BluRay/DVD players, DVRs, and wireless routers. The devices included Busybox, but the manufacturers or distributors of the devices (including Cisco, Verizon, Best Buy, and others) allegedly failed to provide the corresponding source code for Busybox.

Landley and his colleague Erik Andersen, represented by the SFLC/SFC, took the position that the failure to provide source code as required by GPLv2 (a) automatically terminated the licensees’ right to distribute GPLv2 code, and (b) could not be cured simply by providing the corresponding source after the fact, but required the licensees to obtain the express permission of the relevant copyright holders. The SFLC/SFC and the copyright holders apparently demanded many concessions from the licensees before agreeing to reinstate the license, including the release of source code for a number of proprietary libraries and programs, as well as the right to review all of the code for new products prior to their release to ensure GPL compliance.

Busybox was critical to the SFLC/SFC’s strategy. First, it was found in many consumer devices. Second, in many cases the companies targeted by the SFLC/SFC had simply manufactured or distributed products that included chips on which the BusyBox code had been embedded. The targeted companies, therefore, had to obtain the corresponding BusyBox source code from their upstream chip supplier. As a practical matter, it was generally difficult for these companies to obtain the right version of the code. Taken together, these factors gave the SFLC/SFC tremendous leverage.

This is exactly why Landley says that "GPLv2 BusyBox is legally speaking one of the most _dangerous_ pieces of software you can ship." According to Landley, he initially became involved in the BusyBox lawsuits because he thought that they would improve the software:

when I thought that hooking up with a lawfirm to launch BusyBox license enforcement lawsuits would result in any code added to the BusyBox repository, THAT was naive. Zealots grabbed that and used it to inflict completely unrelated crap like "license compliance officers" sending reports to the Free Software Foundation (which WAS NOT INVOLVED, yet somehow managed to hijack this to further their own agenda).

Landley now believes that the lawsuits were a bad idea:

The BusyBox lawsuits are something I personally started. They were a bad idea, they have done more harm than good (I have personal, firsthand experience with this), and it's my responsibility to stop them.

On an engineering note, they never contributed a single line of code to BusyBox. NOT ONE. I thought they would, but they didn't, so I stopped pursuing them.

Instead they were picked up by zealots to pursue a wider agenda that had NOTHING TO DO WITH MAKING BUSYBOX A BETTER PIECE OF SOFTWARE. You yourself admit that this is what happened, and the idea of STOPPING this is exactly what you are objecting to.

I'm an engineer. I respond to problems by writing code.

Zealots respond to problems by telling OTHER people what they "should" do, and freaking out when they don't do it.

Landley explains that he wants to rewrite BusyBox under a non-GPL permissive license to "stop BusyBox from being used as a bludgeon against the world at large."

The BusyBox license enforcement lawsuits were a HORRIBLE IDEA, I regret having started that ball rolling, I couldn't stop it. I can only render it irrelevant with fresh development.

But others, particularly Matt Garrett, have excoriated Landley, because they believe that creating a non-GPL alternative to BusyBox will make it easier for others to violate the GPL:

the reason for writing this replacement isn't to avoid infringing Busybox's license, as such, but to avoid Busybox being used as a tool to enforce the license of other GPLed code (primarily the Linux kernel). . . .

The problem of vendors wilfully violating the GPL isn't one that can be solved by writing code. People who own the copyright to bodies of BusyBox have chosen to enforce that copyright as part of a larger overall strategy to force vendors to release the source code to other GPLed works that they're infringing. They have the right to do that. You're choosing to work on a replacement for BusyBox in order to make it easier for people to avoid enforcement actions. You also have the right to do that. I think your approach results in us seeing a larger number of wilful GPL violations than would otherwise be the case, but it's absolutely your choice.

For his part, Landley has little good to say about the SFLC/SFC:

I wrote up fairly extensive guidelines about what I did and did not consider infringement:

http://lists.busybox.net/pipermail/busybox/2008-October/033327.html

I.E. using vanilla unmodified code is not infringing, we just want your IMPROVEMENTS. I did'nt care about forcing you to mirror source tarballs like the FSF did to Mepis, or exploiting crazy loopholes. If you honestly haven't got any code we'd want, there's nothing in it for us.

The SFLC/SFC didn't work that way. They wanted settlement money so they could afford to file the next suit, and they used BusyBox to sue over OTHER software packages which is disingenuous.

So from my point of view, "Is your code vanilla unmodified BusyBox" could be answered "yes". From the SFLC's point of view, the answer had to be accompanied with a $20k check and the right to go through your refrigerator looking for expired mattress tags.

I'm aware that you care deeply about the mattress tags, but you're being a slimy weasel exploiting other people's loopholes to get your way, and you're upset that the loophole is closing. You find it an INJUSTICE that the loophole may no longer be leverageable for unrelated purposes.

Both Landley and Garrett are passionate advocates for FOSS, but it’s evident that they view the problem from diametrically opposite perspectives. Garrett sees GPL non-compliance as a serious problem that will be made bigger by the loss of BusyBox as a tool for enforcement. Landley believes that the BusyBox litigation hurt the adoption of Linux and other GPL’d code. Landley’s collaborator Tim Bird sums it all up soberly and succinctly:

Matthew correctly points out that the busybox litigators use busybox as a leverage for asking for more than just the busybox source. I believe they do not have this right (either legally or morally). It is this aspect of the situation that some companies find undesireable. It represents a business risk that is beyond the value that busybox provides.

The intent of this project is not to shield GPL violators. It is intended to prevent violation in the first place. I view the need for this project with some sadness, as I myself have worked hard for many years to encourage GPL compliance. I will continue to do so.

I think that reducing the legal uncertainty involved with using GPL software increases the likelihood of adoption and compliance. This is in stark contrast to the direction that the SFC has taken with their re-compliance requirements.

What Matthew argues here is that the ends justify the means, in terms of GPL enforcement. I respectfully disagree.

Landley and Bird have framed the problem well, but they can’t solve it simply by rewriting BusyBox. In his response to Landley, Bradley Kuhn declares that "I’m here to enforce the GPL," and Garrett himself urges Linux kernel copyright holders to step into the breach left by Landley. "The mushroom cloud of legal uncertainty" surrounding the GPL and the Linux kernel will continue.

Legal Issues In Open Source: What to Expect in 2012

Edward J. Naughton (enaughton@brownrudnick.com) — Mon, 30 Jan 2012 12:35:58 -0500

It’s traditional in late December to take a look back at the past year and review the top stories, and there are plenty of pieces that review the developments in open source in 2011: Sean Gallagher’s article at Ars Technica, Stephen J. Vaughn-Nichols’ recap of the top five Linux stories, and Mark Radcliffe’s take.

As you’d expect, pretty much everyone who made a list of top stories included Linux’s twentieth birthday, the dramatic rise of the Android mobile operating platform, and the resulting mobile phone patent wars.

It’s always more dangerous to make predictions than it is to summarize what’s already happened, but I thought I’d take a stab. Here are a few of the big stores that I think we’ll see in 2012.

I’ll start with a safe pick: expect the smart phone IP wars to continue. The federal court in San Francisco has scheduled a mid-April trial on Oracle’s patent and copyright infringement claims against Google. Microsoft is still slugging it out with Motorola and Barnes & Noble. Apple and Samsung continue to battle it out in courts around the world. And there’s a new entrant: Kodak, which asserted digital imaging patents against Apple, HTC, and Samsung as it filed for bankruptcy.

Next, I think that there will be an increased awareness of security issues in Linux and Android. The conventional wisdom has been that Linux and open source systems were more secure than systems running proprietary code because the community could review the code and discover and fix any security vulnerabilities. This view may have been a bit too rosy. In August, kernel.org, the network of servers that host and distribute the Linux code, was hacked and was taken out of service for a couple of months. And as Android and other open source systems have increased their market share in consumer devices, they’ve increasingly become the targets of hackers and malware. The Android Market has been a significant vector for malware because, unlike Apple’s iStore, it’s uncurated. But some of the malware, like CarrierIQ, was authorized by Android device makers and/or carriers. To be sure, CarrierIQ was installed on iPhones and Blackberrys as well as Android devices, and the availability of Android source code helped researchers find the code, but users can no longer take comfort in the idea that open source systems are necessarily more secure than closed systems.

Another trend to watch: the continued movement by developers away from the GPL and other copyleft licenses in favor of more permissive licenses like Apache and BSD. Google’s release of Android under the Apache license rather than GPLv2 is perhaps the most prominent example, but an analysis of data from Black Duck Software shows that this trend is growing and accelerating. Many commercial open-source projects, particularly vendor-led projects, prefer permissive licenses because they make it easier to build proprietary enhancements around open-source code without having to give that proprietary code back to the community.

This trend makes sense for commercial developers, who profit from their proprietary enhancements, but it has generated or aggravated schisms in the FLOSS community. The free software advocates who embrace the GPL are showing increasing impatience with commercial developers who use free software but fail to comply with the license terms. Android device makers are notoriously bad in complying with their GPL obligations. The angry rhetoric from free software advocates has escalated because they perceive that Google has failed, perhaps deliberately, to lead the Android community and ensure that Android device makers comply with their GPL obligations. Those who prefer the commercial open source model have been equally strident in their attacks on free software advocates.

Given these simmering resentments, I would expect to see enforcement actions and litigation brought by free software advocates, particularly against Android device makers. Harald Welte, one of the leading enforcers of the GPL, has threatened to take enforcement actions against HTC, and others have made similar noises about Barnes & Noble’s Nook tablet. Only time will tell whether these tactics will lead to a FLOSS ecosystem that’s more vibrant or more divided.

The Accidental Android TouchPad: Further Developments

Edward J. Naughton (enaughton@brownrudnick.com) — Thu, 10 Nov 2011 14:25:03 -0500

As I wrote a few weeks ago, it seems that a few of HP’s now discontinued TouchPads shipped with Android 2.2, or FroYo, installed. The TouchPad was a WebOS-powered tablet, but somehow at least a few units had Android installed. It’s thought that these were test units that were never meant to be sold.

A developer leading an open source project to port Android to the TouchPad has demanded that HP provide the source code for the modified version of the Linux kernel that is embedded in these units. HP declined, because it doesn’t officially support Android on the TouchPad and didn’t authorize the shipment of devices with Android embedded.

At the time, I observed that a Linux copyright holder could cause trouble for HP by invoking Section 4 of GPLv2, which has been construed by the Software Freedom Law Center and the Free Software Conservancy to automatically and permanently terminate the rights granted by the GPLv2.

As it happens, the developer at issue owns copyrights on various files in the Linux kernel, and he seems intent on using those copyrights to pressure HP to release the source code for the GPL’d portions of Android. Now it appears that a law firm has sent a demand letter on his behalf.

How will this play out? Stay tuned.

Bionic Revisited: What the Summary Judgment Ruling in Oracle v. Google Means for Android and the GPL

Edward J. Naughton (enaughton@brownrudnick.com) — Wed, 9 Nov 2011 16:43:33 -0500

In September, Judge William Alsup, the federal judge presiding over the Oracle v. Google lawsuit, rejected Google’s arguments that software application programming interface (API) specifications are per se unprotected by copyright. That order, which is consistent with the legal precedent, will have significant implications for the dispute between Oracle and Google. The court has not yet decided that Google infringed Oracle’s copyrights in the Java APIs and code - the trial has been delayed until next year - but Google now has a tough hill to climb: at trial, it will need to walk through each of the 37 APIs and 12 code files one by one and demonstrate for each that there was no infringement.

To learn more, please click here.

Android’s Bionic Problem Is Not "Bogus": Why Judge Alsup Got It Right And Linus Torvalds Got It Wrong

Edward J. Naughton (enaughton@brownrudnick.com) — Tue, 8 Nov 2011 16:34:18 -0500

In September, federal judge William Alsup denied Google’s request for a ruling that the Java application programming interfaces ("APIs") were, categorically, not protected under copyright law. In that order, which came in Google’s litigation with Oracle over Google’s use of Java in its Android mobile operating system, Judge Alsup ruled that each of the disputed files must be analyzed individually to determine whether it is protected by copyright. He also ruled that even if the individual files are ultimately determined not to be copyrightable, the selection and arrangement of those unprotected elements may nevertheless show creativity that is entitled to copyright protection.

Android’s use of Oracle’s Java isn’t the only example of Google’s cavalier attitude toward copyrights. Judge Alsup’s order didn’t address Android’s Bionic library, which I analyzed back in March, but his reasoning can be readily applied there, too. As I explained, when Google created the Bionic library, it attempted to work around GPLv2 by using an automated script to "clean" the Linux kernel headers. After analyzing the code in several files, I concluded that Google’s categorical, automated approach to "clean" the headers didn’t work as a matter of copyright law, and I observed that Google’s methods provided an easy bypass of the GPL for commercial exploitation.

My observations piqued the curiosity of a number of journalists and bloggers, and several recognized the implications of Google’s approach. It didn’t take long for Google supporters (and, surprisingly, some free software advocates) to go on the attack. After much sturm und drang in the Android community, Linus Torvalds himself reportedly declared that the idea "seems totally bogus." He admitted, however, that he had not bothered to review the code or my analysis of Google’s approach to "cleaning" the Linux kernel header files. Although Linus has emphasized that he speaks only for himself and not for any of the other contributors who hold copyrights in the Linux kernel, critics of my analysis nevertheless declared it "debunked," on the basis little more than a flippant quote from Torvalds in a blog.

Another blogger who criticized my initial analysis declared that "It Is Not That Simple." At least he got that part right, but that was my very point, and it is also the point that Judge Alsup made in his recent order: the copyrightability of the Java APIs and the Linux kernel headers cannot be determined on a categorical basis. It’s necessary to examine the files themselves, perform a complex analysis of the code, and properly apply copyright law. I did that in my first paper, and I’ve done it further in this new white paper. That analysis leads me to the conclusion that Google’s approach doesn’t work. But if it does work, if the guardians of the Linux kernel and the GPL believe that it is acceptable to use an automated process to "clean" GPL’d headers or code so that you can re-distribute them under a non-copyleft license, that fact should be made clear so that the uncertainty and doubt is dispelled for good.

Poor Software Design as an Unfair and Deceptive Act: The Lessons of FrostWire

Edward J. Naughton (enaughton@brownrudnick.com) — Wed, 26 Oct 2011 16:09:16 -0400

It was inevitable that malware would eventually target smartphones. The mobile devices are ubiquitous, and they can store quite a lot of valuable private data. Downloaded apps - projected to reach a staggering 29 billion for 2011 - provide an easy vector for infection.

As Android’s market share has grown, it’s become a big target for malware, especially because the Android Market is unregulated, in contrast to the curated Apple AppStore. InfoWorld called the Android Market a "malware cesspool."

It’s become all too common to see reports of mobile malware appear with increasing frequency. The scourge comes in many forms: disguised as e-book readers or mini-browsers or other apps, they can vacuum up and steal your data, or trick you into registering and paying for a premium service, or root and gain control of your phone, or grab all of your SMS messages including bank authentication codes.

Even some legitimate apps are designed to behave in ways that seem a lot like malware, accessing permissions that go beyond what’s really needed. So it comes as welcome news to hear of the FTC’s recent enforcement action against FrostWire. FrostWire developed a popular peer-to-peer file sharing app, called FrostWire for Android, that was available for free in the Android Market. When users downloaded and installed the FrostWire for Android app, they were presented with a dialog box that allowed them to choose which types of files - photos, videos, music, documents, etc. - they wanted to share. According to the FTC, "FrostWire had configured the application’s default settings so that, immediately upon installation and set-up, it would publicly share users’ photos, videos, documents, and other files stored on those devices." If a user didn’t uncheck the boxes upon installation, all files in that category would be publicly available for sharing. The user could change those settings later, but it was difficult to figure out how to do that. The FTC filed suit against FrostWire in federal court in Miami, contending that FrostWire had committed unfair and deceptive acts by configuring the default settings in a way that would cause users to share all their files unwittingly. FrostWire settled the case, agreeing to the entry of an injunction that required it to make changes to the app, including the default settings, which FrostWire apparently has done. Google has nevertheless banned the app from the Android Market.

From a legal standpoint, the FrostWire matter is especially interesting because the FTC’s claim wasn’t based on false or misleading statements but on the design of the software. It also offers a cautionary tale for app developers: don’t write your apps to ask for more permissions than they need, and be smart about choosing the default privacy settings.

The Accidental Android TouchPad: Why It’s Important to Manage Software Supply Chain Risks

Edward J. Naughton (enaughton@brownrudnick.com) — Thu, 29 Sep 2011 14:31:59 -0400

For a time, it seemed that HP couldn’t give away its TouchPad tablet. Then it killed the device and announced a fire sale liquidation. Giving them away wasn’t the problem any longer -- HP couldn’t handle the demand as the remaining inventory flew off the shelves.

Now there’s a clamor for HP to give away something else: the source code for a version of Android that somehow found its way onto at least some of the devices that HP shipped.

The exact details are murky, but it seems that at least a few of the WebOS-powered TouchPads actually shipped with Android 2.2, or Froyo, installed. Because the Android software on these units shows a Qualcomm Innovation Center logo, the best guess is that these were Qualcomm test units (Qualcomm supplies the processors for the TouchPad). They were never meant to be shipped and sold, but somehow they were.

The story is more than an embarrassment for HP. There are open source projects underway to port Android to the TouchPad, and the developer leading one of those projects has demanded that HP provide the source code for the modified version of Linux embedded in these units. So far, HP has declined, because it doesn’t officially support Android on the TouchPad.

This is all interesting enough in its own right, but what makes it really fascinating is that a developer who sent a demand to HP claims that he owns the copyright on certain code included in the Linux kernel.

In other words, the hotly debated question of whether Section 4 of GPLv2 automatically and permanently terminates your license upon noncompliance may not be hypothetical. If Linux copyright holder invoked Section 4, he could cause real headaches for HP, which distributes many products running Linux.

Managing the supply chain for a complex hardware or software product has never been easy. This story shows why it is so important and how high the stakes can be.

Is the FSF more harmful to FOSS than Android?

Edward J. Naughton (enaughton@brownrudnick.com) — Wed, 28 Sep 2011 09:11:58 -0400

A couple of weeks ago I noted the conversation in the FOSS community over Google’s closed development of the "open" Android mobile operating system. That debate was sparked by the publication of some internal Google documents that instructed its Android team: "Do not develop in the open."

That internal directive contrasted sharply with Google’s public statements. In the Oracle v. Google lawsuit, for instance, Google filed an answer in which it insists that Android is an "open platform -- a platform that provides equal access to any who would choose to develop software for the platform." According to Google, the "objective of Android is an open and shared product that each contributor can freely tailor and customize . . . the success of the Android platform is due in large part to its open nature, which benefits the entire open source community of consumers, developers, manufacturers, and mobile operators."

Last week, Richard Stallman, the founding figure of the free software movement, weighed in on Android in The Guardian. Stallman acknowledged that "most of the source code of some versions of Android has been released as free software," but because Google had refused to release the Honeycomb code, he observed that "Android 3, apart from Linux, is non-free software, pure and simple." He also noted that "even the executables that are officially part of Android may not correspond to the source code Google releases" because device manufacturers often don’t release the source for the executable version that actually ships on the devices. Stallman’s summary: Android phones are "less bad" than proprietary smartphones but still do not respect freedom.

Stallman’s take on Android is hardly surprising, and he doesn’t say much that others haven’t already said. What is surprising is the vehemence of the response to Stallman from Android apologists: one leading open source blogger lambastes Stallman for engaging in "repugnant partisanship," while another accuses him of spreading anti-Android FUD.

Talk about shooting the messenger. Google’s approach to using free and open source software in Android has been unorthodox, to put it mildly: It used scripts in an effort to "clean" the Linux kernel headers of copyleft. It has withheld the vast majority of the source code for Android 3.0. It has walled off Android from the rest of mobile Linux, not accepting contributions from the community and contributing little itself to the upstream Linux stack. And it has subsidized an ecosystem of Android device manufacturers that has been notoriously lax at GPL compliance.

So instead of attacking Stallman, who has simply called out the problems with the "open" Android platform, maybe these commentators should join him, and call on Google to make Android truly open, or even free.

Google’s Closed Development of Android Opens Old Wounds

Edward J. Naughton (enaughton@brownrudnick.com) — Mon, 12 Sep 2011 17:50:55 -0400

Does "open source" mean developing in the open? Or is it good enough – legally and morally – to publicly release the code after the fact, when the next release is ready for market? Is transparency a defining value of the open source community, perhaps even the most important value? Or is it equally valid, and perhaps a better business practice, to keep development closed?

That debate is raging in the open source community following the recent publication of internal Google documents that bluntly set out the company’s strategy for developing Android: “Do not develop in the open.” The articles, like this one at The Register, set out the news story, but the real action is in the comments. This posting by Scott M. Fulton, III, over at ReadWriteHack, has generated some thoughtful commentary as well.

There’s a similar divergence of views, to put it mildly, over Barbara Hudson’s four-part article on termination under Section 4 of GPLv2. Hudson excoriated the FSF and SFLC – using terms like "GNUstapo" – and rejected their position that Section 4 automatically terminates rights under the GPLv2. She argues that rights can be reinstated simply by coming into compliance and downloading a new copy of the license. If her argument is correct, compliance with the GPLv2 becomes much easier. Those who enforce the GPL argue that her argument would "eviscerate" the license; others complain that the FSF’s reading allows it to "take hostages."

The free, libre, and open source community has always been marked by yin-yang. Today’s quarrels echo the row in the late 1990s between Richard Stallman, who insisted that "free software" was essential to freedom, and Eric Raymond, who rejected Stallman’s ideology and embraced a pragmatic "open source" development model. And now, as Linux turns twenty, Android is both a blessing and a curse.

On the State of Open Source Software: The Marketing and the Reality

Edward J. Naughton (enaughton@brownrudnick.com) — Thu, 8 Sep 2011 12:10:38 -0400

Yesterday Infoworld published a thought-provoking piece by Peter Wayner about the state of open source. Wayner observes that the "open source" label is ubiquitous, but that the freedoms that open source was supposed to bring are much harder to find. Many products are built on open source - the operating systems for iPhone and Android phones, for instance, are governed by open source licenses - but they’re locked down and/or kept in a "secret lair." Enterprise software companies offer community editions of their products, but often as a feature-limited demo version, in the hope of selling upgrades to a commercial license.

But this isn’t anything new. Seven years ago, around the time of those IBM commercials during the Super Bowl declaring that "The Future Is Open," a colleague and I published a couple of papers, including for the Computer Law Association, that examined the transformation of the free software movement and ecosystem. Ieuan G. Mahony and Edward J. Naughton, "Open Source Software Monetized: Out of the Bazaar and into Big Business," 21 The Computer and Internet Lawyer 1 (October 2004) (not available online). After tracing the history of the free software and its embrace by the largest proprietary software companies, we observed that the "open source" label was increasingly used simply as a marketing strategy, to sell their essentially proprietary products.

Plus ça change, plus c’est la même chose.

Open Source License Compliance: It’s Straightforwardly Complicated

Edward J. Naughton (enaughton@brownrudnick.com) — Thu, 25 Aug 2011 15:49:54 -0400

Some of my recent posts on the challenges of compliance with open source licenses have generated a lot of discussion in the FOSS community, as I hoped they would, and I’ll have more to contribute to the discussion in coming posts. But for now, consider this:

Brian Proffitt, discussing my post, assures readers that there’s no cause for concern about termination under Section 4 of GPLv2 and quotes Linux Foundation’s VP Amanda McPherson, who says that "complying with open source licenses is very straightforward." But not long ago, Jim Zemlin, President of the Linux Foundation, acknowledged the very opposite: "Managing open source license compliance is complicated." Complicated enough, in fact, that the Linux Foundation offers fifteen highly technical manuals and tools to manage the compliance process.

Will There Be Any Open Space Left In The Mobile Landscape?

Edward J. Naughton (enaughton@brownrudnick.com) — Fri, 19 Aug 2011 15:20:25 -0400

It’s been a topsy-turvy week for open source in the mobile space.

Google’s Android mobile operating system has been marketed as "open source," free for others to use and modify, in contrast to Apple’s closed iOS and Microsoft’s closed Windows Phone. One of the defining hallmarks of open source software has been the free availability of the source code. Late last week, however, Google asked the International Trade Commission to sanction Microsoft for allegedly disclosing certain "highly confidential" Android source code in connection with an ITC proceeding against Android-powered Motorola smartphones.

Another hallmark of open source, particularly code under free software licenses like the GPLv2, is an opposition to software patents. Many free and open source licenses contain provisions that expressly or implicitly require distributors of open source code to grant licenses to any patents that read on the code they distribute. But late last week, it was reported that Motorola Mobility, one of the largest makers of Android smartphones, had suggested that it might begin asserting its substantial patent portfolio against other Android device makers. Then, on Monday, Google announced that it had agreed to buy Motorola Mobility, primarily to acquire its trove of patents. Google promised that it will continue "to run Android as an open platform," but it’s not immediately evident how it will reconcile its patent holdings with an open Android. Will it make those patents available, royalty-free, perhaps through a mechanism like the Open Invention Network? Is Google willing to do that after paying $12.5 billion to acquire them?

Some glimmers of hope remain. HP announced yesterday that it was exiting the mobile phone and tablet business and scrapping the WebOS mobile operating system. Some have called for HP to open source WebOS. And a few weeks ago the Mozilla Foundation announced its plans to develop an open source mobile operating system. Perhaps there’s still room in the mobile landscape for a truly open solution.

Operating (system) without a license: Does Section 4 of the GPL leave Google and Android device manufacturers unlicensed? (Part 2)

Edward J. Naughton (enaughton@brownrudnick.com) — Tue, 16 Aug 2011 11:08:14 -0400

In my previous post, I explained how Section 4 of GPLv2 plays a critical role in GPL enforcement actions brought by the SFC and the SFLC. By immediately terminating rights for non-compliance and requiring express permission from the licensor to reestablish those rights, Section 4 provides a stout club that can be used against companies who rely on GPL code in their products but fail to adhere to the complicated requirements for that license. In this post, I want to examine what that might mean for an Android ecosystem that is not a model of GPL compliance.

How does Section 4 affect Android OEMs?

As we’ve discussed, GPL compliance is challenging even for those who want to comply. It seems that many in the Android community are not trying that hard, and the GPL compliance record is fairly dreadful. Late last year, a well-known OSS hacker looked into Android tablet compliance and found that most of the device manufacturers are not in compliance with the GPL. As I recently observed, with Honeycomb, the compliance record is even worse.

If the SFC/SFLC position in Best Buy were applied to the Android ecosystem, every device for which a manufacturer has not made all of the GPL source code available is unlicensed and subject to an injunction. Google’s recent posting of some source code on the Android Open Source Project (AOSP) site doesn’t protect OEMs: it’s quite clear that the obligation to provide source code is personal to each and every person in the supply chain, and a commercial entity cannot rely on others to provide the relevant source code. In addition, because the source that Google has posted is a blind dump without any manifest, it is very difficult to determine whether it meets the "corresponding source" requirement of the GPLv2. Google cautions that the Honeycomb source it has released is not "likely to work on actual hardware," and so I suspect that it is not "corresponding source."

What about Google?

To a certain extent, an OEM’s failure to comply with the GPL source distribution may not be Google’s problem, if Google has provided the necessary source to the OEMs and doesn’t restrict them from making it available.

But the provision of source code is not the only obligation imposed by the GPLv2. Section 1 also requires you to redistribute GPLv2-licensed source code under the GPLv2. In other words, you can’t take code that you’ve received under the GPLv2 and release it under another license. This is "license laundering" and a violation of GPLv2 that would trigger Section 4.

A visual examination of the source code for Gingerbread -- the latest complete version of Android that is publicly available - reveals several instances of what appears to be GPLv2-licensed code included in files that are licensed under the Apache License. For example, Android uses "bootcharting" logic, which uses "the 'bootchartd' script provided by www.bootchart.org, but a C re-implementation that is directly compiled into our init program." The license that appears at www.bootchart.org is the GPLv2, not the Apache 2.0 license that Google claims for its implementation.

There are other examples as well, including repurposing of files from the Cygwin and Zenburn projects and the inclusion of a code "modeled after" a script that appears to be from a documentation page from Linux man-pages project at kernel.org. Each of these situations involves original code or content that is licensed under the GPLv2 but which is ostensibly relicensed under the Apache 2.0 in Android. I’ve previously discussed Google’s "washing" of the Linux kernel headers when it created the Bionic library.

Did Google get permission from the original copyright holders to relicense this GPLv2 code and content? It’s possible, but developers that pay attention to GPLv2 compliance typically include a note to that effect in the code comments. Without such permission, the relicensing of that code violates the GPL and triggers Section 4. It would also require Android OEMs to disclose additional source code, beyond what Google has provided on the AOSP, because that code would remain under the GPLv2 despite Google’s attempts to launder the license.

What could this mean for the Android ecosystem?

Any OEM that isn’t providing a GPL-compliant source code distribution - there are few in the phone universe who are and, as far as I can tell, none in the tablet universe - is, according to the SFC/SFLC, unlicensed and does not have the right to distribute Android devices that contain GPLv2-licensed code.

That’s a serious issue, more serious than the situation that led to the BusyBox lawsuits. Unlike many of the BusyBox defendants, each of the Android manufacturers knows that there’s GPLv2 code in their products - Google emphasizes that it has consciously leveraged such code in its development of Android.

Perhaps more intriguing is the likelihood that Google has improperly relicensed GPLv2 code under Apache 2.0. If that is the case, Google itself has probably lost its rights to distribute Android containing that laundered code, and Google would need to obtain the express permission of the relevant copyright holders to resume distributing it.

How will this play out? Will the SFC or another party bring a suit? The facts and the law seem pretty compelling. In Best Buy, the SFC went after a number of parties and sought an injunction against the distribution of an entire product based on the inclusion of just one small GPLv2 component. In those cases, the SFC argued that:

Failing to enjoin blatant violations of open source licenses threatens to erode their effectiveness, which would cause substantial public harm by decreasing the participation in the software distribution model that produces freely available and modifiable software to the world.

If that’s true of a few Blu-Ray players, it seems to be an enormous peril in the case of the Android ecosystem, where the problems - failure to provide any source code and potential license laundering by Google - are much more "blatant violations of open source licenses."

License revoked: Applying Section 4 of the GPL and the lessons of Best Buy to Google’s Android

Edward J. Naughton (enaughton@brownrudnick.com) — Mon, 8 Aug 2011 15:47:33 -0400

Not long ago, open source advocates sued more than a dozen major consumer electronics manufacturers, claiming that the manufacturers had lost the right to use GPL’d software in their devices. It looks like the same could be said of Android: virtually every one is unlicensed.

I recently explained that by failing to make freely available the source code for the GPL’d portions of Honeycomb, Google is forcing its OEM partners to face a number of increasingly unpleasant legal issues. Perhaps in response to the outcry created by its decision, Google made available portions of the source code for Honeycomb, some of it in just the past couple of weeks. Even if that code release could be considered GPL compliant - which is quite doubtful -it doesn’t end the controversy.

The arguments made by the Software Freedom Conservancy (SFC) and the Software Freedom Law Center (SFLC) in Software Freedom Conservancy, Inc. v. Best Buy Co., 09-CV-10155 (S.D.N.Y.), put the entire Android ecosystem in potential legal jeopardy. In the Best Buy case, the SFC and SFLC argued that a violation of the GPLv2 immediately terminates a licensee’s right to distribute covered code and that the licensee cannot remedy its violation by providing the source code after the fact. The express permission of the relevant copyright holders is necessary to reestablish the licensee’s rights.

Given the woeful track record of GPL compliance in the Android ecosystem, that argument would imply that almost every OEM distributing Android devices today is unlicensed, and even Google itself may not be licensed to distribute portions of the Android code.

That is an astonishing situation, one that could have significant repercussions for Android users, distributors, and Google itself. Some may dismiss it reflexively as scaremongering, but that response is just too simple. In this first post, I’ll analyze and explain the legal background of Section 4 of GPLv2. In my next post, I’ll discuss why Section 4 matters for Honeycomb and the risks it creates for the entire Android ecosystem.

The Best Buy Case and GPLv2 Section 4

For many years, there were questions whether the GPL was enforceable. To put an end to those questions, the SFLC and the SFC began to file copyright infringement actions, primarily against manufacturers and distributors of embedded Linux devices. Those cases focused primarily on BusyBox, a set of utilities licensed under GPLv2 that was used in those devices. The SFC and SFLC have ridden these cases to a lot of success.

One of those cases involved Best Buy, the electronics retailer, which distributed a Blu-Ray player with embedded Linux and BusyBox. Most of the BusyBox cases resolved pretty quickly, and those that went to litigation settled well before anything significant happened. The Best Buy case also settled, a few weeks ago, but before it did the SFC and SFLC filed motion for a preliminary injunction to prevent Best Buy from selling the Blu-Ray players even though the BusyBox code had been made available. The court never decided that motion, but the papers submitted in support of and opposition to it provided a lot of insight into the usually opaque area of GPL compliance and enforcement.

The heart of the SFC/SFLC case was Section 4 of the GPLv2, which states that any attempt "to copy, modify, sublicense or distribute" covered code in a way other than provided in the license "is void, and will automatically terminate your rights under this License." The SFC/SFLC insisted that once the defendants violated that section, by failing to distribute the corresponding source for BusyBox, they needed the licensor’s explicit permission to continue to distribute devices containing BusyBox. In other words, after-the-fact compliance with the GPL was a necessary condition, but it was not sufficient to reinstate the defendants’ rights under the GPL. This is not a particularly controversial position: Harald Welte of gpl-violations.org has relied on Section 4 to obtain injunctions against non-compliant GPL distributions in Germany, and there are US precedents supporting the concept that one loses the right to distribute if one violates a copyright license.

This "express permission" requirement really gives teeth to the SFC’s enforcement activities. The SFC can - and does - condition continued distribution on requirements that go far beyond the GPL terms. In its A Practical Guide to GPL Compliance, the SFLC explicitly affirms this power: "Different copyright holders condition reinstatement upon different requirements, and these requirements can be (and often are) wholly independent of the GPL. The terms of your reinstatement will depend upon what you negotiate with the copyright holder of the GPL’d program." Many of the reported settlements in other cases involve (a) the appointment of an "open source compliance officer" to monitor compliance with all GPL programs, not just the one at issue, (b) periodic reporting of those compliance efforts, (c) notification to previous recipients of the GPL’d program, and (d) monetary payments. E.g., BusyBox Developers and Monsoon Multimedia Agree to Dismiss GPL Lawsuit; FSF Settles Suit Against Cisco ; BusyBox Developers Agree To End GPL Lawsuit Against Verizon. According to affidavits filed in the Best Buy case, the SFC demanded that the defendants disclose source code for a number of proprietary libraries and programs, as well as the right to review all of the code for new products prior to their release to ensure GPL compliance. When the defendants refused, the SFC filed a motion seeking an injunction against the continued distribution of the Blu-Ray players at issue.

Complying with the GPL’s source code disclosure obligations is no simple matter; it’s easy to run afoul of them and end up in the unenviable position of facing an SFC/SFLC compliance action and their accompanying demands. First of all, you need to know what it is you have to disclose. Section 3 of the GPLv2 describes the obligation to provide "corresponding source." It’s not enough under that section to simply provide the source code for the component itself. You also need to provide "any associated interface definition files," plus "the scripts used to control compilation and installation of the executable." (Scripts in this situation include any software programs, files, tools, or scripts that are necessary for a user to install a modified version of the program, such as makefiles, configuration files, build scripts, and packaging scripts.) It can be very difficult to satisfy this obligation in the real world: in Best Buy, the defendants provided seven different rounds of proposed compliance information, none of which was deemed adequate.

Even if you get the extent of the "corresponding source" right, you still need to figure out how to make it available properly. Assuming that you are a commercial distributor of GPL code, the source code must be available simultaneously with your binary distribution. The distribution must either have source code accompanying it or come with an offer "valid for at least three years" to provide the source code immediately upon request. You cannot rely on another entity’s offer of code to satisfy your obligation, nor can you simply offer the source code for download. You must make it available on a physical medium - e.g., CD - for anyone who requests it.

How tricky is compliance with the GPL source disclosure obligation? Here’s a data point: last week Slashdot reported that "Emacs, one of GNU's flagship products and the most famous software creation of Richard Stallman, has been discovered to be violating the GPL since 2009-09-28 by distributing binaries that were missing source." Richard Stallman himself commented that "We have made a very bad mistake. Anyone redistributing those versions is violating the GPL, through no fault of his own."

Section 4 of the GPL clearly poses a significant risk for companies who rely on GPL code in their products. One slip-up in the complicated arena of GPL compliance can jeopardize their right to distribute products. In my next post, we’ll see why this matters for Google, its OEMs, and the Android ecosystem generally.

Because Android "Is Not Open Source," The Mozilla Foundation Plans To Build A New MobileOS

Edward J. Naughton (enaughton@brownrudnick.com) — Mon, 8 Aug 2011 15:36:40 -0400

You know how the old saying goes: if you are going to talk the talk, you’d better walk the walk.

Google has long touted Android as "open," but as many (including me) have chronicled, it hasn’t been walking the walk.

Google’s decision to withhold the Honeycomb source code, to overtly privilege some OEMs and partners over others, to implement subjective compatibility requirements, and to make risky licensing decisions (I expect to have more to say about this issue in a future post), has belied its claims that Android is "open." Now it appears that the Mozilla Foundation, developer of the Firefox browser and other popular OSS projects, has had enough. On Monday, Mozilla revealed its plans to develop its own mobile operating system for tablets and smartphones, one that is truly open.

This is a fascinating development. According to eWeek:

The new Mozilla project is known as Boot to Gecko, or B2G, and its goal is to build a complete, stand-alone operating system for the open Web, said Mozilla engineer Andreas Gal in a July 25 blog post. Gecko is Mozilla’s browser layout engine. It appears that Mozilla will begin building out B2G with Android components and Gecko as foundational technologies.

Mozilla’s criticisms of Google’s "openness" were rather pointed:

Android is not open source in the sense of 'open technology.' Android APIs are proprietary Google sauce, not broadly accepted and adopted open web standards. At some point Android used to be at least 'available source' where Google would publish secretly/internally developed source code/technology after the fact as products ship, but even those times seem to be over now. I would love to boot my custom Android build on my Galaxy Tab 10, but no luck, Google refuses to release the source.

We want to do Boot to Gecko the way we think open source should be done. In the open, from day 1, for everyone to see and participate.

Up until now, Android has been marketed as the "open source" mobile operating system. However, in reality, Google has locked down Android in many relevant ways. Mozilla, one of the bastions of open source, is now drawing a line in the sand.

It’s still early, too early to know how this will shape up, but Mozilla’s track record and public statements certainly signal that they are likely to give OEMs and partners far more opportunity to innovate than Google.

This is hardly surprising: Mozilla is a non-profit foundation, not a profit-seeking enterprise. Google, by contrast, uses "openness" because it wants to be everywhere. By offering a free (as in beer, not speech) mobile platform, Google has achieved some ubiquity, which has driven tremendous advertising revenue. Mozilla, on the other hand, has generally been a real and passionate proponent of open web and open access.

Does that mean Mozilla’s solution is the best approach for mobile? No, at this early stage, it’s hard to say much of anything about the project from a technical standpoint. But at least the project appears to be driven by real open source values and can be expected to play by the rules, which is much more than we can say about Android.

What this recent announcement really highlights is that "open source" means something. Google’s handling of Android has raised legal questions that haven’t yet been resolved, but Mozilla’s decision to go its own way shows that the problems are more than just legal. There are serious questions about Google’s treatment of the open source code and the open source community. "Open source" is not just a marketing label for Google to use however it likes, and if the Boot to Gecko project succeeds, some of Google’s "open source" chickens may come home to roost.

Looks like Mozilla will actually try to walk the walk. Bravo.

Brown Rudnick Sponsors Venture Capital Investment Competition at London Business School

Tue, 14 Apr 2009 12:46:32 -0400

Brown Rudnick LLP, an international law firm with offices in the United States and Europe, is sponsoring the Venture Capital Investment Competition (VCIC) at London Business School for 2009. As a continuing sponsor of programs and initiatives that support the global entrepreneurial community, Brown Rudnick represents investors and companies seeking financing. The Firm is the 2008 recipient of the prestigious Investor AllStars Service Provider of the Year Award, which honors a specialist advisory firm serving the venture capital industry for its innovation, creativity and overall contribution in a venture financed deal.

For more information,please click here.

The Institute for Technology Entrepreneurship & Commercialization (ITEC) at Boston University Announces Finalists of 2009 $50k Business Plan Competition

Tue, 14 Apr 2009 12:43:02 -0400

The Institute for Technology Entrepreneurship & Commercialization (ITEC) at Boston University today announced its four finalists for the 2009 $50K Business Plan Competition. The ninth annual competition showcased more than two dozen entries, and included diverse and innovative life science and green solutions.

For more information, please click here.

Brown Rudnick Represents Acme Telepower Group in World’s Largest Pem Fuel Cell Supply Agreement

Tue, 7 Apr 2009 14:54:16 -0400

Brown Rudnick, an international law firm, represented the ACME Group (“ACME”), a leader in the field of innovative infrastructure solutions for the wireless telecom industry, in connection with a high volume fuel cell supply agreement with IdaTech plc (“IdaTech”) and Ballard Power Solutions, Inc (“Ballard”). The natural gas reformed fuel cell systems will provide ACME with 10,000 5kW fuel cell systems -- with an option for another 20,000 -- for exclusive distribution within India and for telecom backup power applications in countries in the Middle East and Africa, excluding South Africa. The systems will provide ACME’s customers with a more economic, reliable and environmentally acceptable product. If all 30,000 units are ordered, it is believed to be the largest supply agreement signed by any PEM fuel cell company.

For more information, please click here.