Young teens play a game on their TV, blissfully unaware of the lack of makefiles its manufacturer previously provided to those requesting its source code.
(Disclosure: I work at SFC and am the primary author of the linked SFC press release.)
It’s still compliant if the source only compiles on a particular target. But you must specify exactly which target that is. You can see that the author of the compilation script included a note about the system they tested it on (Ubuntu 14.04) at the top of the compile*.sh file in the source we posted here: https://sfconservancy.org/usethesource/candidate/avm-fritzbox-4020-683-round-3-of-n/
On the proprietary compiler, this has come up a lot historically on Windows. Generally people have pointed at a common proprietary compiler that a lot of people already use if this is conventional for a given platform. You don’t need to distribute the compiler, but you do have to precisely identify which compiler you used.
Interesting - I wonder how this would work out in the context of a game console, particularly when the manufacturer uses LGPL software, where the user is highly unlikely to be able to obtain the compiler and signing keys are also required?
The signing key aspect afaik primarily comes into force with LGPLv3 (which added the tivolization clauses), and then answer is fairly simple: If you are not prepared to give users the signing keys, don’t use LGPL software. (I’ve not worked on consoles, but other embedded projects, and “no (L)GPLv3 software in customer-(especially consumer-)facing releases ever” is a standard policy, companies willing to consider letting customers modify software sadly are quite rare)
Those policies are misguided because both LGPLv2.1 and LGPLv3 require reinstallation. If they want to avoid users’ freedom to install modifications to the copylefted software on their devices, they need to avoid the (L)GPL family of licenses altogether. LGPLv3 doesn’t require keys - you can provide alternative “methods, procedures [and] other information required to install and execute modified versions” instead. This is similar to LGPLv2.1, which requires “the scripts used to control compilation and installation of the library”.
Hang on, does this article say that Fritz!OS is actually LGPL-licensed? I was under the impression that it was proprietary, and that there was a project that applied patches to the OS without redistributing it for that reason.
If it is open-source, I’m surprised there isn’t more of a modding/hacker community around AVM devices, given how widespread they are in Germany.
Somebody had some fun writing the image caption:
TL;DR Source code alone is not enough, you must supply all scripts and configurations needed to compile.
This has intricacies: what if the source only compiles on a particular target and or the compiler is proprietary?
(Disclosure: I work at SFC and am the primary author of the linked SFC press release.)
It’s still compliant if the source only compiles on a particular target. But you must specify exactly which target that is. You can see that the author of the compilation script included a note about the system they tested it on (Ubuntu 14.04) at the top of the compile*.sh file in the source we posted here: https://sfconservancy.org/usethesource/candidate/avm-fritzbox-4020-683-round-3-of-n/
On the proprietary compiler, this has come up a lot historically on Windows. Generally people have pointed at a common proprietary compiler that a lot of people already use if this is conventional for a given platform. You don’t need to distribute the compiler, but you do have to precisely identify which compiler you used.
Nice, thank you for the details!
Interesting - I wonder how this would work out in the context of a game console, particularly when the manufacturer uses LGPL software, where the user is highly unlikely to be able to obtain the compiler and signing keys are also required?
The signing key aspect afaik primarily comes into force with LGPLv3 (which added the tivolization clauses), and then answer is fairly simple: If you are not prepared to give users the signing keys, don’t use LGPL software. (I’ve not worked on consoles, but other embedded projects, and “no (L)GPLv3 software in customer-(especially consumer-)facing releases ever” is a standard policy, companies willing to consider letting customers modify software sadly are quite rare)
Those policies are misguided because both LGPLv2.1 and LGPLv3 require reinstallation. If they want to avoid users’ freedom to install modifications to the copylefted software on their devices, they need to avoid the (L)GPL family of licenses altogether. LGPLv3 doesn’t require keys - you can provide alternative “methods, procedures [and] other information required to install and execute modified versions” instead. This is similar to LGPLv2.1, which requires “the scripts used to control compilation and installation of the library”.
For more on install under (L)GPLv2(.1), since GPLv2 shares the same language, see this blog post I wrote: https://sfconservancy.org/blog/2021/mar/25/install-gplv2/
If you want a full deep dive on what “tivoization” really is and means, there’s a comprehensive breakdown at https://sfconservancy.org/blog/2021/jul/23/tivoization-and-the-gpl-right-to-install/
Hang on, does this article say that Fritz!OS is actually LGPL-licensed? I was under the impression that it was proprietary, and that there was a project that applied patches to the OS without redistributing it for that reason.
If it is open-source, I’m surprised there isn’t more of a modding/hacker community around AVM devices, given how widespread they are in Germany.
It contains (L)GPL-licensed components: it’s a Linux after all. But it has closed bits too of course.
Are you the oje mentioned in the article? Kudos for pursuing the lawsuit and winning:-)
no, have nothing to do with it.
Sorry, was on mobile 🤦