The short answer: It's complicated. But to give answers at face value:
1. Unfortunately, in most cases, nothing. GPL violations are rampant, and usually without serious consequence for the infringer.
2. Like any other copyright violation, through the courts. But there is a history of successful GPL enforcement by the mere threat of going to court (since what you're usually after is compliance, not damages).
3. Depends heavily on the jurisdiction, but in most of them, it certainly helps to have a copyright holder involved (I would go as far as to say it's a necessity). But you also need money, so most likely, something like the EFF or SFLC.
I think the Software Freedom Conservancy is probably the most active in trying to enforce GPL compliance on free software in general, and for the Linux kernel in particular.
Some kernel developers have assigned their copyrights directly to the SFC, and some have signed agreements for SFC to do this enforcement on their behalf. (see https://sfconservancy.org/copyleft-compliance/ )
Obviously there are many people and organizations who own copyright to parts of the linux kernel, and any of those can attempt to enforce the GPL on the kernel in court.
If Conservancy win their lawsuit against Vizio, then a precedent will be set that anyone who receives binaries based on GPL code will be able to sue for compliance, based on the third party beneficiary doctrine within contract law. This potentially depends on if the jurisdiction allows for specific performance as a remedy for contract violation.
Actually, the Linux kernel devs and SFC really don't see eye to eye on this.
I'd say Harald Welte did a ton for GPL enforcement - really very impressive. He asked for but did not demand release of stuff he didn't have copyright for as well which normally worked.
Anyone who has copyrighted code in the kernel they're using can sue or a copyright holder can work with an organization like the EFF or Software Freedom Conservancy to sue them.
One of the big things with the Linux kernel is that it's GPLv2 and the GPLv2 doesn't offer an opportunity to come back into compliance. Any violation leads to an automatic termination to all rights. Most of the big kernel developers have said that they won't enforce GPLv2 "death penalty", but there's a lot of Linux developers out there and Linux doesn't have authors assign copyright so there's a huge number of copyright holders.
> You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
That "NEVER SETTLE" author bio here is funny in this context. I thought it the whole repo creator was some disgruntled coder who wrote it to push for never settling out of court (but it turns out to be the slogan for the phone).
sm8250 sounds like a Snapdragon thing from Qualcomm. In other words: unlikely to happen because of NDAs. Even if one plus wanted to it wouldn't be up to them.
Edit: It seems there are a lot of FOSS warriors in here, let me clarify: historically, Qualcomm has been legally hostile with both FOSS software communities as well as with their own customers. They will not give anything for free, and if they can slap a ton of NDAs on it, they will. This isn't about if it is GPL compliant or if it is legal or not in some court somewhere in the world, it is about their track record (which is similar to Broadcom). If oneplus has unencumbered source code they have to ship it with their GPL release, if not, they did a stupid thing by being dual-encumbered by conflicting licenses and it's anyones guess what the end result is going to be.
An NDA does not override the GPL, and does not shield from its obligations. As you say, it's "not up to them" to decide which legal obligations they will honor.
I didn't write anything about overriding, did I? I presented a problem scenario where one plus is screwed because they are in between conflicting legal settings.
The NDA probably has explicit terms outlining the consequences of breaking it, so I can't answer that. But as for the GPL, whatever damages or remedy a court might impose for the violation of copyright.
Not complying with the GPL makes this legally equivalent to distributing a copy of Star Wars: Return of the Jedi with each phone. I'm sure no-one would be dismissing that as something unlikely to bear consequences. And the law protects Star Wars and GPL'd code equally.
Does that matter if the company is based in China? Unless they are mainly exporting to a western country where customs could halt imports, legal action against china hasn't been very effective.
It's hard to tell since most GPL violations are simply ignored, and most NDAs are secret to begin with. In general, the NDA-spamming companies have more money than GPL-defending groups, so from that perspective a real-life consequence could be that the company has to spend money on legal either way, and might simply pick the cheapest route. In some cases (Linksys for example), making a small modification and then releasing everything that wasn't encumbered was enough to solve both issues.
In general, breaking an NDA is far more costly than violating the GPL, even if it were enforced like NDAs are.
Just because it's unlikely to happen doesn't mean it's overriding anything. They might simply delete all references, out-lawyer anyone who tries to sue them or simply ignore everything since they are based in China. Again, just because it is illegal doesn't mean therefore something will change. It just means it's illegal. Then you have litigation, but that might not change anything either. So the situation is the same, which means that your proposed action is unlikely to be the resulting outcome.
If running in kernel mode under Linux, it is debatable whether most separate binary modules can and are effectively organized in a way they can be considered not a derived work of Linux. The only one I've personally seen managing to do that without much doubt was nvidia.
The binary blobs question has never really been resolved. You'll find kernel devs and other open source community members on both sides of the issue.
My sense is that most have no interest in forcing the issue. The closest (something similar) came to being forced was the VMware ESX-related GPL case but that ended up dismissed for unrelated reasons.
This is not the “binary blobs” issue (which is still debated, as you say). This is the “binary kernel modules” issue, which is pretty much settled: Even though they are commonly used and distributed, the kernel can never explicitly allow it! This is what would happen if they did: https://lwn.net/Articles/162686/
The problem is that here you are not just distributing what is possibly a derived work (the kernel modules themselves), like what NV was doing. Here you are distributing a single enduser product which contains both the actual GPL work itself (the kernel) AND the kernel modules combined in a way that's essential for the product itself (i.e. it's not "mere aggregation"). That's a much more fragile position, and I rather doubt that whether the modules are a "derived work" or not plays a role, since if anything you are violating the kernel license/distribution terms themselves.
Btw, Qualcomm and MediaTek do _not_ block kernel source releases by OEMs in any way.
You will still want to get the source tree from the OEM even for new devices though.
While the GKI means that kernels are the same across recent devices, kernel modules and device tree sources for the specific device aren't part of that.
They don't block source releases indeed, but only for unencumbered sources. What the ODM should probably have done is either make it out-of-tree or make an unencumbered implementation (if that is the problem at all) and ship that. Or maybe they just made a mistake or were lazy and will include it after the weekend when people are actually back at work.
This happens every new Android version with OnePlus.
OnePlus releases them usually a few months behind the end of initially release cycle getting all the older phones onto the newer build. Covid has been making this worse, plus people left the team when Oppo and OnePlus merged teams.
Kinda wish they would just stop doing it, but this is why phones maybe shouldn't ship with a working OS anyways and make the user supply it instead.
If by law you can't ship your own OS then you have an incentive to make it as easy as possible for third-party OS developers to make it work with your device and to make it as easy as possible for the user to install said third-party OS.
So that you are not betrayed by a software that you just purchased but that you cannot change? In what way allowing this betrayal is better for anyone but the people who benefit from it (e.g. by selling your private data, or whatever their unchangeable proprietary software does)?
Of course users should be allowed to install new operating systems, but there’s no reason for the phone not to come with one at all. You don’t need to boot the stock ROM even once if you don’t want to - just boot into recovery mode and flash a new one right out of the box.
A phone shipping without an operating system at all would make it unusable for the vast majority of the general public.
> A phone shipping without an operating system at all would make it unusable for the vast majority of the general public.
You're assuming the bootstrapping process is complicated, manual, and failure-prone though.
There's absolutely no reason why the initial boot couldn't simply involve plugging an included usb thumbdrive into the usb port and turning the device on. It comes on in an uninitialized state, finds an appropriate image provided by the vendor in a normalized format on the thumbdrive, tosses on the screen some information and a YES/NO option. DONE.
When the vendor is providing the phone and the image, the shit should Just Work.
But by requiring this be the initial process, we'd ensure that everyone could always easily install another image on their hardware by the same mechanism.
It literally just adds a step as difficult as plugging in the phone to charge when first turning it on.
What prevents that initial image from locking the bootloader to prevent the installation of alternate images (possibly by blowing fuses or another OTP mechanism)?
Addressing only the first-boot problem doesn't guarantee down the line ability, which seems more important to me than first-boot ability.
If we had regulatory consumer protections at this level, I think it goes without saying the same regulations would require any such locking down during the initial provisioning would require opt-in by the consumer.
The intended salient point of my previous comment is there's just no reason for this to be something impossible to navigate for the majority of users.
Personally I think it's important for the provisioning to be part of the process for everyone to undergo. When it's effectively part of the unboxing process, it ensures manufacturers invest in maintaining and polishing the functionality. It will be less buggy, it will be less error-prone, and it helps educate the public on the otherwise invisible line separating firmware/software from hardware.
If you had a strong regulatory framework, it seems like it would suffice for the law to include "it must be possible to install an alternate OS image without the use of tools [other than cables supplied with the device]; completely wiping the device may be required to prepare it for an alternate OS."
I don't see it being a good tradeoff to make hundreds of millions of users take the action and wait out the delay of an OS installation so that tens of thousands of users can feel more smugly guaranteed that they'll be able to install an alternate OS. If you're willing to guarantee an install is possible, allowing a default OS installation seems consumer-friendly on balance to me.
It could be argued that not being able to boot alternate software, which might be necessary to diagnose the hardware, goes against the right to repair.
> It could be argued that not being able to boot alternate software, which might be necessary to diagnose the hardware, goes against the right to repair.
We really need to amend Right to Repair with explicit concepts WRT programmable devices. If the software/firmware isn't strictly immutable (think a ROM in a microwave or fancy digital scale or thermometer type thing), the owner should have an ensured and reasonablyfacilitated Right to Reprogram (perhaps with additional clauses regarding reproducibility, i.e. ensuring owner's ability to reproduce the original mutable state as delivered at first-sale).
> this is why phones maybe shouldn't ship with a working OS anyways and make the user supply it instead
I think this goes against the main reason people buy phones from mainstream brands. The reason is the features and ecosystem that come with such devices.
If you are a tinkerer or prefer to install your custom OS, then you'd choose a "foss" device like the pinephone, librem or other.
If you buy a device for convenience, with the expectation that it just works, you buy an iPhone.
If you are somewhat in the middle of that spectrum, you consider an Android device where you trade some convenience with the ability to intervene more deeply with how the device works.
>If you are a tinkerer or prefer to install your custom OS, then you'd choose a "foss" device like the pinephone, librem or other.
Except the hardware and ecosystem of those suck in comparison to The Big 2 (iPhone and Android). If I could install a custom OS on iPhone, I'd buy one in a heartbeat. Otherwise I'm stuck with AOSP on my Pixel.
> Except the hardware and ecosystem of those suck in comparison to The Big 2 (iPhone and Android).
Yes, and the irony is that Apple can afford to develop impressive hardware thanks to their "vertically integrated" offering. People like it and spend a lot of money to have it.
Why don't FOSS phones have the budget to create this kind of experience then? Maybe there are ways for this to be improved, or perhaps we shouldn't try to decouple a phone from the ecosystem it was created for.
A lot of money and energy is now being pointed at trying to make Apple and Google loosen their grip on hardware. At the same time (in my view), this would not address the root cause, which is that there are no effective means for economic advantage generated by foss software on proprietary hardware to find its way back to the community.
Yeah I mean GNU/X11/Linux obviously. I don't always want to write it out because most people know what I mean.
The Android userspace is actual garbage. It's very heavy and the UI paradigm means you're sitting staring at blank screens while you wait for things to load or switch or whatever and things are constantly getting evicted from memory and forced to restart (or crash sometimes.) It made some dubious amount of sense when phones had 512mb of ram but once you hit 1Gb it just became this over complicated mess that adds nothing but pain.
Android's app ecosystem isn't much better, it's mostly converging with iOS as a tool for corporations to deploy their telemetry into your life rather than a platform for running useful community maintained software. Because of this most of the useful software projects for it are slowly dying if they're not already dead.
> The Android userspace is actual garbage. It's very heavy and the UI paradigm means you're sitting staring at blank screens while you wait for things to load or switch or whatever and things are constantly getting evicted from memory and forced to restart (or crash sometimes.) It made some dubious amount of sense when phones had 512mb of ram but once you hit 1Gb it just became this over complicated mess that adds nothing but pain.
Compared to your average desktop computer, Android at least tries to use SELinux, and by-app unix user partitions. Systemd/Linux "Flatpak app" and "snap app" security by comparison is awful.
I think that Termux, (once you get past Zygote forking) to be reasonably fast and responsive, and it runs on almost barebones Android/Linux fine. So I don't think it's fundamentally related to the Android userspace platform as well.
> Android's app ecosystem isn't much better, it's mostly converging with iOS as a tool for corporations to deploy their telemetry into your life rather than a platform for running useful community maintained software.
I think we all need more libre software in our lives. Or at the bare minimum, more things like F-Droid; not ideal since the base OS is still somewhat locked, but a start.
Systemd is not a desktop environment... The closest equivalent is Gnome or Elementary OS because those are trying to provide a dedicated platform for developers.
> I think this goes against the main reason people buy phones from mainstream brands. The reason is the features and ecosystem that come with such devices.
I.e. anti-competitive bundling of software and hardware. There is no reason one could not buy a generic phone, the same as one buys a generic PC, and then install whatever "mainstream" OS one wants.
You are also assuming that because installing an alternate OS is difficult now (in large part because manufacturers make it difficult, if not impossible), it would continue to be just as difficult in the future.
I think you presume too much idealism. It's more along the lines of "if you want a 'free' phone, you take the shiniest one your carrier gives you for contract renewal"
Oh you want more GB's (metric unspecified)? This one is only 100 currencies more, but it'll just be five more per month for 24 months.
That's all? What about for a better camera? Oh, for a top of the line photo app, you'll want our xl series, just ten more currencies a month!
It's not hard. They should just upload the ones they used to build the image they distribute. If they don't they are just not worth buying anything from. I wish more developers would care. Are you a known license violator? No responsible disclosure for you, no "workaround in our app to make it work better on your device, fix your shit yourself", etc., etc.
65 comments
[ 2.7 ms ] story [ 82.4 ms ] thread1. Unfortunately, in most cases, nothing. GPL violations are rampant, and usually without serious consequence for the infringer.
2. Like any other copyright violation, through the courts. But there is a history of successful GPL enforcement by the mere threat of going to court (since what you're usually after is compliance, not damages).
3. Depends heavily on the jurisdiction, but in most of them, it certainly helps to have a copyright holder involved (I would go as far as to say it's a necessity). But you also need money, so most likely, something like the EFF or SFLC.
Some kernel developers have assigned their copyrights directly to the SFC, and some have signed agreements for SFC to do this enforcement on their behalf. (see https://sfconservancy.org/copyleft-compliance/ )
Obviously there are many people and organizations who own copyright to parts of the linux kernel, and any of those can attempt to enforce the GPL on the kernel in court.
https://sfconservancy.org/copyleft-compliance/vizio.html https://en.wikipedia.org/wiki/Third-party_beneficiary https://en.wikipedia.org/wiki/Specific_performance
I'd say Harald Welte did a ton for GPL enforcement - really very impressive. He asked for but did not demand release of stuff he didn't have copyright for as well which normally worked.
Also does a vendor FAQ - https://gpl-violations.org/faq/vendor-faq/ to help folks get it right.
One of the big things with the Linux kernel is that it's GPLv2 and the GPLv2 doesn't offer an opportunity to come back into compliance. Any violation leads to an automatic termination to all rights. Most of the big kernel developers have said that they won't enforce GPLv2 "death penalty", but there's a lot of Linux developers out there and Linux doesn't have authors assign copyright so there's a huge number of copyright holders.
> You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
There are lots of articles on this like http://www.fosspatents.com/2011/08/most-android-vendors-lost..., https://www.samba.org/samba/samba/ftp/slides/linuxcollab-why...
Realistically, most of these things get settled or ignored and the world moves on with a bare minimum of enforcement.
Edit: It seems there are a lot of FOSS warriors in here, let me clarify: historically, Qualcomm has been legally hostile with both FOSS software communities as well as with their own customers. They will not give anything for free, and if they can slap a ton of NDAs on it, they will. This isn't about if it is GPL compliant or if it is legal or not in some court somewhere in the world, it is about their track record (which is similar to Broadcom). If oneplus has unencumbered source code they have to ship it with their GPL release, if not, they did a stupid thing by being dual-encumbered by conflicting licenses and it's anyones guess what the end result is going to be.
> In other words: unlikely to happen because of NDAs
Not complying with the GPL makes this legally equivalent to distributing a copy of Star Wars: Return of the Jedi with each phone. I'm sure no-one would be dismissing that as something unlikely to bear consequences. And the law protects Star Wars and GPL'd code equally.
The law, maybe. But governments/courts protect them very unequally, as only one of them has people throwing money at politicians.
In general, breaking an NDA is far more costly than violating the GPL, even if it were enforced like NDAs are.
My sense is that most have no interest in forcing the issue. The closest (something similar) came to being forced was the VMware ESX-related GPL case but that ended up dismissed for unrelated reasons.
And nvidia recently decided that they actually don’t care about any of that and decided to release their sources anyway.
You will still want to get the source tree from the OEM even for new devices though.
While the GKI means that kernels are the same across recent devices, kernel modules and device tree sources for the specific device aren't part of that.
OnePlus releases them usually a few months behind the end of initially release cycle getting all the older phones onto the newer build. Covid has been making this worse, plus people left the team when Oppo and OnePlus merged teams.
Kinda wish they would just stop doing it, but this is why phones maybe shouldn't ship with a working OS anyways and make the user supply it instead.
I really hope you’re joking. In what way would that be better for anyone but the most hardcore tinkerers?
While at it, erradication of shovelware.
A phone shipping without an operating system at all would make it unusable for the vast majority of the general public.
You're assuming the bootstrapping process is complicated, manual, and failure-prone though.
There's absolutely no reason why the initial boot couldn't simply involve plugging an included usb thumbdrive into the usb port and turning the device on. It comes on in an uninitialized state, finds an appropriate image provided by the vendor in a normalized format on the thumbdrive, tosses on the screen some information and a YES/NO option. DONE.
When the vendor is providing the phone and the image, the shit should Just Work.
But by requiring this be the initial process, we'd ensure that everyone could always easily install another image on their hardware by the same mechanism.
It literally just adds a step as difficult as plugging in the phone to charge when first turning it on.
Addressing only the first-boot problem doesn't guarantee down the line ability, which seems more important to me than first-boot ability.
The intended salient point of my previous comment is there's just no reason for this to be something impossible to navigate for the majority of users.
Personally I think it's important for the provisioning to be part of the process for everyone to undergo. When it's effectively part of the unboxing process, it ensures manufacturers invest in maintaining and polishing the functionality. It will be less buggy, it will be less error-prone, and it helps educate the public on the otherwise invisible line separating firmware/software from hardware.
I don't see it being a good tradeoff to make hundreds of millions of users take the action and wait out the delay of an OS installation so that tens of thousands of users can feel more smugly guaranteed that they'll be able to install an alternate OS. If you're willing to guarantee an install is possible, allowing a default OS installation seems consumer-friendly on balance to me.
We really need to amend Right to Repair with explicit concepts WRT programmable devices. If the software/firmware isn't strictly immutable (think a ROM in a microwave or fancy digital scale or thermometer type thing), the owner should have an ensured and reasonably facilitated Right to Reprogram (perhaps with additional clauses regarding reproducibility, i.e. ensuring owner's ability to reproduce the original mutable state as delivered at first-sale).
this enforcement is actually a very good idea!
I think this goes against the main reason people buy phones from mainstream brands. The reason is the features and ecosystem that come with such devices.
If you are a tinkerer or prefer to install your custom OS, then you'd choose a "foss" device like the pinephone, librem or other.
If you buy a device for convenience, with the expectation that it just works, you buy an iPhone.
If you are somewhat in the middle of that spectrum, you consider an Android device where you trade some convenience with the ability to intervene more deeply with how the device works.
Except the hardware and ecosystem of those suck in comparison to The Big 2 (iPhone and Android). If I could install a custom OS on iPhone, I'd buy one in a heartbeat. Otherwise I'm stuck with AOSP on my Pixel.
Yes, and the irony is that Apple can afford to develop impressive hardware thanks to their "vertically integrated" offering. People like it and spend a lot of money to have it.
Why don't FOSS phones have the budget to create this kind of experience then? Maybe there are ways for this to be improved, or perhaps we shouldn't try to decouple a phone from the ecosystem it was created for.
A lot of money and energy is now being pointed at trying to make Apple and Google loosen their grip on hardware. At the same time (in my view), this would not address the root cause, which is that there are no effective means for economic advantage generated by foss software on proprietary hardware to find its way back to the community.
The Android userspace is actual garbage. It's very heavy and the UI paradigm means you're sitting staring at blank screens while you wait for things to load or switch or whatever and things are constantly getting evicted from memory and forced to restart (or crash sometimes.) It made some dubious amount of sense when phones had 512mb of ram but once you hit 1Gb it just became this over complicated mess that adds nothing but pain.
Android's app ecosystem isn't much better, it's mostly converging with iOS as a tool for corporations to deploy their telemetry into your life rather than a platform for running useful community maintained software. Because of this most of the useful software projects for it are slowly dying if they're not already dead.
Compared to your average desktop computer, Android at least tries to use SELinux, and by-app unix user partitions. Systemd/Linux "Flatpak app" and "snap app" security by comparison is awful.
I think that Termux, (once you get past Zygote forking) to be reasonably fast and responsive, and it runs on almost barebones Android/Linux fine. So I don't think it's fundamentally related to the Android userspace platform as well.
> Android's app ecosystem isn't much better, it's mostly converging with iOS as a tool for corporations to deploy their telemetry into your life rather than a platform for running useful community maintained software.
I think we all need more libre software in our lives. Or at the bare minimum, more things like F-Droid; not ideal since the base OS is still somewhat locked, but a start.
I.e. anti-competitive bundling of software and hardware. There is no reason one could not buy a generic phone, the same as one buys a generic PC, and then install whatever "mainstream" OS one wants.
You are also assuming that because installing an alternate OS is difficult now (in large part because manufacturers make it difficult, if not impossible), it would continue to be just as difficult in the future.
Same for OS and computers and phones.
The setup process is already cumbersome both for Windows and for MacOS.
Oh you want more GB's (metric unspecified)? This one is only 100 currencies more, but it'll just be five more per month for 24 months.
That's all? What about for a better camera? Oh, for a top of the line photo app, you'll want our xl series, just ten more currencies a month!
For 70% of sales, the is matters zero.
Do you believe this is something most people would want as a product experience, or something most people would be capable of doing?
The weird Western altruism embedded in the GPL is completely alien to Chinese culture.