Earlier quoted context omitted.
Do you though? Google, as the liscenser is free to keep portions of fuschia under lock and key, so that's not really the case.
You're really not convincing me that Google's intentions are good. Not licensing under GPL is a clear signal that Google is prioritizing hardware partners' needs over their users. Just like Android.
How sandboxing works in Fuchsia
61–70 of 172 posts
Re: How sandboxing works in Fuchsia
#62Re: How sandboxing works in Fuchsia
#63Earlier quoted context omitted.
"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. " 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"?
"You can literally go and compile the entire kernel, right now." 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.
Re: How sandboxing works in Fuchsia
#64Earlier quoted context omitted.
I'm being paranoid here, but would allowing an Apache license let vendors put custom spyware and DRM into the kernel that they wouldn't have to release the source for?
In practice: No more or less so than they could do under linux.
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.
Re: How sandboxing works in Fuchsia
#65Earlier quoted context omitted.
In practice: No more or less so than they could do under linux.
How do you figure? I see you keep posting that Linux can run proprietary binary blobs. No one is arguing against this. The argument is that these binary blobs will ship by default inside fuchsia OS and that the creators of fuchsia have chosen a license that has no provisions against this. 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 lic…
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.
Re: How sandboxing works in Fuchsia
#66Earlier quoted context omitted.
Fuchsia uses a microkernel (Magenta) which is more secure and technically elegant, but usually comes at the cost of performance. 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).
I'm guessing that you think it's a bad thing but I don't quite understand your position. 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", the…
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).
Re: How sandboxing works in Fuchsia
#67Earlier quoted context omitted.
I guess generically in that it has a touchscreen, limited hdd size, etc. It's an i5 Intel x64 CPU though.
I believe my phone runs a 64bit ARM with eight 2.3ghz cores and has the same amount of ram as the base Acer model?
Re: How sandboxing works in Fuchsia
#68Earlier quoted context omitted.
Then why is it not licensed under the GPL, like Linux?
The real answer is because the people involved believe the licenses they are using are even more free. IE they do not subscribe to the FSF's ideology. 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 t…
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?
Re: How sandboxing works in Fuchsia
#69Re: How sandboxing works in Fuchsia
#70Earlier quoted context omitted.
>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…
Companies are embracing open source these days, but not the GPL. We see that with gcc and clang, or in the way MacOS uses older versions of tools just to avoid GPLv3: 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.