Tesla Violates Open Source Agreements; Don’t Be Like Tesla
Open source software can be a two-edged sword. On the one hand, for many companies or their vendors developing a specific application to make their business more efficient, it can save valuable time because programmers don’t have to “reinvent the wheel.”
On the other hand, users of OSS are generally required by the licensing agreement to adhere strictly to its terms. For example, sidestepping the specific requirements of the license, a user may open themselves up to charges that it failed to provide source code to the software product that incorporates the open source software.
Indeed, there can be legal and – in some instances – public relations nightmare in using open source software, which both businesses and developers need to understand. Open source license agreements and requirements can range from the bizarre to the serious.
At the silly side, one open source creator requires users to buy a copy of his book and threatens action if the user doesn’t. More seriously, about 65-percent of open source code on Sourceforge is licensed under GPL2.0, which requires anything built on those platforms be redistributed on the same “free to the public” terms.
Another type of license, LGPL2.1, has similar but more restrictive redistribution requirements, mandating that distributors of any package including the LGPL libraries to allow the end user to replace the libraries which may conflict with some commercial software terms.
Developers of open source software take the license requirements very seriously. Just ask Tesla Inc.
In creating successive models of cars, Elon Musk’s staff have been using a lot of open source software, especially in developing a driverless automobile. Because the brand is both so high profile and so heavily reliant on technology, developers and hackers alike have been paying close attention to how the open source software was used. And when Tesla appeared to be violating the terms of the open source license agreements by keeping everything under wraps, people started crying foul.
A number of people and organizations including the Software Freedom Conservancy have been publicly chastising Tesla for a considerable period of time. Under mounting public and private pressure, Tesla recently began releasing some of its code, which reduced some of its potential legal liability to license holders. The move was applauded politely although there haven’t been any standing ovations because much of the code remains hidden to all but the most-ambitious hackers.
There are a handful of “best practices” to follow in using open source code, which can help an organization avoid some of the most-common legal pitfalls.
- Use a centralized patch management framework to ensure that vendor patches are applied in a timely fashion per the license agreement.
- There must be a policy regarding how the open source software will be used
- Provide a cached version of known and approved open source components.
- Understand your software supply chain.
At the same time, if a developer or their customer receives a non-compliance letter, it’s crucial not to avoid it and hope the situation will go away. The first thing to do is speak with a software licensing attorney because there are nuances that can substantially affect the outcome of the dispute. The creator of the code will want to maximize its opportunity while the user will want to protect the proprietary portions of the final result
Open source offers many possibilities for developers and end-users. But it is important to understand the downside risks as well as the upside potential before plunging ahead. And don’t be like Tesla.
UPDATE May 30, 2018 –This isn’t a good week for Tesla and the OSS it is using to pilot its autonomous car experiments. For at least the second time, one of Tesla’s driverless cars crashed, this time into a parked police car in Laguna Beach, California. At least no one was injured, unlike a previous crash in Arizona where a pedestrian was hurt seriously.
By Marcus Harris