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?"
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
so we can vilify them, castigate them, and otherwise snark.
---- Teach Peace. It's Cheaper Than War.
For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.
http://www.gnu.org/licenses/gpl-2.0.html
It's a straight up violation. Go find the author of the software... any author of any part of the software will do.. and invite them to sue the manufacturer. Direct them to the Software Freedom Law Center.
How we know is more important than what we know.
The loophole being proposed is just a variant of Tivoization. And the GPLv3 already fixes it, and anything else that gives out source while not giving you everything you need to build it.
GNU GENERAL PUBLIC LICENSE Version 3 Free Software Foundation, Section 1, "Source Code.": 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.
The GPL does not allow authors to hide or refrain from distributing any build scripts or information required to build/install the binaries.
They cannot have a "secret" build environment, the GPL requires that they reveal all scripts and information about the build environment.
I don't understand why the FSF would not pursue this with full vigor. Obviously you cannot exercise your freedom to modify code, if the vendor does not distribute the pieces required to build and install a binary.
As far as I can read it, the corresponding source definition in clause 1, GPLv3 covers that situation
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.
My reading of "all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work" would cover the build environment. 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.
http://www.gnu.org/licenses/quick-guide-gplv3.html
Protecting Your Right to Tinker
Tivoization is a dangerous attempt to curtail users' freedom: the right to modify your software will become meaningless if none of your computers let you do it. GPLv3 stops tivoization by requiring the distributor to provide you with whatever information or data is necessary to install modified software on the device. This may be as simple as a set of instructions, or it may include special data such as cryptographic keys or information about how to bypass an integrity check in the hardware. It will depend on how the hardware was designed—but no matter what information you need, you must be able to get it.
This requirement is limited in scope. Distributors are still allowed to use cryptographic keys for any purpose, and they'll only be required to disclose a key if you need it to modify GPLed software on the device they gave you. The GNU Project itself uses GnuPG to prove the integrity of all the software on its FTP site, and measures like that are beneficial to users. GPLv3 does not stop people from using cryptography; we wouldn't want it to. It only stops people from taking away the rights that the license provides you—whether through patent law, technology, or any other means.
Have these companies found a convenient way to use GPL code, whilst preventing their customers from doing the same?
Yes - it's called "having more lawyers than you."
What are you going to do about it, sue? You can always sue...if you actually have the resources to fight it out. And even if you actually get it to stick, it could be years down the road before you actually get access.
Regarding your specific case, can you reverse-engineer a solution?
This only adds bad press to Linux. OTOH an offer to cooperate with freeing up the firmware?
Sign an NDA on a tool-set for the company, then release a free version. Simply reverse-engineer it with manufacturer's cooperation, access to docs and tools, then "hack" it in a blessed way that doesn't violate the company's licenses and complies with GPL. I'm sure they would be glad if someone helped them comply with GPL instead of forcing them to do it themselves.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
And it'll work, too.
No, the build environment doesn't provide an end-run around the GPL. Both v2 and v3 of the GPL require the distributor to provide the scripts that control the build. In GPLv2 it's in section 3, in GPLv3 it's in section 1. GPLv3 also covers this again in section 6, in a more general form when it discusses installation information.
What if the firmware is burned into ROM and hardware only supports ROM?
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
It sounds like you don't work for either of these companies. So why are you protecting them?
If you really want them to do the right thing, start making a stink about it. There's very little chance anything is going to change because one guy asked them to. There's at least some chance that they will if the companies start getting a bloody nose from it.
AccountKiller
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.
No sympathy for them, if they cannot comply with the license they are engaged in commercial copyright infringement and should be thankful you gave them an opportunity to fix it rather than going straight for statutory damages.
However the FSF has limited funds and they do have to pick their battles wisely. If all you can do about the situation is bump your FSF contribution then do it.
As for a practical workaround for your benefit, do you have the ability to write arbitrary bytes to the firmware? If so you should be able do this in a hexeditor. It wouldnt be trivial though - quite a few hours of work, depending on the specifics of how they screwed their HTML up so badly and how it's encoded. You might be able to shortcircuit it a bit by simply determining what IE sends to the device to perform each task, and then scripting your own pages that result in the correct bits being sent to the device. Would have to look at the actual device in-depth to determine which route is most practical.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
(from same link)
If the compiler is a special case then you have a problem there. If the target device is some special dedicated OS, it all comes under this exception? Notice that they do not require to release the compiler (unless is was adapted for this target).
Also remember a term called Tivoization. You are starting the same discussion all over again.
But they are missing the largeste advantage of the GPL. They can have free mod version and bug fixes if they release their complete environment.
"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.
GPLv2 says that source code includes "the scripts used to control compilation and installation of the executable". GPLv3 is even more explicit. So they are likely, depending on the details, just violating the GPL, not using any kind of loophole.
I thought we hated copyright because it rewards people for too long now etc.
The company is not depriving anyone else of using the code so therefore there is no harm in it and no value lost etc etc etc
Funny how we want it both ways, huh?
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.
The GPL doesn't require that hardware that has GPL code be modifiable to include updated versions of code. Build systems are a distraction here: a more direct form of the problem is that the GPL code is burned into ROM, and even the GPLv3's Tivoization section (number 6, paragraph starting "If you convey...") explicitly permits that. It would be dumb if it didn't. While it may well be the case that for GPLv3 (and not GPLv2) failing to give you a usable build environment for compiling modifying code so you can run it on your "User Product" is a violation, this is forgetting a large part of the purpose of free software.
The point of free software is that the software, the code, is free for the community to use. Thinking about free software as simply the ability to modify code within its original context causes us to forget opportunities for reusability that benefit the entire free software community, well past the lifetime of this one device, and encourages behavior where modified code isn't usable on other devices or in entirely different contexts. I've written a bit more about this on my blog, with some examples of times when thinking about "free software"/"open source" only within the context of the original product has caused the free software ecosystem as a whole — the thing that's causing large companies to want to embed free software in their hardware devices in the first place — to be left behind.
Are you talking about makefiles and scripts, or are you talking about a proprietary compiler used to generate the code? There's a huge difference.
cat
After getting the "our developers are working on it" runaround for months and months when Linksys didn't issue new drivers without the Broadcom vulnerability for my WPC54G v.4 adapter, rendering it totally useless, I decided to never, never, again buy Linksys equipment.
So you might be right that the firmware of the Linksys device I bought was upgradable, but that's useless if you have no way to make custom firmware and the vendor doesn't issue bug fixes for its original firmware.
The company I work for builds our custom software environment for specialty networking hardware on top of FreeBSD specifically so we can avoid crap like this. We also employ people to make contributions back to the FreeBSD project as well, so we're not mooches, but seriously... this is why so many companies don't want to get involved with Linux or GPL solutions.
You either have a license to use the code or you don't. If you don't comply with ALL of the terms of the software license, you can't use the code. It really IS that simple. The companies have stolen code.
If you own the copyright for the source and if you can't afford a lawyer, contact the press and let then know that the companies in question have stolen your code. They have the obligation to prove that they have the licenses in place.
You said it yourself; this is as much a loophole to GPL as a criminal getting away with it because he has good lawyers.
It's not a loophole of GPL itself, but rather of the legal system in which it must rely.
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.
Sorry to rain on the "GPL violation parade", but this really isn't a violation. The GPL covers the source code only, that's what the banner above the code indicates. It doesn't stretch to everything that's required to build a duplicate product. These companies are under no obligation to release their build environment, scripts, custom firmware utilities or whatever unless they contain GPL code AND they're releasing the binaries out into the public. Private build tools don't count. Doesn't matter if it makes your source useless, or you unable to build a new image. Nobody ever promised that you would be able to build some replacement code and drop it into the device. Indeed, there are reasons where companies may NOT want you do to that (think product liability), even if they do release the source code that they originally built from.
I'm a great supporter of GPL, but folks here are trying to stretch the GPL into something it's not. If what you propose is true, I should be releasing the source and binaries to Notepad because I used it edit some of my files. I would also be required to release my build scripts even if they're owned by another company, and the firmware loader that I used to load up the image into the device.
Perhaps if you worked with the companies in question without crying wolf over some GPL violation that isn't, they may actually help you more. Here's a suggestion: offer to build them a new script based on public tools...And I mean really "go the distance" with them, using something public like Ant. Help them work through the rough edges and show them that you can provide a "win-win" situation where they can actually trust you. They may not bite, but then again, they may... And you've helped show good faith rather than calling in the lawyers.
If you bought the devices with no promise from the company that they would ever provide any kind of firmware upgrade, then you have no complaint against them because you bought the device based on what it had on it at the time, regardless of whether ROM can be flashed or not.
Well, the GPL version 3 does address this issue, and other limitations (like hypervisors that prevent you from installing unsigned code).
But the problem is not a license issue, since we don't have the resources to legally battle all companies that violate Free Software licenses.
It's about people understanding the importance of GPLed software, and the philosophy behind it. It's about building an ethical understanding of the issue in the population.
But the reason why people violate the GPL is obvious: Copyright isn't natural. Stealing is immoral, and also breaks the law. Copyright infringement only breaks the law, but it's not immoral. It's not a crime. And it'll never be. Copyright is an invention, and unnatural limitation. Therefore, people disregard it, just like many other things that aren't immoral, but are illegal. Illegal, but very convenient, will get you a lot of infractions. That's why we have a lot more traffic violations than murders.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
Using MSBuild and the windows sdk both free (as in beer) you can pretty much build anything you can in visual studio. We use it for our test building system.
If the firmware includes any software that is a member project of the Software Freedom Conservancy (here's a list), which it almost certainly does because 99% of these devices include BusyBox, send mail to conservancy@softwarefreedom.org and tell them about the device. They will start the process of making sure the vendor is complying with the necessary requirements of the licenses.
Sorry but the hypocrisy of your statement is so in my face I have to say something.
You are keeping the identity of these companies secret for what end? It's GPL there for open there for it should not be a secret.
If you say something this community might be able to help you. Maybe one of us has already discovered solutions to your technical problem. When something like this comes up slashdot usually coughs up pages of useful links. It can be rather fun and interesting at times.
Sadly you are keeping it secret. Thus the helpfulness of this community is next to zip.
Because you are keeping things secret it would not be all too far fetched to believe that you are actually trying to alter the code is such a way as to derive money from it. Say by either selling an after market mod or by selling it back to the mystery vendor(s).
Please don't cry about the big companies keeping secrets if you can't even get that out with out keeping a secret.
P.S. Most likely no violation was made. Hardware and build env's are not governed by source code GPL. Unless of course the hardware or build env is also derived from a GPL reference.
What is Linux built with? GCC.
What are the libraries and applications that run on Linux built with? GCC and the other GNU build tools.
What is U-Boot built with? GCC.
What is Busybox built with? GCC.
As long as the kernel configuration file and platform-specific drivers are included in the kernel source, everything needed to build it for the target is available, so a competent programmer cannot be precluded from changing it.
It may be a bit of a pain to configure additional apps into buildroot, emdebian, or whatever the vendor uses (and that configuration file should be in the source package, anyway), but those tools are are hosted at their respective homes. Again, you cannot keep a competent programmer from rebuilding them.
Unless the vendor specifically uses some sort of JTAG (or similar) interface to install software updates, the mechanism by which they do it will be in the run-time and source tree (perhaps obscure, but present). If they do use a JTAG (although it is VERY rare for a product to be released with no download update capability), there might be a case for listing the brand and model, and posting the config' file.
Look at how many boxes have "homebrew" communities. Those people are competent (if not outright brilliant). Just because YOU cannot figure out how to install some change(s), does not mean that there is a GPL violation.
Finally, there are often features in user space. As long as the libraries used are LGPL, there is no requirement to publish the source code of applications that link to them.
you know, the make file, where all manner of macros and includes are listed
Trendnet seems to be GPL compliant in releasing source code to the surveillance cameras we installed however there is no build environment or firmware tools. Linksys on the other hand, while I don't know if they have involvement with GPL on the device in question, I know we have some managed switches from them that are IE only (or at least not compatible with ff, opera or chrome/chromium) and required me to install ies4linux in order to configure them. I didn't test with w3m.
Or perhaps the general readership should start naming names and raising a stink about companies they *know* to do GPL 'on technicalities'. I work at one of those companies (though this company contributes all their patches back upstream, they do not empower users to have what they need to customize 'embedded' uses of open source). It's hypocritical for me to make a call and not name my company, but I do care about my job. I have repeatedly complained they are acting sketchy and I just keep getting told they are afraid of customers breaking their own stuff and holding my company accountable for things they do to themselves if they were allowed to fiddle with it.
In a more interesting note, if you don't care about warranty/support on the device (if you *do* care, then be aware that exercising the freedom to modify software the vendor considers 'embedded' will void the warranty in much the same way disassembling the hardware would, which is understandable), open it up, look around, look for familiar sockets/chips and search part numbers on the web. You may well find the firmware is on a compactflash card, usb flash part connected via the same pinout as most motherboard usb connectors, or IDE or SATA port that you can remove and examine/experiment offline. Once I opened up a piece of equipment, found a likely candidate, searched to verify it was usb, and fashioned a connection to my laptop out of parts of a usb keyboard. The vendor flash utility refused to do anything without a particular odd update layout, but the underlying filesystem was just ext2 on usb flash. Be wary of runtime cryptographic signature checks, but more often than not vendors don't worry about it.
The question is making a bad assumption (ie. Open source software can't run on closed hardware.) The hardware is closed, the software is not. The purpose of open source is still being served here. You can learn from this nameless company's modifications to the source, or use it to develop your own hardware or software, the benefits of more eyes on the code, etc.
I say this as someone who has ported Linux to a new platform: building the toolchain and porting the code is part of the fun. If it's a popular processor, and all you have to do is define the specific architecture, plan on spending a few days (on the toolchain, that is). If it's something completely new, for example - a processor not yet supported by gcc... Well, you might as well make an ongoing project of it, host it on sourceforge, etc...
Granted, they *should* provide the toolchain, especially if it is OS software, but they are not strictly obligated. It is entirely possible they are using a proprietary compiler which they can't release to the public. This happens a lot in the embedded world.
In all likelihood, they are either using a proprietary toolchain which they can't release, or they are one of those companies where cost controls everything, and the effort to post the toolchain and hosting space is just a nickel too much. There's a good learning opportunity here - while you'll probably have to do a little detective work to get things working, and maybe even port it to a FOSS compiler.
The society for a thought-free internet welcomes you.
Many mobile chipsets are being shipped as secure boot enabled anyway, so you can have the source AND the build environment which would allow compilation but you couldn't run it on production hardware... though you could argue it (signing) is part of the build environment really it is not, it is a digital signature on the compiled binary.
That's not how I read that clause. While it does make the mention that you don't need to distribute any freely available or common tools required to build that source, it seems to me like they spell it out pretty clearly that otherwise you need to distribute everything needed to build, install and run that thing. (But I am not a laywyer.)
Otherwise it would be trivial to make the source need parsing through a script that only runs on my internal and proprietary modified Brainfuck interpreter, and then through a Lisp program that only runs on an old version of Autocad that's still installed somewhere in the company, before it compiles.
In your particular case, sure, you can develop with Visual Studio, but surely you can take the time to write a makefile that can be run at the command prompt. In fact, it's been years since I worked with Visual Studio, but I seem to remember it did that for me itself. And they wouldn't even force you to use gcc, since the command line versions of the MS compilers were free last I heard.
(And frankly if they don't have an automatic build machine, and the scripts that that needs, i.e., if they're in the kind of situation where tgey can only build on some dev's machine in their Visual Studio, with whatever sources they may or may not have checked out at the time... they're not the kind of company I'd want to buy anything from in the first place.)
Plus, if I understand the summary right, even if he managed to compile the binary code, the tools to install (and thus also to run it) are missing too. I'd say that's against the letter and spirit of that clause right there. The idea was to be able to make changes, not to just have a bit of source to open in an editor, but not be able to actually run any changes or, for that matter, even know if it's the right source. How would you know for something you can't even compile, and certainly not run?
And it's hard not to ascribe it to malice there. Whatever proprietery protocols they use to upload that firmware, surely they're encapsulated in a bunch of classes and functions that are just called from whatever environment they use. It's trivial to pack the same in a small command line utility.
(And again, if they're that joined at the hip to whatever environment is usually used to upload that firmware, that they can't separate the classes that do the uploading from the rest of the beast... it sure doesn't sound like the kind of company I'd trust to program my VCR, much less the firmware for anything.)
A polar bear is a cartesian bear after a coordinate transform.
A company which is using mutually-incompatible licenses in the same product may have no legal option but to recall the product or renegotiate one of the licenses, or close up shop entirely/file for bankruptcy.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Copy the Chip and burn it yourself!!!
Or maybe after you copy it you could analyze it if you need to mod it. wtf EPROMS you don't have a bunch laying around already. You do know coding isn't just your IDE? Right. Right? It's electronics, truth tables and all that shit
There is a substitute for the Windows SDK: the w32api component in MinGW GCC.
Are you confusing commercial with proprietary?
Commercial and proprietary are orthogonal in theory but not in practice. For some kinds of products, nobody has yet thought of a services-style business model to divorce commercial from proprietary. For example, what kind of services does a video game need if it's not MMO?
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).
GPLv3 defines "System Libraries" and "Major Component" in more detail.
Where do you draw the line between generally available platforms and for-hire, integrated product build tools that can lead to lock-down?
GPLv3 draws the line in part in terms of a "Standard Interface", or an interface published by a standards body or widely used among developers that has been implemented in published (not necessarily Free) source code. Libraries provided with a toolchain are more likely to qualify as System Libraries that can be left out of Corresponding Source if they implement a Standard Interface on top of a proprietary operating system.
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 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.
Does the GPL require the source code to run on the same piece of hardware? The OP can't build an run new firmware on his router, but can he build and run it on his x86 linux machine with standard tools? If *that* can be done, is it really still a violation? The modified source code has been re-contributed to society. I know that's not really what the OP wants to accomplish though...
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.
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.
I doubt the intent of the license was to prohibit writing applications in certain languages while still opening the code.
Such languages are called Java-trapped. Java itself used to be Java-trapped until Sun released OpenJDK.
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.
He's only 50% insightful.
(I refer you to the other replies to see why)
"I don't care about the Constitution!" --Bill O'Reilly, November 17, 2009
2 can play at that game.
Enjoy this.
you had me at #!
n/t
you had me at #!
I've worked at so many companies where our builds were barely able to work for new employees. Let alone work for the public at large. But really is it such a big deal, if it's just one program from the open source how to compile it is pretty well known. Packaging it in a convenient way is another matter, but if you're hacking up some device why should you limit yourself to their lame schemes?
And why stop at build systems, maybe these companies that ride on the backs of GPL developers should give you a laptop already configured to build the whole thing from source. And while they are at it, you should get their source control change history too, maybe we should demand every GPL using company give us a public read-only Git or Mercurial repo with each release.
Feel free to make any of those demands in your next open source license. Although I suspect a company would rather pay you a few thousand dollars than deal with weird requests.
“Common sense is not so common.” — Voltaire
Can someone else sue for damages, since GPL'ed code not being provided would seem to be a violation of everyone's rights... or what about the original author, since it sounds as if they are in violation of the code's original authors granting of license... or did I misunderstand the GPL?
Tie it in as a criminal copyright case. This should be easy and you don't have to have standing. It's what the *AA/BSA have always wanted.
Re:This is why we don't use GPL stuff He's doing what the GPL requires. Actually, he's full of shit and making it up, but if he WERE, then he'd be doing what the GPL requires.
But as I say, he's full of shit: his company doesn't do that. Partly because if he were, there'd be no reason to fear the GPL, partly because he would be doing free R&D for his competitors, and if he was OK with that, why is he all bent over the GPL requirements?
I read through the over 200 messages, lots and lots of complains.
So, instead of complaining brand X sux brand Y sux too, can someone please tell me which equipment that you would recommend, that uses Linux / GPL softwares that also comes with readily tweakable firmware ?
Thank you !
Muchas Gracias, Señor Edward Snowden !
It's far less than ideal, but you could do the work, submit the patches to the company and try to get them to bundle it into a newer version of the software for the devices...
(Of course - I don't know how you actually test your code to make sure it does work, but that's a problem for them to solve)
I take is you have never actually tried to create a GCC cross compiler.
You could argue that a gcc cross compiler and cross bintools are a "general-purpose tools". But have you ever tried to create them from source
so you couldn't put that in the firmware anyway.
This is actually a non issue, as you already have a licensed copy in your current firmware (which you could obtain either with the "backup old firware before flashing" option, or get it straight from Netgear's firmware repository).
The problem will only arise if you decide to publish your upgraded firmware on the net: you could only distribute the GPL bits, not the proprietary ones. There are 2 legal way to do then :
- Provide a small utility to save the proprietary part out of a legal copy, and the final user will use it to add the missing propretary bit from the new firmware using his/her own legal copy.
(That's the way it's done with Google Android, for example: licensed partner like HTC not only have a full built of the opensource system, but also a couple of proprietary Google Apps. The standard procedure with 3rd party firmwares is : backup google apps, flash custom firmware, restore google apps).
- in the specific case of a router, the html interface is rather basic and is a tiny part of the firmware. One could pretty much dump it and use some 3rd party alternative. (OpenWrt's LuCi is an example, as are various embed Linux distros with names ending in "-wall". But you could also go for full geekness and do everything on CLI over SSH).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
http://chrispederick.com/work/user-agent-switcher/
Allows your browser to report itself as something it's not, like firefox/linux as iexplorer/vista. Often this solution works just fine. Have a look; link above.
In my opinion, the GPL specifies that you need to make the source code provided so that an individual could compile it on his own. It doesn't really specify that you need to make it work with a particular device.
That is to say. If I compile software on my Linux system, I can run it from where I build it, or I could copy the executables into some directory where other user's system path will pick it up and effectively have it "installed" so that others can easily execute it. I could even FTP it to another similar machine so that someone could run it there. The GPL is satisfied once I get to the part of building the program so that it's executable. It doesn't require me to provide all the various means to transmit / copy that executable to different places.
In the case of something like a cell phone, building the software alone is probably enough to run it in a simulator or on a development device, if you are a developer in possession of such a thing. The fact that you, as a third-party, don't actually have the an item capable of receiving the software or the means of rendering it so seems immaterial to the word and spirit of the GPL.
In the case of makers of equipment that include software controlled radio transmitters, a vendor is legally prohibited from supplying end-users with the ability to modify code which might alter the software radio's functionality, unless the user provides proof that they've been duly licensed by the appropriate regulatory agency.
It's like saying, "Here's the source code. You can install it on your transmitter if the FCC says its OK, otherwise you're going to need to play with it in a VM or something." That seems perfectly valid to me.
Obvious solution: Out them now.
If a person uses copyrighted work without paying for it, it is theft of service, the same goes for FOSS. In lieu of monetary payment, the FOSS developer requests and legally requires you to acknowledge the provenance of the code, and provide your changes back to the community. If you can't comply, don't use the code period, develop it from scratch yourself, or legally buy the code. Some FOSS developers (if they didn't use upstream FOSS code) would probably be willing to sell you a commercial license to their code, so you don't have to provide your changes to the community. It has nothing to do with control over a downstream product, other than requiring remuneration for services provided. And claiming otherwise is disingenuous.
No GPL license requires you to provide internal closed source development tools or build environments. If you think different, please show me. http://www.gnu.org/licenses/agpl-3.0.html. Some crazy person could come to you and claim otherwise, but the FSF won't be knocking on your door. The same can be said of closed source tools when some NPE patent troll decides they own IP to a tiny part of a process with plenty of prior art. They're crazy, but they're playing chicken to see who flinches first.
no matter how much tinkerers claim otherwise, the original company still ends up getting the blame when user modifications break the product.
Absolutely not true and I dare you to try to prove otherwise. If you get sent a product without factory firmware on it, it gets disclaimed from warranty. If someone tries to publicly shame you, the sane response would be to release a statement that you usually don't discuss customer information publicly, but the product was returned to you with tinkered software, specifically not allowed for warranty claims, and you believe the customer stating otherwise in public is defamatory to your company.
Another example? Okay, how about IDL4? Suppose you want to write a BSD-only OS on top of L4Ka::Pistachio (which is BSD licensed too), and you wanted to make use of IDL4 (which is GPLed) to simplify IPC. You're in again for a bad surprise, because the IDL4 generated stubs are (probably) GPLed too, nullifying your intention to create a BSD-only OS. A simple special rule w.r.t. the generated stubs could have been added by IDL4 developers just as the bison(1) developers thankfully did, but IDL4 devs didn't. So it's not only the "bad greedy companies" that play tricks on build environments, it happens in the OSS community as well (sometimes intentionally, sometimes by accident).
cpghost at Cordula's Web.
Mod this up, might be first comment to actually hit the nail on the head...
Ogre Wedding Planners llc.
I never said for the company to sue them. I said to publicly suggest the customer is making defaming statements.
But in your example, one wouldn't say that because it isn't true. The company should come out and say the customer obtained the product outside of normal retail channels and per your warranty agreement, isn't eligible for service.
Though for low value products like a $50 Linksys router that costs the company less than $10 to replace, it might be worth the good publicity and goodwill to replace it as a courtesy. The company probably has the ability to JTAG official firmware onto the product regardless of the level of bricking, and resell the product as recertified anyway.