> I then decided to contact Insulet to get the kernel source code for it, being GPLv2 licensed, they're obligated to provide it.
This is technically not true. It is an oversimplification of the common case, but what actually normally should happen is that:
1. The GPL requires the company to send the user a written offer of source code.
2. The user uses this offer to request the source code from the company.
3. If the user does not recieve the source code, the user can sue the company for not honoring its promises, i.e. the offer of source code. This is not a GPL violation; it is a straight contract violation; the contract in this case being the explicit offer of source code, and not the GPL.
Note that all this is completely off the rails if the user does not recieve a written offer of source code in the first place. In this case, the user has no right to source code, since the user did not recieve an offer for source code.
However, the copyright holders can immediately sue the company for violating the GPL, since the company did not send a written offer of source code to the user. It does not matter if the company does or does not send the source code to the user; the fact that the company did not send a written offer in the first place is by itself a GPL violation.
The written offer is part of the licence, as is the need to respond to that offer with the source code offered. It is all part of the same agreement.
A written offer on its own would not normally be directly enforceable in many (most?) jurisdictions, for the same sort of reason that retailers can't be held to incorrectly published prices (in the UK at least, a displayed price is an “invitation to tender”, not a contract or other promise) except where other laws/regulations (anti bait&switch rules for instance), or the desire to avoid fighting in the court of public opinion, come into effect.
But in this instance, the written offer and the response to that offer are part of the wider licence that has been agreed to.
> If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code.
That section (and similar in section 6c) is not about the written offer of source code. The written offer of source code is instead covered in section 6c.
Maybe it’s not technically “breach of contract”, and an offer might or might not be a contract. But if you don’t honor an offer you made, you must surely be guilty of something. Otherwise, all offers would be meaningless and worth nothing.
I think they're just saying the GPL doesn't really cover consumer/distributor (dis)agreements, it only covers copyright. While the spirit of the GPL is user-first, it still has to be realized within the confines of copyright law. Even though many people might conflate the spiritual goal and the legal agreement, it doesn't grant "users" any extraordinary legal powers.
It's not illegal to not honor written offers, it's illegal to distribute copyrighted material in violation of it's license.
Be sure to read the top comment where someone who claims to have worked for the company provides some inside information.
In my experience, this is quite common when the development of hardware is viewed as a cost center and is outsourced to various providers and teams. Those providers and teams churn a lot and nobody who worked on that is likely still involved with the company via contracts or direct employment.
Front line support people aren’t equipped to respond to these requests. If you’re lucky they’ll get bounced around internally while project managers play hot potato with the e-mail until it gets forgotten. You might get lucky if you go the corporate legal route, but more likely is that the lawyers will do the math on the likelihood of you causing them actual legal trouble for anything and decide it’s best to ignore it.
When I worked at a company that had a history of GPL drama one of the first things I did was enforce a rule that every release had a GPL tarball that was archived and backed up. We educated support people on where to forward requests. I handled them myself. 7 out 10 times, the person on the other end was angry because they assumed the GPL entitled them to all of our source code and they were disappointed when they only found GPL code in the tarball. It really opened my eyes to some of the craziness you get exposed to with these requests (though clearly not the polite and informed request in this Reddit thread) which is probably another reason why support staff are uneasy about engaging with these requests.
> 7 out 10 times, the person on the other end was angry because they assumed the GPL entitled them to all of our source code and they were disappointed when they only found GPL code in the tarball.
Well, if your non-GPL code direcly linked to, or closely interoperated with, any GPL code, those users would have been right.
As always, the solution is to contact their legal department, preferably via a lawyer. Engineers and support staff are not going to risk their jobs making legal decisions about giving away company property.
The FSF could help a lot here by publishing demand letter templates outlining the statutory and precedential basis for license enforcement and recovery of damages.
But it's the company's legal department which would evaluate that claim. Because it's a legal claim. Licenses aren't magic spells, they're social agreements and non-executive employees don't want to get in trouble for making executive decisions.
If the only GPLed component used is the Linux kernel, you probably aren't entitled to any noteworthy source code. It's well established that using the kernel doesn't create a GPL requirement userspace software running on the same device, and the most likely arrangement here is a completely-uncustomized kernel paired with an open-source userspace program that does all the interesting bits.
So can someone tell me - a non-insulin-dependent individual - why would an insulin pump need to be (controlled by?) a phone (in this case, the Nuu phone referenced)?
Surely there is a way to cheaply obtain bluetooth and a controller without saying "we'll just use this already existing hardware - that happens to be a whole-ass phone - because it's $5 from China"?
Kinda feels like that just screams data-stealing, regardless of where it was made.
Security… The PDM is walled off completely, it cant install apps, its not on wifi, you cant change any settings. The issue is that a PDM technically could easily kill you, by giving you a lethal dose of insulin.
Funny thing is that the newer Omnipod 5 from the same company works with regular phones now, but only in th US.
Until recently, if you offered a pump that _could_ be controlled by another device (such as a phone) you would have to offer your own "controller" device, even if 99.9% of your customers have a phone already.
So, this companion device is kind of a thing that Insulet had to release. You'll see this with CGM's too -- there's a small companion device sold with the Dexcom G7 (the "controller"), even though everyone just uses their phone.
This is kind of a regulatory quirk; basically from the FDA's point of view you had to have a complete standalone system, that did not include the phone, in order to be able to prescribe it. I think they do not require companion devices any more, it's OK to release something that requires the user to have a phone.
"we plan on users having a phone to connect to it and use primarily. FDA requires a primary/backup. well it's already phone-controlled, go find a phone that works with it. needs to be cheap, cuz no one will really use it anyway"
That makes a little more sense. I was imagining the development process involving both devices, rather than one device first, then determining what the second would be later.
I get mad triggered by software license violation discussions.
Please for the love of all that the FSF thinks is holy - just file a damn lawsuit if you are telling me they are violating the law. State your claim and have a court sort it out.
It costs hundreds of dollars. For a medical device? Seems like a good deal.
Let me guess. Omnipod. They've had some pretty bad recalls too. Never in a lifetime would I trust my well-being to their p.o.s. hardware / software combo. Apologies that person in this thread that worked there, but I hope you are working for a better company now.
Oh well. The whole thing has already been reverse engineered. Look up Loop or Trio or OpenAPS. Diabetic companies like Insulet have been very lax when it’s come to the hacking of their devices. This isn’t really that big a deal. What we need right now is help REing the Omnipod 5
I’m aware of a few people working on REing the Omnipod 5. The furthest issue that I have seen is that when a PDM/Omnipod 5 app signs into your insulet id, it gets a private key from the API which is stored in the keychain (and uses SSL pinning to prevent MiTM retrieval of the private key). When pairing with the pod they exchange public keys and then a derived key from the devices private key+pods public keys, but haven’t been able to get a copy of a private key yet to make further progress.
Not all though, I've been looking at Minimed pump reverse engineering (which would be just reading glucose data, not controlling the pump), and that's not solved yet, at least not for the 780G. But I hope it will be, and perhaps I'll be able to contribute.
I don't work for Medtronic. But it's extremely unlikely that will happen. It's not merely a matter of reverse engineering -- after the original medtronic "hack" / reverse engineer efforts (the ones that lead to the original openAPS system being developed) the FDA put out new guidance on cybersecurity protections for insulin pumps.
The communication between your phone/pump or glucose sensor/pump is encrypted now for all newer devices.
> Diabetic companies like Insulet have been very lax when it’s come to the hacking of their devices
TL;DR: Not the FSF, but SFC; email compliance@sfconservancy.org
The dominant legal theory is that the GPL can only be enforced by the party holding the copyright. SFC's lawsuit against Vizio is strategically trying to establish precedent changing that; establishing that end-users are "third party beneficiaries" under the GPL, so others can enforce the GPL; but for now the copyright holder is the only one who can enforce it.
So the FSF could only take it up if the violation is on projects that do copyright-assignment to the FSF (i.e.: most GNU stuff). If you do find a violation of GNU stuff, the process is "email license-violation@gnu.org". I do not know what process Craig and Krzysztof use when triaging reports and deciding what to pursue.
Many Linux-kernel contributors (also, SFC member projects such as OpenWrt, Git, Qemu) have assigned their copyright to SFC or named SFC as their legal representative (also, SFC member projects; so SFC can take up something like this. Similarly, you can report violations to them by emailing compliance@sfconservancy.org (see https://sfconservancy.org/copyleft-compliance/help.html for more info).
Now, SFC is aware of more violations than they could ever possibly pursue, so they're strategic about pursuing ones that are high-impact. I'm not sure how they decide that. But I can say that medical devices are near-and-dear to them, between executive-director Karen Sandler's implanted defibrillator and policy-fellow Bradley Kühn's blood glucose monitor.
This is technically not true. It is an oversimplification of the common case, but what actually normally should happen is that:
1. The GPL requires the company to send the user a written offer of source code.
2. The user uses this offer to request the source code from the company.
3. If the user does not recieve the source code, the user can sue the company for not honoring its promises, i.e. the offer of source code. This is not a GPL violation; it is a straight contract violation; the contract in this case being the explicit offer of source code, and not the GPL.
Note that all this is completely off the rails if the user does not recieve a written offer of source code in the first place. In this case, the user has no right to source code, since the user did not recieve an offer for source code.
However, the copyright holders can immediately sue the company for violating the GPL, since the company did not send a written offer of source code to the user. It does not matter if the company does or does not send the source code to the user; the fact that the company did not send a written offer in the first place is by itself a GPL violation.
(IANAL)
That doesn't sound right to me.
A written offer is not the same thing as a contract.
A written offer on its own would not normally be directly enforceable in many (most?) jurisdictions, for the same sort of reason that retailers can't be held to incorrectly published prices (in the UK at least, a displayed price is an “invitation to tender”, not a contract or other promise) except where other laws/regulations (anti bait&switch rules for instance), or the desire to avoid fighting in the court of public opinion, come into effect.
But in this instance, the written offer and the response to that offer are part of the wider licence that has been agreed to.
> If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code.
Similar clauses in Sec 6.
[1] https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
It's not illegal to not honor written offers, it's illegal to distribute copyrighted material in violation of it's license.
In my experience, this is quite common when the development of hardware is viewed as a cost center and is outsourced to various providers and teams. Those providers and teams churn a lot and nobody who worked on that is likely still involved with the company via contracts or direct employment.
Front line support people aren’t equipped to respond to these requests. If you’re lucky they’ll get bounced around internally while project managers play hot potato with the e-mail until it gets forgotten. You might get lucky if you go the corporate legal route, but more likely is that the lawyers will do the math on the likelihood of you causing them actual legal trouble for anything and decide it’s best to ignore it.
When I worked at a company that had a history of GPL drama one of the first things I did was enforce a rule that every release had a GPL tarball that was archived and backed up. We educated support people on where to forward requests. I handled them myself. 7 out 10 times, the person on the other end was angry because they assumed the GPL entitled them to all of our source code and they were disappointed when they only found GPL code in the tarball. It really opened my eyes to some of the craziness you get exposed to with these requests (though clearly not the polite and informed request in this Reddit thread) which is probably another reason why support staff are uneasy about engaging with these requests.
Well, if your non-GPL code direcly linked to, or closely interoperated with, any GPL code, those users would have been right.
The FSF could help a lot here by publishing demand letter templates outlining the statutory and precedential basis for license enforcement and recovery of damages.
Surely there is a way to cheaply obtain bluetooth and a controller without saying "we'll just use this already existing hardware - that happens to be a whole-ass phone - because it's $5 from China"?
Kinda feels like that just screams data-stealing, regardless of where it was made.
Funny thing is that the newer Omnipod 5 from the same company works with regular phones now, but only in th US.
So, this companion device is kind of a thing that Insulet had to release. You'll see this with CGM's too -- there's a small companion device sold with the Dexcom G7 (the "controller"), even though everyone just uses their phone.
This is kind of a regulatory quirk; basically from the FDA's point of view you had to have a complete standalone system, that did not include the phone, in order to be able to prescribe it. I think they do not require companion devices any more, it's OK to release something that requires the user to have a phone.
"we plan on users having a phone to connect to it and use primarily. FDA requires a primary/backup. well it's already phone-controlled, go find a phone that works with it. needs to be cheap, cuz no one will really use it anyway"
That makes a little more sense. I was imagining the development process involving both devices, rather than one device first, then determining what the second would be later.
Thanks for the insight!
Please for the love of all that the FSF thinks is holy - just file a damn lawsuit if you are telling me they are violating the law. State your claim and have a court sort it out.
It costs hundreds of dollars. For a medical device? Seems like a good deal.
The communication between your phone/pump or glucose sensor/pump is encrypted now for all newer devices.
> Diabetic companies like Insulet have been very lax when it’s come to the hacking of their devices
Absolutely not true, not any more.
How do they triage and decide what to pursue?
The dominant legal theory is that the GPL can only be enforced by the party holding the copyright. SFC's lawsuit against Vizio is strategically trying to establish precedent changing that; establishing that end-users are "third party beneficiaries" under the GPL, so others can enforce the GPL; but for now the copyright holder is the only one who can enforce it.
So the FSF could only take it up if the violation is on projects that do copyright-assignment to the FSF (i.e.: most GNU stuff). If you do find a violation of GNU stuff, the process is "email license-violation@gnu.org". I do not know what process Craig and Krzysztof use when triaging reports and deciding what to pursue.
Many Linux-kernel contributors (also, SFC member projects such as OpenWrt, Git, Qemu) have assigned their copyright to SFC or named SFC as their legal representative (also, SFC member projects; so SFC can take up something like this. Similarly, you can report violations to them by emailing compliance@sfconservancy.org (see https://sfconservancy.org/copyleft-compliance/help.html for more info).
Now, SFC is aware of more violations than they could ever possibly pursue, so they're strategic about pursuing ones that are high-impact. I'm not sure how they decide that. But I can say that medical devices are near-and-dear to them, between executive-director Karen Sandler's implanted defibrillator and policy-fellow Bradley Kühn's blood glucose monitor.
I saw that spelling for the first time last week, I think.
Did he change his name? Has he always been Kühn, but went with Kuhn, because Umlaute are hard for Americans?
https://fedi.copyleft.org/@bkuhn/115461658201124515