Slashdot Mirror
Do Build Environments Give Companies an End Run Around the GPL?
Malvineous writes "I have two devices, from two different companies (who shall remain nameless, but both are very large and well-known) which run Linux-based firmware. The companies release all their source code to comply with the GPL, but neither includes a build environment or firmware utilities with the code. This means that if you want to alter the free software on the device, you can't — there is no way to build a firmware image or install it on the devices in question, effectively rendering the source code useless. I have approached the companies directly and while one of them acknowledges that it is not fully GPL-compliant, due to other license restrictions it cannot make the build environment public, and the company does not have the resources to rewrite it. I have approached the FSF but its limited resources are tied up pursuing more blatant violations (where no code at all is being released.) Meanwhile I am stuck with two devices that only work with Internet Explorer, and although I have the skills to rewrite each web interface, I have no way of getting my code running on the devices themselves. Have these companies found a convenient way to use GPL code, whilst preventing their customers from doing the same?"
"They could arguing that the build tools and environment are general purpose tools, etc used unmodified. I'd have to think that if that were the case you wouldn't be having any problems trying to make modifications though."
Would that it were that simple. There's lots of things out there where you can't just download the source and do a "make clean; make".... do you have the right libraries? (glibc version hell) The right version of the tools? (there's more than one version of gcc out there) The provider of the software might not even know... they just make it on their box, it goes ok, and they package up the source and distribute it.
As others have pointed out, GPLs 2 and 3 both require the release of the build-prerequisites. If, as one of the unnamed companies claims, they used GPL code and proprietary build prerequisites that they cannot legally release, than their lawyer(s) fucked up big. Just because the GPL doesn't ask for money, and some of its friends have long hair, doesn't make it any less binding than whatever license governs their build environment. They've put themselves in the untenable situation of having two binding licenses that cannot both be satisfied(and losing redistribution rights for their firmware would probably hurt if they don't have the resources to re-do their build environment).
However, in practice, to uphold a right, no matter how solidly enshrined in law, generally takes time and money(particularly in civil cases, where the state won't provide you even a shitty lawyer). As long as they aren't the most blatant, the SFLC and their ilk probably won't go after them(especially if their hardware is uncommon or obscure; from a strategic standpoint, the SFLC probably cares more about improvements to OSS software flowing back to the community, and buildability on common devices than they do about buildability on obscure stuff). You might have slightly better luck if you can identify the specific authors/copyright holders of all the GPL code used in the firmware. Particularly for the company that put itself in a license bind, any of the authors could decide to sue them, possibly for real money, if they so chose.
For you personally, though, you are probably SOL. If you have to ask slashdot, you probably don't have the lawyers you need. About all you can do is make noise about the situation, naming names, ideally, and hope that somebody with firepower takes interest.
Netgear had the same problem. It was probably about 4-5 years ago, they had a nice router that ran Linux and had a USB port for supporting a harddrive. I saw that Netgear provide the source, I emailed their open source person, and he was providing the things I ask for. I ended up picking up the router during one of Fry's sales and thought I was all set to build my own firmware. I attempted to build the new firmware, everything completed successfully, but I couldn't find the firmware to install. I emailed netgear again, the response was along the lines of: "Oh no, you can't build the firmware image, we don't give out that tool, and also our html pages are copyrighted, so you couldn't put that in the firmware anyway." As others have stated, this is what TIVO did and why GPL v3 was created. With GPL v2, it would be a much harder fight to win, and again it would need to be the copyright holders of the software, who need to file suit, not the customer.
Looking for any old 8-bit Heathkit/Zenith software/hardware - http://heathkit.garlanger.com
My employer works in a market where we can trust our partners about as far as we can throw them. They would rip us off in a heartbeat given the chance, and have in the past, and we don't have the resources to deal with it in court. We're happy to contribute our modifications of GPL code back to the community, and we do, but the constraints of the embedded environment require that most of our value-add proprietary code is in scripting languages, so it would be trivial for any of them to rip us off if we handed out the build scripts. We don't go out of our way to obfuscate things, but we don't make it easy to modify our firmware either.
As a consequence of this, GPLv3 is a strict no-go for us, and the same is true for many other small companies in the cut-throat embedded world. If we could trust our partners, or we could afford to litigate when they attempt to screw us over, we'd gladly be as open as possible, but as it stands we can't afford to give away our proprietary code in the process of complying with the GPLv3, so GPLv2 is as Free as we go.
Posted anonymously for what I hope are extremely obvious reasons.
We are not talking about desktop applications that someone grabs off TBP. The two situations are you describe are completely differnt ends of the process.... end user pirating software and upstream developer exerting control over a downstream product. What we have in the original situation was a downstream hobbist wanting access to the internal development tools of an upstream developer based off someone upstream from that company being FOSS, but wanting tools that were not FOSS. Or more specificly, someone bought a device that was closed (but used some open components) and then wants to edit the device, but wants the upstream company's help doing it (i.e. releasing their development tools). That produces not only MUCH more work for the company (build enviroments are not something that can be trivially packaged up if they are not designed to be), but also produces a horrible PR situation since, no matter how much tinkerers claim otherwise, the original company still ends up getting the blame when user modifications break the product. I got really, really sick of dealing with those support issues over time.