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?"
Is it a license violation to use GPL code in a Windows program that's built with Visual Studio, given the author is unlikely to provide a copy of Visual Studio on request? You cannot rebuild the application, even given the entire source code, without access to a non-GPL piece of software you don't have access to.
You might not like it. You might even think it's against the spirit of something or other. But it's not a GPL violation.
You could argue that one difference is that Visual Studio is available to anyone prepared to pay for it. I'm sure that the build environment for the device you're talking about is also available to anyone prepared to pay for it. It likely costs more than you'd want to pay, though.
"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.
Even under the most stringent reading requiring the compiler to be freely available, companies could still build binaries for these.
GCC is not self-hosting on Windows last I checked but GCC can be cross-compiled to windows and that can be used as the developers' build compiler. So the full recursive chain ships a working Linux live CD with GCC, source for that, source for GCC, the command to cross-compile GCC resulting in a windows build of GCC, the product source code, and the scripts required to build and package.
It's an interesting problem with the GPL license text. There is a big difference between the "components released with the operating system" depending on whether you are talking about the full embedded SDK (often licensed for $$$ to product developers) or the final run-time OS (distributed in the product that goes to end-users). To which does the license text refer? Even back when GPLv2 was being authored, many Unix systems did not include compilers in the base release but they could be obtained by anybody willing to purchase licenses; developers would ship binaries of GPL source built with these commercial compilers, and nobody saw it as a problem that end-users could not rebuild it without also purchasing the compiler.
So, a reasonable interpretation says that the article's complaint is invalid, e.g. end users can obtain an SDK just like the product vendor did, and then modify their product instance as they see fit. However, a complicating factor is that these embedded SDKs are often heavily customized for a product vendor, and are not off the shelf systems another vendor (or end-user) could obtain. Where do you draw the line between generally available platforms and for-hire, integrated product build tools that can lead to lock-down?
A strict interpretation would be that one cannot use GPL source code in embedded products using traditional embedded development tools, because those tools have incompatible licensing terms which prevent end-user modification of systems. This is similar to the patent issue addressed in GPLv3.
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
The two are related, and both are desirable. However, they are mostly two different issues. You have the source and can put it on to any hardware for which you have proper access. Your problem here isn't the software license. It's the hardware license. You also need to get hardware for which you are granted the proper access. The distinction is clear, and I'm not sure why there is so much confusion.
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.