Displaying posts tagged GPL
September 30, 2015 by Karen Sandler
Last week I had the privilege of delivering Friday's keynote address at Linaro Connect. I was so excited and pleased that I had been asked to speak about compliance there. As Linaro is a consortium for Linux kernel related initiatives on ARM, I was excited and curious as to what the conference was like and thrilled to be given the chance to talk about why copyleft and GPL compliance are so fundamental to the success of collaborative engineering initiatives like Linaro. The fact that the conference is so developer focused was a huge bonus.
One of the topics I touched on, given its newsworthiness was the situation with Volkswagen. Many people have talked about the implications of so-called dieselgate and its implications for free and open source software. In my talk I focused on another aspect of this - engineer and developer culture.
When I was in engineering school at The Cooper Union we had a mandatory course during our first year where we read the book To Engineer Is Human (which incidentally, if you buy you can sign up to support Conservancy on Amazon Smile first). The book discusses prominent engineering failures (including the dramatic Tacoma Narrows Bridge collapse “Galloping Gertie”), why they failed and how such failure is ultimately a part of successful societal engineering. In the class we talked about the culture of engineering ethics and how engineers ultimately have a special responsibility in society on behalf of the people who are impacted by the work they do.
In the recent case of Volkswagen, the failure of the company to behave ethically not only caused a negative impact on the environment and alienated VW's customer base, but also had a massively negative effect on the company's bottom line and financial outlook. How many engineers at the company felt horribly about what was happening and felt powerless to do anything about it? And in that case, the failure of Volkswagen to do the right thing was bad for the company in a number of levels.
As we see that copyleft and best security are linked (I talked about the Honeymoon Effect during the talk, and you can read my old paper on medical device safety plus many great discussions by folks like Matthew Garrett and even Bruce Schneier) and we embark upon an Internet of Things network, the ethical implications of software freedom become all the more poignant. In addition to the ethical aspects inherent in sharing code and the ethical considerations of following a license under which you received software for your use, there's an additional ethics layer in the safety implications of keeping GPL'd code closed. Because software so often interacts in complex ways (as shown in the car vulnerability demonstrations that go through the wheel maintenance system to exploit the critical ignition and brake systems), it's impossible to predict which software the next failure will be based on.
We need companies to understand that complying with the GPL isn't just good community participation or a safeguard from lawsuits - it is fundamental to their longterm financial success in a myriad of ways. Developers play a key role in that process. It's not always easy to stand up for the right thing in a corporate context. Doing so can cause reprisal in the form of some penalty. Obviously, if an engineer had been able to take action at Volkswagen, they would have saved the company a lot of embarrassment and lost revenue but without the hindsight of seeing how that situation actually played out it's likely that there was a real fear of penalty for speaking up.
Fortunately, where copylefted software is involved there are external mechanisms to help with some of these issues. Because companies must make good on providing source when they distribute, an outsider could determine that a company is not meeting its obligations. This is the main reason why having the option of participating anonymously in our coalition of developers who want to enforce the GPL is so important. In software development, coming out in favor of enforcement may not cause you any negative repercussions with your current employer but many developers rightly worry that other future employers may negatively view their participation in the coalition.
In the same vein as my ethical education in engineering school, developers should include the long term ethical considerations in their core technical analysis of what free and open source software licenses their companies should use and how they comply with it on a long term basis. While failures are terrible to have, they're essential to learn from and work towards better technical and ethical infrastructure.
Posted by Karen Sandler on September 30, 2015
September 29, 2015 by Bradley M. Kuhn
Would software-related scandals, such as Volkswagen's use of proprietary software to lie to emissions inspectors, cease if software freedom were universal? Likely so, as I wrote last week. In a world where regulations mandate distribution of source code for all the software in all devices, and where no one ever cheats on that rule, VW would need means other than software to hide their treachery.
Universal software freedom is my lifelong goal, but I realized years ago that I won't live to see it. I suspect that generations of software users will need to repeatedly rediscover and face the harms of proprietary software before a groundswell of support demands universal software freedom. In the meantime, our community has invented semi-permanent strategies, such as copyleft, to maximize software freedom for users in our current mixed proprietary and Free Software world.
In the world we live in today, software freedom can impact the VW situation only if a few complex conditions are met. Let's consider the necessary hypothetical series of events, in today's real world, that would have been necessary for Open Source and Free Software to have stopped VW immediately.
First, VW would have created a combined or derivative work of software with a copylefted program. While many cars today contain Linux, which is copylefted, I am not aware of any cars that use Linux outside of the on-board entertainment and climate control systems. The VW software was not part of those systems, and VW engineers almost surely wrote the emissions testing mode code from scratch. Even if they included some non-copylefted Open Source or Free Software in it, those licenses don't require disclosure of any source code; VW's ability to conceal its bad actions with non-copylefted code is roughly identical to the situation of proprietary VW code before us. As a thought experiment, though, let's pretend, that VW based the nefarious code on Linux by writing a proprietary Linux module to trick the emissions testing systems.
In that case, VW would have violated the GPL. But that alone is far from enough to ensure anyone would catch VW. Indeed, GPL violations remain very prevalent, and only one organization, Conservancy, enforces the GPL for Linux. Conservancy has such limited enforcement resources (only three full-time people on staff, and enforcement is one of many of our programs), I suspect that years would pass before Conservancy had the resources to pursue the violation; Conservancy currently has hundreds of Linux GPL violations queued for action. Even once opened, most GPL violations take years to resolve. As an example, we are currently enforcing the GPL against one auto manufacturer who has Linux in their car. We've already spent hundreds of hours and the company to date continues to fail in their GPL compliance efforts. Admittedly, it's highly unlikely that particular violator has a GPL-violating Linux module specifically designed to circumvent automotive regulations. However, after enforcing the GPL in that case for more than two years, I still don't have enough data about their use of Linux to even know which proprietary Linux modules are present — let alone whether those modules are nefarious in any way other than as violating Linux's license.
Thus, in today's world, a “software freedom solution” to prevent the VW scandal must meet unbelievable preconditions: (a) VW would have to base all its software on copylefted Open Source and Free Software, and (b) an organization with a mission to enforce copyleft for the public good would require the resources to find the majority of GPL violators and ensure compliance in a timely fashion. This thought experiment quickly shows how much more work remains to advance and defend software freedom. While requirements of source code disclosure, such as those in copyleft licenses, are necessary to assure the benefits of software freedom, they cannot operate unless someone exercises the offers for source and looks at the details.
We live in a world where most of the population accepts proprietary software as legitimate. Even major trade associations in the Open Source community laud companies who make proprietary software, as long as they adopt and occasionally contribute to some Free Software too. Currently, it feels like software freedom is winning, because the overwhelming majority in the software industry believe Open Source and Free Software is useful and superior in some circumstances. Furthermore, while I appreciate the aspirational ideal of voluntary Open Source, I find in my work that so many companies, just as VW did, will cheat against important social good policies unless someone watches and regulates. Mere adoption of Open Source won't work alone; we only yield the valuable results of software freedom if software is copylefted and someone upholds that copyleft.
Indeed, just as it has been since the 1980s, very few people believe that software freedom is of fundamental importance for all software users. Scandals, like VW's use of proprietary software to hide other bad acts, might slowly change opinions, but one scandal is rarely enough to permanently change public opinion. I therefore encourage those who support software freedom to take this incident as inspiration for a stronger stance, and to prepare yourselves for the long haul of software freedom advocacy.
Posted by Bradley M. Kuhn on September 29, 2015
April 2, 2015 by Karen Sandler
Tomorrow is the last day to contribute towards Conservancy's $50,000 anonymous match! We've made great progress and are tantalizingly close to making the full goal. We're now 97.8% of the way there. You can help us close the gap — just 11 Supporter sign ups will do it!
Posted by Karen Sandler on April 2, 2015
July 15, 2014 by Bradley M. Kuhn
Eleven days ago, Conservancy announced Kallithea. Kallithea is a GPLv3'd system for hosting and managing Mercurial and Git repositories on one's own servers. As Conservancy mentioned in its announcement, Kallithea is indeed based on code released under GPLv3 by RhodeCode GmbH. Below, I describe why Conservancy chose to serve as non-profit home to an obvious fork (as this is the first time Conservancy ever welcomed a fork as a member project).
The primary impetus for Kallithea is that more recent versions of RhodeCode GmbH's codebase contain a very unorthodox and ambiguous license statement, which states:
(1) The Python code and integrated HTML are licensed under the GPLv3 license as is RhodeCode itself.
(2) All other parts of the RhodeCode including, but not limited to the CSS code, images, and design are licensed according to the license purchased.
Simply put, this licensing scheme is — either (a) a GPL violation, (b) an unclear license permission statement under the GPL which leaves the redistributor feeling unclear about their rights, or (c) both.
When members of the Mercurial community first brought this license to Conservancy's attention about ten months ago, the first focus was to form a formal opinion regarding (a). Of course, Conservancy did form such an opinion, and you can probably guess what that is. However, I realized a few weeks later that this analysis really didn't matter in this case; the situation called for a more innovative solution.
Indeed, I recalled at that time the disputes between AT&T and University of California at Berkeley over BSD. In that case, while nearly all of the BSD code was adjudicated as freely licensed, the dispute itself was painful for the BSD community. BSD's development slowed nearly to a standstill for years while the legal disagreement was resolved. Court action — even if you're in the right — isn't always the fastest nor best way to push forward an important Free Software project.
In the case of RhodeCode's releases, there was an obvious and more productive solution. Namely, the 1.7.2 release of RhodeCode's codebase, written primarily by Marcin Kuzminski was fully released under GPLv3-only, and provided an excellent starting point to begin a GPLv3'd fork. Furthermore, some of the improved code in the 2.2.5 era of RhodeCode's codebase were explicitly licensed under GPLv3 by RhodeCode GmbH itself. Finally, many volunteers produced patches for all versions of RhodeCode's codebase and released those patches under GPLv3, too. Thus, there was already a burgeoning GPLv3-friendly community yearning to begin.
Like with any Free Software codebase fork, acrimony and disagreement led to Kallithea's creation. However, as the person who made most of the early changesets for Kallithea, I want to thank RhodeCode GmbH for explicitly releasing some of their work under GPLv3. Even as I hereby reiterate publicly my previously private request that RhodeCode GmbH correct the parts of their licensing scheme that are (at best) problematic, and (at worst) GPL-violating, I also point out this simple fact to those who have been heavily criticizing and admonishing RhodeCode GmbH: the situation could be much worse! RhodeCode could have simply never released any of their code under the GPLv3 in the first place. After all, there are many well-known code hosting sites that refuse to release any of their code (or release only a pittance of small components). By contrast, the GPLv3'd RhodeCode software was nearly a working system that helped bootstrap the Kallithea community. We're grateful for that, and we welcome RhodeCode developers to contribute to Kallithea under GPLv3. We do note, of course, that RhodeCode developers sadly can't incorporate any of our improvements in their codebase, due to their problematic license. However, Conservancy extends again our offer (also made privately last year) to work with RhodeCode GmbH to correct its licensing problems.
Posted by Bradley M. Kuhn on July 15, 2014