>Which I think touches on aspects that have never been tested fully in courts, ie rights to create derivative works and the issues around linking.
Derivative works have been tested in courts a handful of times - but few are dumb enough to go to court and end up with a precedent set.
But that was not what I was discussing - I was discussing the requirements that need to be met to have copyright permission to distribute the unmodified software.
>Plus the exception in that clause. So if you have a dev kit for the SoC used, can a reasonably competent person compile the BusyBox code provided?
The exception only applies to software that already was part of an existing proprietary OS, to allow for GPLv2 software to be used with such OS's, but it is careful not to except rendering the software proprietary by accompanying it with proprietary components.
You can additionally supply sources for a dev kit too, but you still need to comply with the source requirements for the original object code distribution.
>If you want to compile for an AMD64 or any other target, that's up to you and the GPL doesn't place any obligation on helping users create their own derivative work.
The GPLv2 places an obligation on the distributor to provide build scripts that compile for the target architecture for the device.
My point was that the provided "sources" are clearly not corresponding source code, as such in their original state target AMD64.
>Plus there's probable legal ambiguity around complete source code means all the source code for all modules it contains. Which some seem to interpret as all code, including anything that might be proprietary or under seperate copyright. It also doesn't extend to hardware designs, unless they're also open-sourced.
There is no legal ambiguity - it was written to mean all parts of the program - including all derivative works.
Microsoft software has conditions on producing derivatives works - you do not have permission to go and write a proprietary derivative work of say excel without meeting microsoft's requirements (as you do not hold microsoft's copyright) and you also do not have permission to write a proprietary derivative work of GPLv2 software (as you do not hold the copyright of the author(s)).
Unrelated hardware designs aren't relevant to the license and "open source" is even less relevant (considering that the GPLv2 was released in 1991 as a free software license, while the concept of "open source software" and "open sourcing" did not exist until 1998).
>Cisco settled the case six months later by agreeing to several actions:
>"appoint a Free Software Director for Linksys" to ensure compliance
>"notify previous recipients of Linksys products containing FSF programs of their rights under the GPL"
>make source code of FSF programs freely available on its website
>make a monetary contribution to the FSF
Yes, the FSF out of good faith tried to work with them to get license compliance sorted for 6 months, but eventually they got fed up and told them they would sue if they didn't comply.
Suddenly, they complied with the license by supplying a written offer to all customers, additionally supplied the source code for download from the website and paid the FSF for some of their costs.
>BT has a General Counsel and an army of lawyers.
Cisco was a massive company at the time and had an army of lawyers, who were glad to be paid to go on tangents for 6 months, but when there was the threat of getting sued, those lawyers made it very clear to the suits that they would lose and set unwanted precedents if they went to court, thus Cisco complied with the GPLv2 for GNU software and also complied for Linux and the FSF reinstated their license.
>Per Cisco, it has the source for GPL elements freely available on its website.
Cisco only previously complied with the GPLv2 for the Linksys WRT54G (which ran GNU/Linux) - providing the complete corresponding source code - which allowed the "Open"WRT project to be launched, which replaced all the aggregated proprietary programs with free software replacements.
The FSF doesn't hold any copyrights on Linux and the FSF has only a limited copyright claim for BusyBox, thus taking companies to court over BusyBox/Linux without additional GNU programs being distributed, or assistance from copyright holders of Linux and/or BusyBox, is much more difficult.
The FSF prefers to focus on license enforcement on GNU programs, which are mostly distributed under the GPLv3-or-later - but would assist if any substantial BusyBox or Linux copyright holder came forward - but such copyright holders tend to not enforce their license.
Cisco has now mostly changed to BusyBox/Linux and as there is a lack of enforcement, no longer complies with the GPLv2.
>BT seems to be doing the same as Cisco with their FSF-agreed remedy.
The FSF certainly wouldn't have agreed to what BT is doing - BT decided themselves to publish useless non-corresponding sources of BusyBox and Linux, as most people would then assume that they must be complying with the GPLv2 and give up, or even if they tried to compile the sources, give up when it doesn't compile, assuming they must be bad at compiling.
>You assume Cisco would have lost, but there is also the possibility that Cisco may have won and established precedent that the GLP attempts to assert rights that it can't legally enforce.
If Cisco had won on their claims that the GPLv2 was invalid, then they could have still be pursued for damages for distributing FSF copyrighted software without a license.
>Plus BusyBox has been involved in a fair bit of litigatiion, so mitigations are pretty well understood and tested.
Not really - some copyright holders did some litigation over BusyBox only (but not of the other GPLv2 programs), but soon gave up.
>many articles on devices being compromised, botnet C&C servers being taken down etc etc. That can happen when the official C&C servers get compromised.
That applies equally to persistent and non-persistent botnets - the C&C servers being taken down merely means that the botnet no longer receives commands - but not that the vulnerabilities are fixed or the botnet software stops infections (unless the botnet was configured to not infect unless it can reach the C&C servers).
>Those are generaly designed so a new subscriber can plug a router into their NID, and the first thing that will do is download a copy of the latest software, reboot, then grab a standard config, possibly with some subscriber-specific stuff generated by provisioning & BSS.
That is a backdoor that shouldn't be implemented.
>And that has to be secure, otherwise some bot-herder can come along, re-key any signing & cryptographic functions that could lock the provider out of their (and your) routers and potentially brick a few million devices.
As typical with roll-your-own crypto, such backdoors are *never* secure - there has indeed been a case of a few million devices bricked and I figure there was cryptographic signing.
>So asking your provider for their keys is likely to get a polite 'NO!', followed by a 'Hell NO!', then a more strongly worded response that might include a visit from TPTB asking why you want the ability to break a large public network.
If there is some alternative way to install software, the provider can comply with the GPLv2 by providing installation information for that alternative mechanism - which can include an alternative signing key.
The only case the provider would legally need to have to supply the signing keys for such backdoor, is if that's the only way to install software.
>the input from engineering, legal, operations and finance is going to be 'NO!'. Especially when there are externalities like reputational risks, massive costs of replacing millions of routers..
Clearly the world needs heavy litigation over BusyBox/Linux, with court orders with payment of damages and orders to replace millions of routers with routers that do not use BusyBox or Linux, or any GPLv2 or GPLv3 software, if the GPLv2 is not complied with.
>And the prospect of some very large fines when people die. Having no Internet for a few weeks would be inconvenient. Having no phone because the PSTN has been migrated to a VoIP service means that people with a bricked router might not be able to make a 999/112/911 call, and people have died as a resuly of badly designed VoIP services. So then there'd be a large fine from the regulator, plus civil claims for wrongful death from families
I really wouldn't want to rely on a router that runs proprietary software for emergency calls - only routers that run free software tend to be reliable (there's a reason why manufacturers use BusyBox/Linux - there is only a limited amount of proprietary cancer added, so it's that much less reliable than GNU/Linux-libre).
If other router OS's were as reliable, clearly companies would go with those instead, as there's no GPLv2 obligations for the routing parts of BSD's for example.
Therefore, the regulator should be serving the citizens and pursing cases of backdoors and GPLv2 infringement for routers hard and handing out large fines and executing businesses for non-compliance - with the goal of ensuring that all routers end up running 100% free software, which then can have all the bugs worked out and thus can be relied on for emergency calls.
