John Deere urged to surrender source code under GPL The Software Freedom Conservancy (SFC) has called upon farm equipment maker John Deere to comply with its obligations under the General Public License (GPL), which requires users of such software to share source code. In a blog post published on Thursday, SFC director of compliance Denver Gingerich argues that farmers' ability …
I have never understood why companies find it so hard to comply with a simple license? The GPL has almost no boilerplate or pages of rubbish it's really clear.
In actual fact I feel open source's plain English has helped it stand up in court more than almost anything else. The more complicated the license the easier it is to screw something up or to demonstrate there was no meeting is the minds - that you didn't really understand it.
They probably understand the license very well.
These "big" corporations bet on the "we're to big to lose" and "sue us and it'll cost you more than you us" attitudes. They are at least wilfully blind and most probably wilfully infringing. The only way for them to comply is for the CxO level to face serious personal fines and jail time because of this.
It's not hard to follow the GPL. It's willful dirty tricks. Non-responsiveness, and providing incomplete software (or "discovery materials") when they do "comply" are standard big-company lawyer tricks/recommendations. "We'll play the long game, even if they sue us. Eventually, these little turdlets will give up and go away."
They want their (so-far) captive money stream to continue.
The only reason the companies which did provide some source code didn't do so in EBCDIC, on 14-inch IPI -- an old mainframe interface standard -- hard drive units, was that they hadn't thought of it.
This post has been deleted by its author
People still use the LGPL on some things. I am one of those people. In fact, when I do it, I'm deliberately trying to leave that option to the people who use my library. Even though that's true, the original point overstates it a lot. The code they've mentioned so far isn't using the LGPL, it's using the GPL.
Unfortunately, in many cases, companies that release GPL source code aren't providing much of use. You can get a copy of the Linux source, possibly with a few changes, but the application that is run on top of that Linux kernel and does all the important stuff is proprietary and they won't give you anything from it. Even if you search through all the source they gave you, you'll find a bunch of code you could have already gotten from its canonical sources in most cases. It's much rarer that companies include GPL source directly in the binary they want to hide from users, thus requiring them to GPL that part of the code. This is one reason I don't understand companies that don't comply with the license; most of the time, if they did, they'd be giving up no secrets whatsoever.
I guess that some companies must use some GPLed libraries in their applications' source code, because, well, it's already there, and does exactly what they need it to do, why reinvent the wheel? And for not wanting to release the source code, they probably rely on FOSS advocates not taking them to court because of the sheer costs of such a process. But this is just speculation on my part.
It certainly happens at times, but in a lot of cases where people get involved, it's not. A good example concerns one of the projects that's done a lot to protect their GPL rights: BusyBox. BusyBox used to sue basically everybody that used it and didn't give the source. They were so prolific compared to everyone else that embedded Linux firmware users started making alternatives like Toybox, which is why Android doesn't use it.
We would hope that all this action by BusyBox gave us some useful code, but the developers who looked at all the source from companies they sued found otherwise. They found that most places had either not modified the code at all or had demonstrated their incompetence by patching in code something they could have accomplished by changing flags in the makefile. Rarely was any of the code the companies were hiding useful to the community; it was just hidden out of laziness.
Anyone who knows what the licenses mean wouldn't have a problem using GPLed utilities like an embedded Linux system, because they know they don't have to release anything secret. They would also understand that using a GPL library would require them to release code they want to keep internal, so they should be careful enough not to do so. This clearly won't apply to everybody, but so much GPLed code out there is part of a runtime means that you'll see that more often even for developers who don't understand licenses in the slightest.
Companies have software development teams that integrate some open source stuff or build it on a Linux base, but it isn't like they are consulting the CEO or even the legal team to get their sign off. Probably that happens now but Deere could be using software for a couple decades that's been slowly built up over the years, and no one who was involved in that is still around.
So when they are alerted to this they first say "what, who are these crazy guys that think we have to release our source code?" and then they hear from their development team that "yes, there is GPL code in here like they said, and it has been here a long time so we assumed it had been approved by management/legal". Then they talk to their lawyers who say "we'll look into it" and sense an opportunity for a lot of billable hours for "research" on the GPL, copyright, and so forth!
It isn't hard. They don't want to.
Plenty of companies use GPL source code because they don't want to have to write everything from scratch. They just hope nobody will ever ask them to comply with the terms of the licence.
Actually on second thought I don't think it's a case of hoping, I think most of them believe that they can simply ignore the licence because in their minds it isn't a real licence because no money changed hands.
Could someone educate me on what exactly is required by the GPL? If you produce a system which runs Linux, and you write software which runs on that system, do you have to distribute the source code of your product?
If that's the case there must be huge numbers of systems that break the GPL. Pretty much everything now seems to run on Linux!
GPL is copyleft, that is, if you integrate software source licenced under it, you have to provide your own software's source that linked to it.
Most but not all Linux uses this licence, not all free software uses this licence (I would say most does not). The bits they have used however do.
Just using GPL software, or bundling unmodified binaries alongside your own software, but crucially not linking to it at a source code level, has no restrictions, you do *not* have to provide access to the source for your own software in this case.
All "Linux" comes under these terms. Because there's only one Linux. Let's not confuse a couple of things here. Strictly speaking, Linux kernel is just one component in the entire Linux based system. But with the kernel alone, you can't really do much. The kernel itself comes with GPL2.0, the rest of the system doesn't have to. There are literally tens of compatible licenses, that are even more permissive in nature than GPL, like some variations of MIT or BSD licenses. With these, one can completely close the source code, not publish it, and there's nothing any litigation can do about it. Luckily GPL is not one of these (though 2.0 isn't that strict as the new 3.0 is, and is still the license of choice if you ask Linus), and all FOSS organizations should really be litigating against such companies that break the license agreements and we as users should support them however we can in that endeavor.
...either learn about English common Law on your own or (far better) consult a Lawyer that specializes in contract law. There are people here that could answer your question but the time it would take would deprive them of time working on other more meaningful projects. Understand that the license is a contract, so read the contract and apply what you learn from your studies. In a few weeks you should understand the basics. Don't obese about the finer points unless you have to. Again, this is why we have lawyers. I can't fix my car, or a tractor if I owned one. However I know enough to so that I can keep my promise if I use FLOSS software. It's not that hard. All the bits and pieces are simple. It's when you combine them that things get complex. So if you are an SQL DBA that can't be bothered with learning how to change the break pads on your car it is OK. As long as you can take your car to the people you trust to fix it right.
Downvote because I'm a nerd, not a lawyer. I, personally, don't touch the GPL because outside of the world of Linux it's rather less clear what and how the whole linking thing applies ... or, rather, if things are distributed as a wodge of code, a ROM image, then it would appear to apply to the whole which may well not be possible if there are numerous authors long since gone and various different licences that do play nicely with each other. I note, in particular, that the GPL explanation page seems to drop in some things not actually addressed in the licence itself (political reasons) which is also irksome.
For the OP, yes, pretty much if you make and release a product that contains GPL code, you must also make the actual sources used to build that product available, though for commercial reasons this is usually the open source parts and not the custom bits, so in the rare cases where a company does make something available, it's usually not enough to actually build a new firmware. And, yes, there are many many devices around using GPL inside with no firmware in sight (glaces at Cheap Chinese Crap).
Sometimes, it's sort of maybe. Like this: https://opensource.orange.com/en/sitemap/
My firmware is SG30 sip-fr-7.22.6.1. The most recent archive available is SG30 sip-fr-6.52.12. There's also no info on the Livebox 5 or 6 (the FTTH ones).
The GPL applies to any code that is deliberately licensed under it and any code added to or linked with that code. Crucially, it does not apply to code that interacts with GPLed code with a method less direct than linking. Depending on what components are covered by the GPL, this can lead to different effects.
Let's take a common case: they have a firmware image that boots Linux. Linux is covered by the GPL, so they have to release the source to Linux. If they've modified Linux, for example by putting in extra code necessary to use their hardware, they have to release that too. Not that they always do, but they are required to. When their image starts, it runs an application they've written that is not part of Linux. It uses Linux's system calls to function, but it isn't integrated into the kernel. For now, let's assume that program doesn't use GPL libraries in it. They do not have to release the code for that program, even if it runs on Linux. This is just an example. There are other situations, but this one is common for embedded firmware.
Your assumption: "If that's the case there must be huge numbers of systems that break the GPL. Pretty much everything now seems to run on Linux!" is simultaneously correct and not exactly correct. Firmware that's effectively closed and uses Linux is not a problem if they release the code for the GPLed parts, which in many cases ends up being either completely or almost unmodified copies of the Linux code you can already get. That's not always true, but most of the embedded Linux devices you see all around you have not done anything interesting to the kernel and their required code releases wouldn't be very interesting. Even though it wouldn't help anyone, few of the companies that are required to release that source actually do it, which is why there are GPL violations nearly everywhere.
If you build a system running on GPL software and supply that system to other people/corporations, you must also offer them the source code, including any modifications you made to it (which would include, for example, any custom Linux device drivers for your hardware). It has to be offered in a complete, usable form, including any build scripts etc, so they are able to actually build the software from source and run it on the machine.
So John Deere are obligated to enable people to independently build and get "John Deere Linux" running on their tractors. What they are not obligated to do is supply the source to any of the custom applications that run under that system and presumably are what do the actual work of running the machines. That comes under "mere aggregation", ie closed source software can share the same media and run under a GPL operating system without being obligated to follow the GPL itself.
The distinction is usually made on the basis of whether the closed source code links to the GPL code, or just interacts via an API. If it links it is considered a derivative work, and should be released as GPL.
In that case I would guess that, whilst the actions here are of some value, they will not go to solving the repairability of the hardware as the important applications are likely to remain closed source unless JD have integrated key parts into the firmware. If they have it will then depend on how and what as to where we get to collectively on the repair front.
The gplv2 has a mere aggregation clause so if they are simply using Linux and running their code on it, they shouldn’t be required to release their software. My guess is they have customized some gpl packages or have a tighter integration for a custom distribution embedded in their systems?
I read the blog post and I can't work out exactly what they are attempting to obtain and for what.
I've built embedded Linux OS for industrial systems. Providing the scripts and config is less than half the story.
If the applications are running as separate processes they don't need to supply those and that's where the IPR is. Nor do they need to help you fix anything when you make a mistake.
It's only if they have been stupid enough to use a GPL library that they will have to give away thier application(s).
If they have used an LGPL library they should have dynamically linked to it. I would argue that if you want to replace that library it's your responsibility to make sure the API is compatible.
So if it's the OS build/config just provide it and sit back...
If they were stupid enough to link against a GPL library then own the problem and provide the source.
GPL/GPL V3 does add an interesting limit on embedded and cloud systems.
> So if it's the OS build/config just provide it and sit back...
AIUI, to fulfil the requirements of the GPL would mean the manufacturer would need to provide all the tools necessary to build and configure, yes, but also to install the software on the device - in this case a tractor. And since the GPL prevents placing restrictions on modifications to the code, the user should feasibly also be able to install a modified version of the OS onto the tractor.
John Deere absolutely do not want this to happen. It would mean farmers could take ultimate control of the tractors away from John Deere, whose locked-down systems have meant that their monopoly on repairs and services has become where much of their revenue comes from.
That requirement for installation information only applies to GPL 3 or LGPL 2.1. Linux uses GPL 2.0 only and does not require installation information. A Linux image that you have the source for but cannot install on the equipment offered does not break the license for Linux. They will need to find a GPL 3.0 component in order to have a right to installation instructions.
Indeed - see Tivo-isation
In short, the Tivo PVR uses Linux, but they made the bootloader require a signed binary for the kernel. So you can have your alternative Linux kernel, or even one built from the source they use - but without the keys to sign it, you can't get the bootloader to load your kernel. Thus you have a piece of hardware which runs the Linux kernel, but it's impossible to replace or modify that kernel. And under GPL V2 that's permitted. Under GPL V3 that is not permitted - clauses were stuck in specifically to deal with the Tivo case. But (from memory, it's a while since I last looked), the V3 GPL is very restrictive in many ways and a few (e.g. Linus) think it's gone too far.
So as others have pointed out, there's a distinct possibility that even if JD did supply all the source code - and where GPL V3 is in use, all the tools to build and install that software - but you may not in fact be able to get the system to load and run it if they've followed Tivo's lead.
It's quite ironic when you think about it. Using FOSS, something that is intended to empower the end-user, make them able to adapt the code to their needs, and then subverting it, twisting it, and ultimately using it to do the quite opposite of the original intent, and lock down the entire system. Deere is definitely not the only company doing this, but probably the most infamous one.
You'd be surprised what even the most litigious "protecting our IP" corporations have hidden in their code bases. They love taking a free ride on someone else's labour as it saves money....until it doesn't. I believe <large Wall Street bank> had part of their prop-trading code base using modified open source libraries without releasing the changes (as required) even though there was no real IP in there from a trading perspective i.e. they shouldn't have cared who could use it. From memory they prosecuted/persecuted the developer who did try to release the changes back to the community for releasing their IP.
First time I came across sharp practice by John Dere it was a story that farmers couldn't even perform simple everyday maintenance tasks, firstly because every part (say an oil filter) is 'chipped' so third party products can't be fitted, secondly because even if you could get hold of a 'genuine' part, the machine wouldn't recognise it until it had been registered using the diagnostic tools, thirdly because even just opening the bonnet for a look triggered some sort of trip wire, again needing a dealer reset.
Is that situation any better now?
M.
Or you can just buy from Brother, which is what I did. No chips in their laser or inkjet printers.
And no Epson tricks like having the printer brick itself after a certain number of cartridges until it's sent in "to have the cleaning pads replaced" at double the cost of the original unit.
Sorry to disagree but my Brother HL-4570CDW is definitively using chipped toner cartridges. They stop working once their internal counter has reached the EOL number of pages that they are advertised for. Happened with this printer so far for every cartridge. I also had the predecessor model HL-4070CDW and I believe that you might be correct there that it did not have chipped cartridges.
Sorry to disagree but my Brother HL-4570CDW is definitively using chipped toner cartridges. They stop working once their internal counter has reached the EOL number of pages that they are advertised for.
I'm delighted to tell you that this is not in a chip on the toner, it is an internal register on the printer itself - and you can reset that counter by putting the printer in to service mode. Apparently for your model, this is:
* Turn off printer and open front cover
* Press and hold the cancel button and then turn on printer
* While still holding the cancel and the printer booted up, press the reprint button
This should get you into the service menu, and you can reset the counter on whichever toner it is saying needs replacing.
Epson... I had an inkjet printer that lasted a couple of DAYS before it failed in a way that basically put a short circuit on the power input (a mere 48V!). It managed maybe a half dozen pages. When I took it apart (was stored a while, so guarantee expired), the inside was already coated with ink splatter. If they do this (more ink wasted, more cartridges to purchase) then I can imagine that itty bitty ink pad would get pretty gnarly.
On the other hand, it's a panel underneath that can be prised off. If they weren't arseholes about it, this could be a user level repair...
Well, my Epson died in the middle of printing a dozen pages from a service manual I needed on-site, so I was not in a mood to look kindly on it.
I had to do a lot of research to figure out what was going on as this was a new "feature". At the time, reset s/w was "hax0r w4rez" and not available from anywhere that I trusted, nor were pads available. Mine was simply in the bottom of the printer so replacing it wasn't a problem.
It's left a bad taste in my mouth, and my first printer was an MX-80 with GrafTrax so I'd been an Epson customer for a LONG time.
But they've lost me. I'm voting with my wallet and buying other brands now.
If they'd done "Ink pad is almost full, you need to service your printer soon!" or ANY sort of communication, instead of the printer dropping dead with an obscure error, then I wouldn't have felt like I'd been played for a fool.
To be honest it's not only John Deere. The whole "flog to farmers" market is riddled with a 1970s mentality. Farm machinery, no matter how tough, breaks (usually when you're miles from civilisation) and you need to fix it with whatever is at hand.
In the end it is the consumer that ends up paying when buying food, because the starting price for workshop repairs is usually around the 2000 euros mark, whereas the average farmer will be able to scrape up enough bits from the back of the barn to keep the machine going for a few more weeks so it can finish doing what it has to.
Take away that ability and whole crops can be lost.
Strange that
The german company that supplies the machine tool control units we use run their systems on Linux, with a copy of the source code licence included, you call them up and say "gimme the GPL code you used" and you'll get a nice big file with a copy of that source code.
What you wont get is their own in house source code they use to build the control software that lives on top of their linux installation.
Done that myself.... only too happy to supply a linux OS, and a JRE (centos and java 1.5 i think) not happy to supply the source code used to build my applications...
Careful with that, it also depends heavily on the libraries your app uses, linkage type, as well as development/build/deployment tools. Funny thing is, Microsoft uses or at least used some BSD network code in windows, and even though the BSD license used for the code is much more permissive than that of Linux(GPL 2.0) it still stipulates that the header of the license be included in the binary itself. Microsoft had no problems with that, of course. They duly included the license text in their final binary.
JD has directly given sales to its competitors over the years thanks to their own stupid policy of greed.
In my frequent travels throughout the vast rural areas, I see very successful and growing dealerships of all of their competitors. But most especially those making far less computer controlled equipment, such as Mahindra and Kuboto.
We use an old Ford 8-N tractor. While it will only plow, furrow, plant, spray, and harvest 2 rows at a time, all I have to do is make sure it's got gas and the battery is charged. Hook the appropriate machinery to the three point hitch and the PTO if needed and I'm ready to go.
Nothing electronic on it, still uses the old points, plugs, and condenser ignition system. Use is measured in hours by a cable hooked to the driveshaft.
I look for some of the bigger farms to buy up a lot of these and use them in tandem. Makes more sense to hire a few more people to run tractors that will almost always be available and any average farm guy can fix than have an expensive piece of iron sitting in the shed keeping you from getting anything done. Repairs on the old Ford can be done in the shed down to and including rebuilding the engine.
That's all romantic and misty-eyed and rebellious sounding, but no. Larger farms don't have the time or people to "use them in tandem" - that does not scale.
Farmers don't buy these large machines because they think they'll look pretty in the middle of the field. They buy them to harvest the most crops in the short window of time they have, and to avoid as much backbreaking work as they can.
"they buy them to harvest the most crops in the short window of time they have, "
No, they buy them because the *idea* of doing that. Then their Deere breaks down and they can't do *anything* until next week, when Deere dealer sends someone to fix it. With a cost of thousands.
You totally miss the reality in a farm: Everything will break, at some point, and it *needs* to be fixed *now*.
Idea is from marketing, reality comes from experience. I'd avoid any JD like a plague: Non-repairable tools are worth *less than zero*.
You are speaking from the point of view of a small, independent farmer and you are, of course correct. The big corporate owned farms, operated by employees, are run by accountants. They see partially or fully automated tractors doing 5 times the work more efficiently with only one person paid to do a job that you and your machinery needs more than one person to do as a cost saving. They are taking the risk of maybe loosing time and/or crops against the guaranteed savings on wages over the long term. They probably have service contracts too, with SLAs that costs less than the wages they are saving. Costs that are prohibitive unless you are a big corporate farm owner. They don't care if a crop fails due to failed equipment. It's not their livelihood on the line. The service contract SLA payouts and/or insurance will cover it and it doesn't matter to them if the food supply drops for a while. The profits from their other enormous farms will cover the losses on that one for the duration.
All of the above could also apply to you in terms of cost savings on manpower with all the clever SatNav directed poughing, seeding, spraying etc if you can get that sort of equipment without the overpriced lock-in/out :-)
"They are taking the risk of maybe loosing time and/or crops against the guaranteed savings on wages over the long term."
Error #1: There is *no* long term savings as the equipment *will* break often enough to cause serious problems. So losses, both in short term and in long term. But they are*accountants*, they can't count anything like that. They can count salaries. It's all about known costs vs. assumed savings. Just like you did. Are you an accountant?
Error #2: they don't "take risks", they calculate assumed profit and maximize it. Accountants do not recognize risks: There aren't any. Ever.
" They probably have service contracts too, with SLAs that costs less than the wages they are saving."
Error #2: JD doesn't sell service contracts with SLAs. And even if it did, what can you (or your company) do when they wipe their buttocks with it? Sue them? Good luck on that.
"terms of cost savings on manpower with all the clever SatNav directed poughing, seeding, spraying etc if you can get that sort of equipment without the overpriced lock-in/out "
First you invest huge amount of money to automation and then it doesn't work and you even can't fix it on field, icing on the cake.
"Wages saved" doesn't mean *money* is saved, when an automated tractor costs 15 years salary for a tractor driver ... and lasts few years, if you're lucky. And breaks in the middle of harvest season and no, you aren't allowed to fix it.
Who's the clever guy, really?
Somehow I see a person who hasn't ever worked in a farm telling how it's a wise move to buy a $3M tractor you aren't allowed to fix. How much JD is paying you?
"Somehow I see a person who hasn't ever worked in a farm telling how it's a wise move to buy a $3M tractor you aren't allowed to fix. How much JD is paying you?"
You seem to have taken the exact opposite meaning from my post than I intended.
The point I was making is that accountants and corporations don't think like normal people. They think like the people who used to say "no one got fired for buying IBM". But they think that about John Deere.
Check this video by Louis Rossman on related topic: HOW CORRUPTION WORKS - w/ leaked lobbyist emails & calls from Maryland farm bureau
It's a must see!
GPL-compliance may not help the farmers. It does require publication of modifications to original source or code based on GPL-licensed APIs, but a lot of GPL-code has LGPL-licensed APIs which may be utilized for any purpose including proprietary code. In the case of Linux this include the kernel API for modules. The farmers may gain access to minor modifications to the operating system, but that is worthless without source for the manufacturers hardware-drivers and agricultural applications.
The way JD (and others) lock 'customers' in is very probably by the use of ESNs.
These do have many legitimate uses [1] but what these companies do is a consequence of technology not being able to prevent bad actors from turning it to their advantage.
Here is how it can be done (which might give a clue on how to reverse engineer it).
Each sensor has an ID and an ESN (ESNs are usually 64 bit numbers)
The entire list of sensors (IDs) and corresponding ESNs are written to non-volatile memory (probably an EEPROM).
The list is read at powerup and compared with the enumerated devices - mismatch == you have top pay through the nose for someone to come out and...
Connect to onboard computer.
Get current list of enumerated devices (ensuring that only the ones that have been newly installed are permitted to be updated)
Write new list of devices to EEPROM.
Parasites.
If a kernel driver needed to be linked for the device enumeration process then there might be interesting things that could be done. For at least the last 20 years, manufacturers of the devices have provided equipment vendors to define their own IDs, ESNs and so on.
1. In safety critical avionics (as an example) the serial number of every board is tied to traceability information so that if faults occur more often than they should, the batch of components (and manufacturer) can be easily determined. There are many examples of reasonable use of the technology. These parts have been around in various forms for at least 30 years.
Finally that icon is relevant again, because both annoying companies intercepted when Louis Rossmann picked up the Right to Repair crowd about Apple (the fact that he repairs iphones despite Apple blocking him at every chance), and a handful (more than that) of disgruntled John Deere customers showed up on the same RTR meeting.
Just a reminder.
For avoiding such things happens a legal service for OSS need to be established: At the one hand it has a team of lawyers specialized for OSS license related issues(lawyers can work part-time), and at the other hand it provides a service to register legal entities in different countries representing the project(usually the people who have right to merge the PR will be involved), and the legal service is authorised by the entity to handle legal issues around the project(Unlike Apache this won't involve a ownership transfer, the project is legally owned by the entity)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
