Linaro Connect, Volkswagen and Developer Ethics
by
on September 30, 2015Last 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.
Video of the full talk is available. You can sign up to our GPL Compliance Project for Linux Developers by emailing <linux-services@sfconservancy.org>.
Please email any comments on this entry to info@sfconservancy.org.