This is an open legal question, which the Conservancy v Vizio case will hopefully change; in that case, Conservancy is arguing that consumers have the right to enforce the GPL in order to receive source code.

Are you saying that in the general case if you send someone a written offer for something and then don't honour it, you are in breach of contract?

That doesn't sound right to me.

A written offer is not the same thing as a contract.

Doesn't seem incorrect if, extra steps aside, the company is ultimately obligated to provide the source code by the terms of the GPL.

IANAL, but this is my understanding.

What's the consideration in the written offer? Promises aren't enforceable in court. For a contract to be enforceable, it has to be an exchange of something, not a one sided offer.

https://www.law.cornell.edu/wex/consideration

The written offer with a limited term of three years is just one permitted method of distribution. If an offer was never made then they're not covered by that clause and are bound to comply by other means without the protection of the three year window.

> The GPL requires the company to send the user a written offer of source code

It should be noted that this is just one of three options that someone who wants to distribute binaries of GPL code can choose from. It's the most commonly chosen one, and one is only available for noncommercial distribution, so the odds are good that this is the option they are using.

The other available option is to accompany the binary with the source code.

That one leads to an interesting possibility where someone could end up with a binary and there is no one obligated to provide source to them. As far as I know this has not actually arisen, but it seems like something that is bound to happen sometime.

Suppose company X decides to make a generic hardware platform that other companies can buy to build their products on. X's platform is basically a small single board computer with WiFi, Bluetooth, dual, USB ports, a couple Ethernet ports, and some GPIO ports. X ports Linux to their hardware.

When X ships a system it comes with an SD card with a Linux distribution installed including their custom kernel. It is configured to boot from the first SD card slot, and then to run a custom login system that looks at the second SD card slot and if there is a card in there it mounts it, looks for an executable on its root name application.exe, and runs that as root. X includes in the box a small thumb drive with a copy of the source code for everything on the SD card.

The idea is that a company Y that wants to make something like a WiFi access point or an air quality monitor can buy these boards from X, put them in a case with whatever peripherals or sensors they need like air quality sensors, write the software for the application, put it on an SD card, and put that in the second SD card slot.

So lets say Y buys 1000 of these systems from X, builds 1000 of their access points or whatever from them, and sells them.

One of their customers asks Y for the source code of the GPL parts. Does Y have to provide it?

I'd say they do not. They are not making copies or derivative works. They are just receiving physical copies from X and passing those on unmodified to their customers. This should fall squarely under the First Sale Doctrine in US copyright law, and similar rules in other jurisdictions.

How about if they ask X for a copy?

X has made copies and derivative works and distributed them. But X satisfied their GPL requirements by including a thumb drive with the source with each board they shipped to Y.

In America, maybe this is the case. In Germany, it seems an end user can sue them directly for source code.

> This is not a GPL violation; it is a straight contract violation

But GPL is a contract

I think the distinction you are pointing would be between a gpl licensor-licensee contract, rather than a licensee-user contract.

(IANAL)

> 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 was directly linked to, or closely interoperated with, any GPL code, those users would have been right.

It is not company property.

It also doesn’t apply to driver modules if you use gpl shim (eg nvidia drivers and many others) so i dont get why author thinks they violate anything

Then it should be trivial for them to provide the source code.

The OP almost certainly isn’t a copyright holder for the Linux kernel. They probably would have said if they were.

In what planet does a lawsuit cost hundreds of dollars?

Since a company building it themselves hasn't gotten it in the form of a binary from someone else that they're just passing along to you and their use is commercial, they don't satisfy either condition of GPLv2 3(c), but they'd need to satisfy both in order to be able to exercise that option.

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.

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.

One thing is that you need to tell the insulin pump when you eat food so it can deliver insulin to cover the food. I bet that is a lot easier in an app than some separate controller device.

Insulin pumps are paired with glucose monitor. I bet it is handy to check glucose levels to make things are stable and correct if off.

I was troubled by my own comment. How exactly did Bosch handle this? I went back and checked and in fact the rejection email came from their email server, it was an "access denied" type email that I originally misinterpreted as a "you don't have access" type message leaving me annoyed but really I took away and remembered a wrong impression. Looking more carefully, the message doesn't mean anything subtle, it just means the email address (oss-request@bshg.com for the record) doesn't exist. Which is bad, but not nearly as bad as I portrayed it above. Apologies (for the record) to Bosch.

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.

Well it looks like insulet is the primary offender here, and Nuu (the Chinese company) is just the hardware manafacturer

An actual good use case for tariffs.

Why would you come to that conclusion instead of the obvious one being that the kind of people to use Hacker News are the same kind to prefer old Reddit?

Some of us just prefer the old version, so when we copy the link from our URL bar it's to the old version.

No