Dear Reader,
In January, I took Marta Rybczynska’s fabulous one-week training course Embedded Security. Marta is the resident security expert of the Yocto Project. I can apply the training lessons directly to my projects. Here are some things I learned:
Creating a read-only filesystem with overlays for writable directories or partitions.
Prohibiting root login.
Creating a list of CVEs for all packages of an embedded Linux system and filter the unpatched CVEs.
Creating an SBoM for an embedded Linux system and query the huge SBoM for interesting information.
Hardening applications and the Linux kernel.
You will have to implement all these features, when you make your devices compliant with the EU CRA. The training gives you amazing value for a small price.
Now let us see whether the anti-tivoisation clause should already hold for LGPL-2.1.
Enjoy reading,
Burkhard 💜
My Content
EU CRA: Essential Requirements Related to Product Properties
If you could have watched me writing this article, you would have seen me shaking my head in disbelief a lot. I can’t really imagine how especially small and medium manufacturers are able to implement all the essential requirements of the EU CRA. It’s a gargantuan task! I really hope that there will be less onerous requirements for small and medium companies - as Marta points out in her comment.
Does the Anti-Tivoisation Clause Hold for LGPL-2.1?
Why is it important?
The article German router maker is latest company to inadvertently clarify the LGPL license by Kevin Purdy (arsTECHNICA) instantly peaked my interest. The article suggests that the anti-tivoisation clause already holds for libraries under LGPL-2.1 and not only for libraries under LGPL-3.0. As the author misses to point out this implication, I immediately dove into the plaintiff’s complaint.
Till Jaeger - the plaintiff’s lawyer and the co-author of the legal commentary Open Source Software - Rechtliche Rahmenbedingungen der Freien Software (5th edition, in German only) - makes a convincing argument that the defendant AVM must not only provide the full source code of the uClibc library under LGPL-2.1 but also a script to cross-compile the library for the Fritz!Box 4020 router and a script to install the modified library on the router (a.k.a. anti-tivoisation).
The key driver for releasing version 3.0 of the GPL and LGPL was to explicitly allow users to install modified software on their devices. The outcome of the law suit could give an indication whether the anti-tivoisation clause would already hold for LGPL-2.1 - eliminating one of the main differences between LGPL-2.1 and LGPL-3.0.
What was it about?
A developer, Sebastian Steck, bought a Fritz!Box 4020 router produced by the German company AVM. Steck wanted to add some logging functionality to the uClibc library “in order to determine which programs on the Fritz!Box establish connections to servers on the Internet and which data they send” (see Complaint, Section 4). The uClibc library is licensed under the LGPL-2.1.
Steck exercised his rights from the LGPL-2.1 and requested the source code for uClibc and some other libraries from AVM (see Complaint, Section 5). AVM provided the source files in a tarball for download. Steck downloaded the files and found out that the compilation and installation scripts were missing. Steck contacted AVM again and explained the situation in detail. It became clear from AVM’s answers that AVM was not willing to provide the compilation and installation scripts (see AVM FRITZ!BOX 4020 6.83 ROUND 1 OF N for more details and the source code).
Meanwhile AVM provided an update from version 6.83 to 7.02. Steck updated the firmware of his Fritz!Box as a whole. As the firmware image is installed in a SquashFS, updating individual files is not possible. At least there was a way to update the Fritz!Box. Again, Steck requested the source for the libraries of interest. AVM provided the source code for version 7.01 but not for version 7.02.
Steck failed to build the provided sources, because the setting of an environment variable, KERNEL_LAYOUT, was unclear. Trying out all possible values would have taken far too long. Steck asked AVM several times to provide the correct settings for his routers. Eventually, AVM provided the correct value for the environment variable. Steck fixed the compilation issues himself.
The installation description in the make file was for installation on the host computer and not for installation on the target device. AVM refused to provide the correct installation script. Obviously, Steck couldn’t build a complete firmware image either (see AVM FRITZ!BOX 4020 6.83 ROUND 2 OF N for more details and the source code).
That was the point when Steck sued AVM with the help of the Software Freedom Conservancy (SCF) and the law firm JBB from Berlin. AVM finally settled with Steck. AVM provided the source code but not the compilation and installation scripts (see AVM FRITZ!BOX 4020 6.83 ROUND 3 OF N for more details and the source code). In his article, Purdy quotes an AVM spokesperson: “In the course of the proceedings, it turned out that the source code was sufficient, which is why the opposing party withdrew all allegations of a potential LGPL/GPL violation.”
Looking at the argument of the plaintiff, I doubt AVM’s statement. If the case was as clear as the AVM statement suggests, AVM wouldn’t have settled. A judgement in favour of the plaintiff would have implied considerable costs and efforts for AVM, as the routers contain dozens of software packages under LGPL-2.1 and GPL-2.0. For Steck, a settlement minimised the costs.
What was the plaintiff’s argument?
LGPL-2.1 is a weak copyleft license. Copyleft means that AVM must grant the buyers of its routers the same rights as it was granted by the authors of the libraries. AVM must pass on the rights and obligations of the LGPL-2.1 to the owners of its routers. Weak means that the license only affects the library but not other software linking this library.
In contrast, a strong copyleft license like GPL would force a manufacturer to provide the source code of proprietary software linking to the library under GPL. This is the crucial difference between LGPL and GPL.
You may copy and distribute the Library (or a portion or derivative of it […]) in object code or executable form […] provided that you accompany it with the complete corresponding machine-readable source code […]
Section 4, LGPL-2.1 (emphasis mine)
As AVM provides the LGPL-2.1 libraries as binaries (e.g., shared or static libraries) on its routers to its customers, it must also provide the corresponding source code. The source code given to the customer must have the same version as the libraries installed on the device. In other words, AVM must have built the libraries on the device from the source code given to the customer. When AVM gave the source code of version 7.01 to Steck although version 7.02 was installed on his Fritz!Box, it violated the LGPL-2.1.
"Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library.
Section 0, LGPL-2.1 (emphasis mine)
LGPL-2.1 clear demands that AVM provides the compilation and installation scripts for the libraries. In contrast, the LGPL-3.0 spells out in detail what information is needed from the manufacturer. Manufacturers could use this as a reference even for LGPL-2.1. They would definitely be on the safe side then.
“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
Section 6, GPL-3.0 (included in the LGPL-3.0 via Section 4e; emphasis mine)
Section 6 of GPL-3.0 clearly states that a user must be able to install and execute a modified version of the library on the User Product. Section 0 of LGPL-2.1 is still a bit vague but this is corrected in Section 6b.
Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.
Section 6b, LGPL-2.1 (emphasis mine)
In plain English: The shared library must already be installed on the device. When executed, the application loads the modified library from the flash storage and executes properly.
In summary, Till Jaeger makes a sound argument based on LGPL-2.1 that AVM or other manufacturers should satisfy the following obligations:
AVM must provide the library’s source code corresponding to binary on the Fritz!Box 4020.
AVM must provide the scripts to cross-compile the library for the specific Fritz!Box 4020.
AVM must provide the scripts to install the modified library on the Fritz!Box 4020. In the present case, AVM must provide an unsquashed root filesystem with all its applications and libraries in binary form. The installation script compresses the root filesystem and creates a squash filesystem from it. Note: AVM never provided the installation script and the uncompressed root file system.
The user must be able to run, on the Fritz!Box 4020, the applications using the modified library.
I would have loved to see a judgement. Unfortunately, Steck and AVM settled the case. I am pretty sure that the court would have sided with Till Jaeger’s excellent argument. We’ll never know for sure but there is a clear tendency.
My Conclusion
Does the Anti-Tivoisation Clause Hold for LGPL-2.1? My short answer is: most likely yes. The argument made by Till Jaeger - the expert in FOSS licensing world-wide - is absolutely convincing. Hence, I strongly recommend to treat LGPL-2.1 and LGPL-3.0 the same when it comes to installing a modified version of a library on a device, that is, when it comes to anti-tivoisation.
This is the recommendation I will give to my license-compliance customers. With licensing, it is always better to do a little bit more than a bit too little. You don’t want to be taken to court. It’s bad for your reputation and wastes your time and money.
Finally, I want to share two interesting points from the plaintiff’s complaint.
AVM uses a written offer for the libraries under LGPL-2.1. “The library software source code can at least for a period of three years be requested from AVM GmbH (mail to: fritzbox_info@avm.de or write to: Alt-Moabit 95, 10559 Berlin, Germany).” AVM does not provide the source code for download by default but only when explicitly requested by a user.
The plaintiff went to extraordinary lengths to explain what he wants and why he wants it. If AVM had cooperated with him in good faith, Steck wouldn’t have gone to court. When manufacturers go the extra mile in satisfying license obligations, users will happily grant them to remedy a license violation.
I'm not so convinced that this represents a meaningful decision on the LGPL or anti-tivoization clauses in general.
First of all, the outcome was a settlement affirming that the parties no longer had any disagreements, not a judgement. But more importantly, if you look into the details I think you will see this was more of a case where the complainant didn't have adequate expertise to understand how to accomplish his goals. You can see the final delivery of "installation instructions" that was accepted at the SF Conservancy's website: https://sfconservancy.org/usethesource/candidate/avm-fritzbox-4020-683-round-3-of-n/
Note that it did not include any new source code or installation scripts. I'll quote (and translate) the first two sentences:
"Die nachfolgende Schritt-für-Schritt Anleitung fasst im Wesentlichen den Inhalt der öffentlichen Quellen (s1) sowie (s2) zusammen. Bitte achten Sie darauf, die Schritte vollständig und in der richtigen Reihenfolge durchzuführen."
"The following step-by-step instructions basically summarize the content of the public sources (s1) and (s2). Please make sure you actually follow them, completely and in the correct order."
I do think there are some interesting questions left unresolved here, since it was settled instead of taken to judgement: if a competent embedded developer could figure out how to unpack, repack, and install a new firmware image on the router, is that sufficient? If not, how detailed must the instructions be? If my 88 year old grandmother can't figure out how to recompile and install her own LGPL library on her router, does that mean I'm out of compliance? What about if it's some guy with a computer science degree who mostly writes javascript but has never done embedded development before? (And all of the shades in between those two?)
Basically, where is the line between providing source code and build scripts, and providing technical support or teaching people how to build software?