Preamble
This is the third post in my series on my experiences at BMW Car IT GmbH. If you’ve missed the previous posts, you can find them in my archive.
In this post, I’m covering the use of open source software in the MGU head unit project at BMW.
Without open source software, there is no project
Modern car infotainment systems are no longer possible without open source software. Not because a company could not build them as closed source at all, but because they could not do so in a cost effective way: using open source software just saves money. The limited number of developers can then focus on features that are differentiating in the market rather than reimplementing basic features. In short, open source software helps companies to build more competitive products.
As I had already mentioned in my first post on the work I did at BMW Car IT GmbH between 2014 and 2021, BMW had gathered some 250 open source enthusiasts in Ulm and Munich to build an infotainment system for its cars released after 2018. This system would be a Linux system, and most of the userland resembled a modern Linux desktop distribution.
To distribute, or not to distribute, that is the question
This choice implied that BMW would respect the licenses of the various open source projects used in a typical Linux distribution. Almost all open source licenses have restrictions on what users must do when distributing the code in compiled or source code form. As a consequence, we had to figure out where BMW was “distributing.” The sale of a car that contains this code is obviously a distribution, but there were other cases to consider: BMW Car IT GmbH is a separate entity, so does passing a finished build to BMW AG constitute a distribution, even if BMW AG fully owns BMW Car IT GmbH? Furthermore, a series of companies were developing software for this platform, and developer tools—such as software development kits—were available in compiled form for download from our servers. That probably is “distribution,” and we would have to obey the license conditions. But would the companies BMW was paying to develop software for them sue over a license violation? Probably not.
With the question of where distribution happens out of the way, the obligations of the tens of different licenses were up next. These are reasonably well understood for most common licenses, and generally fall into the two categories “permissive” and “copyleft.”
What do I have to do to distribute this?
Permissive licenses are licenses that do not require distribution of the source code along compiled binaries. The BSD [1], [2] and MIT licenses and Apache 2.0 are popular members of this group. For those, it’s typically enough to include a copyright notice and the license text in the product documentation1.
Copyleft licenses instead require providing the source code for distributed binaries. Common representatives of this group are the GNU licenses (GPL 2.0, GPL 3.0, LGPL 2.1), the Mozilla Public License MPL 2.0, or the Common Development and Distribution License CDDL 1.0. They form two subgroups called “weak copyleft” and “strong copyleft” depending on whether the obligation to include source code also expands to derivative works of a copyleft component. The GNU GPL licenses are strong copyleft, while the rest use weak copyleft.
Now, I’m not a lawyer, and neither am I here to give legal advice, so take the following lines with a grain of salt: the common interpretation of the GPL is that linking against a library licensed under the GNU GPL means that you are creating a derivative work. As a consequence, you should not link code you want to keep proprietary against anything that is GPL-licensed.
License compliance at BMW
What does this open source license 101 mean for BMW and what risks does using open source software introduce? There were two main areas of concern with the use of open source software:
- Unidentified uses of GPL-licensed (that is strong copyleft) software that would retroactively force the company to publish proprietary source code.
- Unintentional non-compliance with license terms, because a license was not or incorrectly identified, followed by a court-granted injunction that would stop production and sale of new cars. This scenario (commonly named after Patrick McHardy, a Linux kernel developer who gained fame with GPL copyright enforcement court cases [1], [2], [3]) was a particular nightmare because stopping production is expensive.
As a result, somebody needed to keep a close eye on what obligations the use of open source software brings with it. This was already well-established at BMW. A huge handbook with a couple of hundred pages documented every known license, the company lawyer’s interpretation, obligations, and rules for use in products and development environments. Every project did have to produce a document showing its architecture, used open source libraries and tools and their license. Other developers with experience in license compliance would review this for any of the risks outlined earlier.
Licenses that did not yet have an entry in the handbook, or did not get general approval from the lawyers would require separate review in a council consisting of both developers and lawyers. This also is one of the first problems I saw: a modern GNU/Linux system uses a lot of different licenses.
You get a license, you get a license, everybody gets a license!
The MIT license has a surprising number of variants. The Fedora Linux distribution has a wiki page, that lists no less than 35 of them, all with minor differences. Picture a group of lawyers and developers sitting in a meeting room, discussing the minutiae of different choices of words and their impact on the meaning of the license, and you’ll get a good impression of the pain this license proliferation inflicts on users. On top of this proliferation, developers sometimes create their own variants of licenses without consulting a lawyer. For example, the Happy Bunny License used by the OpenGL Mathematics project GLM is yet another MIT license where the author has added the following paragraph:
Restrictions: By making use of the Software for military purposes, you choose to make a Bunny unhappy.
I do recall one Monday morning in a meeting room in Munich, where two corporate lawyers and three developers discuss for 30 minutes whether consumer cars sold to governments or the military are “use of the Software for military purposes,” and if they were, whether “choos[ing] to make a Bunny unhappy” is a restriction. If you ever considered modifying an existing license, I have to beg you for one thing: don’t.
Due diligence
The other big looming problem companies face when reusing open source software is metadata quality. For its MGU head units, BMW used the Yocto project. Yocto uses recipes to describe how to compile and package a software component. These recipes contain a field for the license of said software component, but—as with all open source software—there are no correctness guarantees on this data. This problem is not entirely theoretical either: in 2014, I found an example of header file copied from the kernel (licensed under GPL 2.0) in the otherwise LGPL 2.1-licensed alsa-libs. A 2022 publication of the professorship for open source software in Erlangen shows that this is still a problem today and found copyleft licensed material in a significant number of projects on GitHub that are claim they are under a permissive license:
Observation 3
There is a significant number of in-code licenses with a different level of restrictiveness than the declared license.
Various projects are making progress to tackle this issue: the Linux Foundation has developed the SPDX standard to make licensing information machine-readable and adding it to project’s source code using the SPDX-License-Identifier header. nexB publish scancode-toolkit, which is a quick and easy way to verify license metadata.
To at least partially address some of these risks, BMW includes not just copyleft source code in its open source archives, but also permissively licensed open source code, including any potential modifications made. This mitigates the risk of misidentification of code licensed under a copyleft license as permissive. As a nice side effect, publishing all open source code regardless of whether it’s required or not, is also more in the spirit of open source.
Where are those license texts in cars, though?
Now, nothing from that lengthy discussion matters, if your customers disect a software update, notice that it contains open source software, but cannot actually find the license texts and the written offer to request the corresponding source code. Back in 2016, BMW Australia customer support did not know what to do with a request for open source code and refused, which then ended up on the Hacker News front page.
I was working on gathering the license texts for the MGU infotainment around that time, and since BMW’s PR department did not seem interested in getting involved in a Hacker News discussion, I did something that probably blatantly violated the company policy on dealing with social media. I sent an email to the author explaining where to find the license texts and where to request the DVD with the source code.
Two weeks later, BMW actually sent out the DVD for this car and this blog post did receive some attention on Hacker News again, so while I may have been violating policy, I’d like to think getting involved did at least generate some good PR.
Note that the DVD (pictured in the linked blog post) is a bog standard DVD+R without any print or label on it. If you’re wondering whether BMW couldn’t have at least made an effort to make look a bit nicer: that’s a conscious decision to prevent the OSS DVDs from becoming a collector’s item ;-)
This is an oversimplification, but this is a blog post, not a seminal paper on the differences between various specific open source licenses.