I know, in fact, this is pretty much a non-consideration, so i'm really curious what makes you believe it is.
In fact, the fuchsia kernel is completely open source, so ...
If you were to bug the SFLC/others, you'd see Google is, in fact, quite happy releasing kernel changes, and is pretty much one of the only companies that has either pushed vendors to open source drivers, or, in a number of cases, rewritten proprietary android drivers as open source just so it can release them!
However, regardless, even assuming you were right, you end up having to put together a compliance release either way, and it's not like the kernel part of that compliance release is any more difficult than the other software.
"That would of course be a disaster for user autonomy and freedom, but why should Google care about that..."
This will be shocking, but the kernel people working on fuchsia do, in fact, care about that!
If they didn't, they wouldn't have open sourced everything, including the kernel.
I'm honestly having a ton of trouble following your logic here.
They want to be able to keep stuff proprietary, but have open sourced it since day 1.
They want vendors to be able to release proprietary drivers, but those vendors can and already do so for linux?
What exactly do you think is different and horrible?
"Happy" is a funny word though. Google is legally obligated to release kernel changes and legally forbidden from shipping kernels that incorporate other people's GPL-incompatible drivers.
It is definitely true that there are other companies who aren't happy to follow the law, from the Allwinners who just don't care to the VMwares who see the law differently to the Samsungs who seemingly honestly didn't realize what the law said. But given that Google is a large, relatively old company based in the US, you can't extrapolate very much from them being willing and even happy to follow the law in a straightforward fashion. It just means they know what the law is. It doesn't mean they like the law, or that they like the situation that caused the law to apply to them.
The explanation most consistent with the facts is that Linux being under GPLv2 allowed Google to get Android to market quickly with a robust, portable, well-designed kernel, and the things we like about free software (ability to hack on it and modify it, likelihood of gaining others' improvements) aligned with their business needs at the time, as a new entrant in a difficult market—but that Google, as a company, has no particular idealism regarding strong copyleft.
If they want to ship proprietary drivers from other vendors, they can't legally do that with a GPL kernel, and it's implausible to believe that they'll do so anyway and wait to get sued and try to play lawyer games. The simplest path forward is to keep making GPL reimplementations of those drivers for now... and to start making a non-GPL reimplementation of the kernel for the future.
If anything, the fact that they have been pushing vendors to open-source their drivers or rewriting proprietary drivers shows just how much they would have a business interest in a Linux-quality kernel that isn't under the GPL.
I suppose the OP was also talking about the changes done to improve linux for datacenter workflows, afaik there is no obligation to release the changes there.
Newer versions of Linux get steadily better at performance, so it seems likely to me that Google is primarily incorporating their changes upstream to save effort over maintaining a local fork (and not risk that fork getting out-of-date), and not so much because they find that open-sourcing their code is inherently worth doing.
That's orthogonal. Open source != GPL (which lots of companies avoid). Or is it GPL too?
Because cloud providers have started to build their own hardware to eke out performance advantages versus other cloud providers. It's not a far stretch to conclude that Google will prioritize its kernel's development for its proprietary hardware and not have to release any of the secret sauce to the public.
It's their software, so they get to choose. It's like arguing NetBSD should use the GPL license.
As for why it generally doesn't make sense to use the GPL for this:
Even the FSF doesn't think GPLv2 is the right license for linux?
GPL'ing linux hasn't prevented any of the problems you mention, either in theory or in practice, so why do the same thing and hope for a different result?
(If you've never read it, i suggest you go read the various threads where linus, etc explain that in practice, the only approach that works is carrot, not stick)
It would be the same for Mozilla or anyone else who got popular enough with GPL software and had lots of vendors and OEMs who used their software.
GPL'ing the kernel or not does not change that some people don't follow the rules. You can have them sign it in blood if you want. They'll just work around you or ignore you, as long as there is money to be made. Also, once you are big enough, cutting them off will just attract regulators.
In practice, you will not get them to follow the rules by having a "war on gpl violators" any moreso than we have solved the US drug problem by having a "war on drugs".
If you (or others here) dream is of an ecosystem where everyone is forced, under pain of death, to follow the GPL, it's pretty unrealistic.
It's not what happens now, it will never happen.
Rather than pretend that's a realistic way to get people to release source, i'd rather not pretend. i'd rather see something different tried that may have some hope of success.
> If you (or others here) dream is of an ecosystem where everyone is forced, under pain of death, to follow the GPL, it's pretty unrealistic. It's not what happens now, it will never happen.
And in response, see Bradley Kuhn's talk at LibrePlanet this year: https://media.libreplanet.org/u/libreplanet/m/understanding-... or the LWN writeup at https://lwn.net/Articles/719610/
Kuhn's argument is that the actual world has involved the stick and not (just) the carrot: GPL enforcement lawsuits have actually existed, and we can't really distinguish people who claim to believe in the carrot from people who would totally have ignored the GPL if it weren't for the realistic threat of lawsuits.
We do live in a world where people are forced under pain of copyright infringement lawsuits to follow the GPL. It is literally what happens now. As you yourself pointed out upthread, Google is quite conscientious about following the GPL, to the point of rewriting proprietary drivers. Even Debian doesn't do that (Nvidia, Broadcom, etc. drivers are available in non-free). Do you think that's because Google thinks the GPL is a great idea? No! Google knows that losing their license to use the Linux kernel is a real possibility under GPLv2 section 4, and would in fact be death for the company.
So why not GPL (v3) it anyway, if the GPL is so ineffective?
After all, what you're telling me in your posts is that Google wants vendors to contribute back, but it can't force them.
I don't want vendors to be able to create proprietary extensions. You claim Google also doesn't want vendors to create proprietary extensions.
- If the GPL is effective, why not use it?
- If the GPL is ineffective, it can't possibly hurt and at the very least it sends a positive signal. So why not use it?
Edit: I'm not sure why you edited your post rather than reply. But I don't think you have really answered my question as it is put here. Is the GPL effective or ineffective? Ineffective, you seem to say. So what's the harm? You claim you care about sources being released. Am I understanding you wrong?
Maybe some employees of Google don't like the GPL. But simultaneously they want all driver sources to be released? But simultaneously they think the GPL is ineffective and won't achieve that?
Your post doesn't really add up. Could you list the reasons why Google isn't using the GPL for Fuschia as bullet points, or something?
Fuschia is designed so that driver sources don't need to be available, and we can still upgrade the kernel. This is better than doing exactly the same thing as before which didn't work. It solves a practical problem (being unable to upgrade your phone's OS) through technology rather than licensing.
That is fine. Any hardware that is released should come with full source code for its drivers. Vendors that are unwilling to comply, should not be releasing hardware. Since it would be infeasible and restrictive to legally enforce, we can just forbid them to use our popular open source kernels instead.
Please, consider the alternative world you want us to regress to! The present reality is practically utopian, compared to a world where the majority of drivers are proprietary! You want desktop/laptop/server computers to have the same awful, unfixable drivers as Android!? Fuschia will not magically make vendor code any less crap!
And, the "practical problem" here is created by licensing. You said it yourself:
>Fuschia is designed so that driver sources don't need to be available, and we can still upgrade the kernel.
This is a problem of licensing. If we were actually talking about purely technical solutions to purely technical problems, this problem wouldn't even exist. We would never have this bizarre problem of unreproducible binary artifacts sitting on our hardware without the ability to rebuild them.
Here is a thought: Maybe if Google started (threatening to) enforce the GPL against vendors, this would be fixed. Sure, it would also destroy their business relationships. But it would actually fix this security problem, today, immediately.
Fine for you. Not fine for the vendors (or Google).
>Please, consider the alternative world you want us to regress to! The present reality is practically utopian, compared to a world where the majority of drivers are proprietary! You want desktop/laptop/server computers to have the same awful, unfixable drivers as Android!?
It worked very well for Windows and OS X, so?
I'd rather have proprietary drivers than no drivers because few vendors are willing to make them open source.
In fact, I'd rather have proprietary drivers than community made, reverse engineered ones too.
If we could have open source vendor provided drivers of course that could be ideal. But in reality we would just have less drivers.
This is naive and you know it. In reality, what would happen is 3-4 years from now, once the lawsuit has run its course, maybe vendors would need to publicize their binary sources, but given that much time they might just develop in house solutions.
1. Of course it can hurt. that's just silly to say.
2. As for why not use it? Because it's ineffective?
You answered your own question?
This seems like a pretty basic GPL zealot argument at this point ("It's completely ineffective but you should do it anyway!") , and i'm pretty uninterested in continuing such arguments.
As a concluding remark, I'll just repost what I posted elsewhere in this thread:
>Consider what happens if you're wrong. What happens if the GPL actually is the reason why Linux has such wide open-source hardware support? Then say goodbye to hacking on Fuschia on your own hardware...
>I'm not willing to take that risk.
"I beseech you, in the bowels of Christ, think it possible you may be mistaken!"
Yes. That would hurt, because as a user I am very much interested in the products of those companies.
And Google wants them as an OS vendor too.
>I am completely fine with that.
Well, the vendors and Google are not. And neither would I be.
Proprietary code should not be allowed anywhere near the kernel or hardware support.
So that only second tier vendors bother applying?
It hasn't eliminated the problem, but it has worked in some cases to the benfit of the vendors and customers.
For example the open source Wifi router community sprung up from one such effort :
Yes, they want a stronger license---GPLv3.
(Edit: I read your statement as "GPL is the right license"; I corrected my post.)
> GPL'ing the kernel or not does not change that some people don't follow the rules. You can have them sign it in blood if you want. They'll just work around you or ignore you, as long as there is money to be made. Also, once you are big enough, cutting them off will just attract regulators.
Your argument could extend to the entire free software movement---to all software written under the GPL. Your argument could be extended to _any_ license! It's dismissive of the impact of the free software movement and the successes of the GPL, and it's dismissive of the legal system as a whole.
You don't have to take my word for it though, go ask bradley kuhn if he thinks that vendors have a tendency to comply with the GPL for the kernel :)
I'm not willing to take that risk.
You can't change the Linux kernel and then close the source and sell it. That's why the GPL is much better for users and other licenses are better for businesses.
Either you believe such a thing is GPL compliant, in which case, yay, they already could do it.
Or you believe they are violators, but nobody has been able to stop them, in which case, that falls into my "in practice, ...".
Because in practice, it has not stopped them
Either way, nothing has changed :)
As for arguably-compliant ways:
Because they can already do like nvidia does, and just have the interfaces be in the kernel, GPL that, and then load binary blobs?
Also remember, even the company doing something more shady (as far as anyone knows), vmware, was not successfully sued for their kernel GPL violation.
So theoretically, they could just drop all pretense and not even do that.
Stating that there are some number of cases of GPL violations that haven't been enforced or are in the gray area is not a logical base for the argument that the idea of having to share the source code should be abandoned. In fact, history shows otherwise - that Linux has had more success (as measured by uptake globally) than any other non-GPL open source kernel ecosystem.
Similarly, just because there may be people who can find loopholes in certain well-intended laws and regulations is not a good reason to abandon their intents. Instead, the questions should be - can we keep these intents and fix the loopholes or make the enforcement more straightforward? I think Google could, but maybe it's not in their immediate interests, one of which may be closer to - how do I upgrade the kernel without recompiling that other stuff.