So I'm not clear what the puropse of fuchsia is. I understand it's an os which may replace android or chomeos but why the move away from linux based systems? Both are open source platforms.
Part of the motivation is certainly to get away from the GPL requirements of using Linux, so that Google and its partners can release products to users that have proprietary modifications to the kernel, without giving those same users access to the source code of the kernel. That would of course be a disaster for user autonomy and freedom, but why should Google care about that...
Edit: This isn't just about the license, but also about the structure of the code. Fuschia is based on a microkernel. "Microkernel" doesn't just mean "modular kernel"[1] it also means "run drivers and systems in a separate process with a separate executable". That imposes performance penalties, but it can enforce a better programming style... and it also allows low-quality proprietary vendor code to be isolated from the base system and not have to pass quality checks or open its source.
[1] Linux is very modular despite being monolithic, and there have been academic operating systems like https://en.wikipedia.org/wiki/Language-based_system which are extremely modular and well designed despite (or perhaps because of) operating entirely in ring 0. Microkernels of course require modularity; but modularity doesn't require microkernel. The key problem with having all your code linked into one executable, of course, is that it requires you to have all your code...
Certainly why?
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.
So:
- 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.
http://penguindreams.org/blog/the-philosophy-of-open-source-...
The OSS utopia pushed in the the 1990s, with tools like Gimp being one day comparable to Photoshop, never really happened.
A lot of companies embracing open source have succeeded in building an OSS utopia for themselves internally, and selling software as a service to other people. There's an unprecedented number of people employed by big companies working on things that are nominally free software, but it's free software to do things like large-scale container management, not photo editing. (The free software folks, to be fair, did see this happening and responded with the AGPL, but that strategy seems to have had about zero effect.)
And even Photoshop has realized that switching to a billing model that more closely resembles SaaS than traditional proprietary software is more profitable. But a better comparison is something like Thunderbird vs. Outlook or LibreOffice vs. MS Office: those fights have ended up with both participants losing out to Gmail/Outlook 365/etc. and Google Docs/Office 365/etc., which are free-of-charge, high-quality, and even more non-free than proprietary software that in theory at least you could disassemble.
Kernels are an entirely different class of thing. I'm fine with permissive licenses for higher-level software such as clang or GIMP.
But I'm not looking forward to a world where I can't get the source code for a kernel that will actually run on real hardware.
It's already painful to compile and run Android from source. Fuschia will make it just impossible.
You literally live in this world right now.
"It's already painful to compile and run Android from source. Fuschia will make it just impossible."
You can literally go download and compile the entire fuchsia kernel, right now.
How is that "impossible"?
Only the kernel Google puts out for the development image. I think the parent meant more in the sense of real devices. It is already quite painful to run custom Android builds from source in real devices, where at least the kernel has copyleft protections. It is quite likely that real hardware running Fuchsia will not come with their sources, since Fuchsia isn't copyleft.
Android discussions started that way. Things changed after enough time and revenue with a huge gap between ASOP and Android experience. Their security fixes vs Apple are also now abysmal. Might be a hint at the future of Google's next OS.
No, things changed for other vendors and for other parts. You can, AFAIK, still happily compile Google's entire kernels.
You are thinking of userspace.
Google's, sure. Some vendors make it painful (and in some cases, even impossible) to compile kernels for their devices.
Google is legally obligated to release kernels for their device. With Fuchsia, neither it nor any of the other hardware makers would be. Google might still continue to release their kernels — say, for developer contributions — but other vendors are quite likely to not do so.
Vendors won't modify fuchsia or its microkernel (magenta). That's the point behind the driver APIs in fuchsia. This should allow Google to update the full system, kernel included, while leaving the vendor drivers, which run in user mode and will still work due to the API being still supported, alone.
If Android is ported to fuchsia, that would solve the android update problem for good.
Is it really Android advertised to the West that people want if it doesn't have the userspace? That's like Windows open-sourcing the kernel but all the needed apps are proprietary. Might as well consider the overall thing proprietary unless your customers exclusively want the kernel plus also-ran software.
The kernel will probably be the one component vendors (chipset or OEM) won't ever feel the need to touch (except for new architectures), since they can put everything in userland processes that they want to keep hidden. Not even the GPLv3 would help there.
Such an approach smells of virtue signalling, and IMNSHO we have way too much of that already.
as other have said the driver API should actually make that easier (in intents).
I've heard this argument before without any factual evidence to back it up. Google could have easily used the FreeBSD kernel and not had to deal with the GPL if they had wanted to.
I seriously doubt they had time to switch to a more user-hostile kernel, given what was already in place. Especially given that they had their hands full programming a user-hostile libc and a user-hostile driver framework that would help hardware vendors with their user-hostile driver-blobs.
Capability-based security is a big step in that direction. I don't know what "they're both open-source" has to do with it, obviously there are other reasons to choose between different pieces of software besides the license.
Google's position as the primary/sole developer of Fuchsia also gives them the control to build the OS in commercially lucrative ways that don't necessarily earn the approval of the Linux open source community (programming shortcuts, proprietary/non-GPL extensions, etc).
Is it a new standard that if company develops code, they are morally required to seek "approval of the Linux open source community" ?
Are we applying this standard only to Google, or all companies?
If writing and open-sourcing code under permissive license is bad if it's done without "approval of Linux open source community", then how bad, in comparison, is what e.g. Apple or Microsoft do (not open sourcing iOS or Windows)?
They're saying that if Google were to pursue their OS goals, specifically using Linux as a base, then they would likely end up doing things that would earn the scorn of the Linux community (at least; it's more likely that what they want to do is GPL-violating).
Historically, with (ancient) 1st generation microkernels like Mach (used in OSX/IOS), sure.
Else, this article's decent: http://blog.darknedgy.net/technology/2016/01/01/0/
Patches for these largest features weren't accepted into mailine - they're not really fully fit for a general-purpose kernel and Google's and Linux kernel teams differ in opinions if they're even required and how they should be implemented. As such, it probably makes sense for Google to use their own, fully internally developed, kernel which is built from ground up to handle IPC, security and mobile chips in the way Android/ChromeOS expect it to.
I highly doubt that.
"Magenta targets modern phones and modern personal computers with fast processors, non-trivial amounts of ram with arbitrary peripherals doing open ended computation"
Magenta is the name of the Fuchsia kernel.
https://fuchsia.googlesource.com/magenta/+/HEAD/docs/mg_and_...
No it's not. Fuchsia is device agnostic. It's for mobile devices, personal computers, IOT devices, etc. Just because it uses Flutter does not restrict it to mobile devices.
:)
Google has the resources to undertake developing a new OS, which they obviously believe will have benefits over being based on Linux like ChromeOS is. Being free of legacy constraints gives them the freedom to explore better ways to achieve they're objectives, e.g Security and UI performance.
We've actually learned a few things about operating systems since 1970, and today's hardware vastly different from the time-sharing systems of that day. It would be really useful to just implement an OS based on more modern ideas and see where it goes.
I have no idea what Google is planning for Fuscia, but I hope that's part of it.
Perhaps because whether it's "open source" is not that much of a concern, but rather whether it has the kind of control (over its evolution) and/or next generation design they want?
We probably need open source hardware for this to go away and to be free.
It makes sense that Google would like to move away from Linux given how important mobile security is and will become in the future. They certainly have the resources to get it right, starting from a clean slate.
Then why don't you try? Google has $200,000 USD waiting for you to exploit a fully patched Pixel. Or are you too rich to make it worth your while? If you're going to say something that silly at least have the technical prowess to walk the talk.
Second, 200k USD for a vulnerability of such caliber is peanuts.
Third, you must have missed this: http://blog.trendmicro.com/results-mobile-pwn2own-2016/
https://www.youtube.com/watch?v=Zm6ziX5pqt8
>Second, 200k USD for a vulnerability of such caliber is peanuts.
I think that's the going rate offered by companies that buy exploits like Zerodium. Do you know of a company offering a better price?
>Third, you must have missed this: http://blog.trendmicro.com/results-mobile-pwn2own-2016/
First, the hack was impressive because of all of the exploits they had to chain. Perhaps this gives you an understanding of just how difficult it really is and why I called your comments regarding Android security silly. Secondly, I don't believe their hack was possible via RCE and needed physical access to the device. Third, you neglected to mention that not only was the iPhone hacked, but it was done so twice. Additionally, the 2 iPhone hacks earned more money than the Nexus 6P hack. Did you also want to comment on the state of iOS security?
None of that takes place in the public eye, but of course one can figure some of it out if one pays attention. In some cases, one can also extrapolate what the state of this "underground" is by examining the research that does become public.