Do Build Environments Give Companies an End Run Around the GPL? 374
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?"
IE only (Score:0, Interesting)
That's not acceptable in this day and age. It sounds like the device is old, so time for an upgrade and pick an open one next time. ... you bought a lemon, so also time for an upgrade.
If the device is new
Not really, no (Score:4, Interesting)
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.
Re:Hm.. (Score:3, Interesting)
But this is largely irrelevant, as nobody with half a brain uses ROM firmware. Flash allows you to correct firmware errors later.
build tools? Re:No, they're just non compliant (Score:4, Interesting)
"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.
Legally, no. Practically, yes. (Score:5, Interesting)
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.
Build scripts wouldn't help (Score:2, Interesting)
As others have posted, they are meant to give you a copy of the build scripts. These scripts may not work outside of their environment (due to hard coded paths, etc), but they are meant to give you those scripts.
But nothing in the GPL says that they have to give you the firmware utilities used to load a new firmware on.
Re:Find an author (Score:3, Interesting)
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.
Embedded SDKs... (Score:3, Interesting)
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.
Re:It would be nice to name names (Score:2, Interesting)
Got stuck in exactly the same situation: Panasonic TX-P46G15E TV admits using (L)GPL code in their system menu and points to http://www.am-linux.jp/dl/EUIDTV7/ However no utility or script to install modified firmware. I asked gpl-violations.org to help but without hard proof that TV runs Linux they didn't pursue further (even though Panasonic admits using (L)GPL software in system menu and user manual as well).
Re:It's still a GPL violation (Score:0, Interesting)
Re:It would be nice to name names (Score:3, Interesting)
For the free market to work, information like this has to be made available. If people know which companies are doing bad things then people will stop buying products from those companies and the companies will be compelled, via loss in profit, to change their ways to go belly up. Keeping secrets hinders the free market and does nothing but cause problems.
NAME NAMES! Obviously, you should do so anonymously to prevent lawsuits, but they need to be named.
Re:This is not a violation of the GPL... (Score:3, Interesting)
First, we have not specified which GPL version is applicable, or if there are specific exemptions to it. Here is the applicable section under GPLv1:
"Source code for a work means the preferred form of the work for making
modifications to it. For an executable file, complete source code means
all the source code for all modules it contains; but, as a special
exception, it need not include source code for modules which are standard
libraries that accompany the operating system on which the executable
file runs, or for standard header files or definitions files that
accompany that operating system."
Nothing there about build scripts or tools to build.... Let's take a look at GPLv3 (section 1):
"The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work."
I see the section regarding build scripts, but embedded devices often do not include the ability to build on the device itself, presenting a big difference from the desktop world where you would typically config, build, install all from source. I still think that simply including the settings/defines/prerequisites would suffice. Note that the section above also specifically excludes general purpose tools. Since installation is often accomplished either through external flashing device or embedded flash utility (general purpose tool), these would be excluded.
Yeah, I've read the GPL. I'm not sure I like where things are going in v2 and v3. On the embedded devices that I work with (for instance FreeRTOS), the licenses are GPLv1 for the overall OS and tasking system. They also include a specific exemption for custom tasks/routines which doesn't require you to release unless you change the OS.
Ultimately, it boils out to defining which device, which specific license and which specific files are involved. None of that's been done, so to assume the most radicalized position here doesn't make sense.
Re:It would be nice to name names (Score:5, Interesting)
Re:Find an author (Score:3, Interesting)
Since hardware the code is running on is part of the build process, you'd also need to have not only entirely OSS software (ALL OF IT, firmware, bios, everything)
Coreboot.
but you'd also need entirely open source hardware.
The mostly-MIPS-compatible Plasma CPU [opencores.org] exists. If the binary produced by a compiler running on an x86 CPU is byte-identical to the binary produced by the same compiler running on a Plasma CPU, is it still a case of turtles all the way down?
ROM with a custom protocol (Score:3, Interesting)
as long as you have access to the proper equipment (CD burner + blank discs) there is nothing that stops you from creating usable 'custom' copies. I'd think the same applies to code in ROM, it's just that the necessary equipment is not typically found on your average home computer.
Some video game consoles use custom cartridge bus protocols, some of which are encrypted and/or patented. Before the NoPass crack [pineight.com] led to SLOT-1 cards, there wasn't any published way to make your own Nintendo DS-compatible ROM chip that wasn't just shellcode to get the DS executing code from the GBA slot. But if the ROM is in a user-removable cartridge, as in the case of almost every game console since the Atari VCS, the licensee under the GPL would still have to provide Installation Information because the licensee "retains the ability to install modified object code on the User Product" through a cartridge.
but on which hardware? (Score:2, Interesting)
GPL's about free software. You want open hardware. (Score:4, Interesting)
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.
One more time: YANAL! (Score:2, Interesting)
Sigh. Every time legal issues come up on Slashdot, somebody declares that the law is obvious, and thinks that there's only an issue because nobody's thought to visit the courthouse.
The reality is this: law is complicated and expensive. It's not enough for you to declare that something's "obvious", you have to demonstrate it in court. That costs money. Lots of money.
I've always thought RMSs notion of "free" software was braindead. It's just not workable. We have the illusion that it does work because a lot of projects use the licenses to create an IP commons that benefits all of them. That's the Open Source model that Free Software purists sneer at. It works because there's an economic basis for it. There's no economic basis for a system that lets everybody hack their own cell phone, and never will be.
GPLv2 vs. GPLv3 in the embedded world (Score:4, Interesting)
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.
Re:My Linksys experience (Score:5, Interesting)
Re:GPLv3 (Score:3, Interesting)
GPLv3 is an evolution of GPL, particularly GPLv2, against abuses which RMS predicted and which have now verified, most particularly patent issues. If you've not encountered patent software issues in the last 5 years, good for you, but they've been an increasing burden for people I work with.
The GPL is not merely "philosophical". While RMS may have a minority viewpoint, it's a minority viewpoint of someone with insight and a strange but effective brand of leadership, and the GPLv3 was developed openly with a _lot_ of community input and involvement. And GPLv3 was aimed squarely at a very real problem, the Novell/Microsoft patent licensing deal, which left Novell in a place to use and publish "GPL" code that was nonetheless patent encumbered by Microsoft and no one else could modify. If this seems unclear, the Wikipedia article is quite good, and the
GPLv3 was also written to be compatible with the Apache license. That is a big and heavily reviewed step, one which RMS wasn't completely thrilled about but which a lot of open source contributors were. So please don't claim that it's purely RMS's ideas.
Re:GPLv3 (Score:3, Interesting)
Last summer CNet reported that 50% of GPL projects hosted by google code were GPLv3. That works out to at least 56,000 projects.
And how many of those are actually stable, shipping, useful software? How many users does that represent, in total?
Finally, if industry is accepting the GPL because it is pragmatic, then that is a good thing. I'm sorry that you can't see beyond the end of your nose to see that v3 addresses pragmatic issues.
I never said it didn't. But if it really goes as far as some in this discussion are suggesting — and not being a lawyer, I'm not sure whether it really does or not, so I'm taking their word for it — then I think it has moved beyond pragmatism into the world of wishful thinking.
I don't really understand what is pragmatic about the kinds of cases I described. Code that is designed to run on specific hardware and requires specialist software or hardware to build/install is probably of most interest to others who also work on that hardware and already have access to the corresponding build/install systems. Those others are probably the most likely to contribute something of value back to the community as well. In trying to make everyone open up everything to everyone else, GPLv3 appears to get in the way of people opening up most of what they do to share with those who would most benefit from it, with the result that no-one can share anything with anyone in these fields under GPLv3.
It's like the FSF presented the industry with an all-or-nothing proposition, and since it had no choice, the industry said "Well, too bad, we'll have nothing then."