Hacker News Reader

Comment by catern | Hacker News Reader

>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...

View on HN

"Part of the motivation is certainly to get away from the GPL requirements of using Linux,"

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?

Then why is it not licensed under the GPL, like Linux?

I'll ask a related question: Why license it under the GPL? What does Google gain? (and what do you gain)

You gain the knowledge that a device running Fuchsia is running code that's publicly available.

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.

I'm not trying to, I just don't think that using GPL would make them any nobler, except in the eyes of GPL-fanatics.

No, you actually don't. You gain knowledge that some of the code is maybe publicly available, just like linux. The rest, however, is often still kept secret, legally or not, and has been since time immemorial.

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 :)

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.

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 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.

Sure.

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?

It sends a positive signal to a group of people who really don't matter - the very small minority of users who like open source and aren't already placated by AOSP existing - but a negative one to people who do - their vendors.

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.

Let me restate that: "GPLing Fuschia sends a negative signal to vendors that don't want to release the source for their drivers."

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.

So let me get this straight: your proposed alternative to Android is just... not having Android at all?

>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.

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.

>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.

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.

"- 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?"

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.

How, exactly, would it hurt? Perhaps by... discouraging use from companies that want to keep their changes private? I am completely fine with that. Proprietary code should not be allowed anywhere near the kernel or hardware support. Would it hurt in any other way?

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!"

Linux does not have wide open-source hardware support on mobile phones, so that argument simply doesn't work in this space - you're arguing in favour of a supposed status quo that doesn't actually exist in the first place.

>How, exactly, would it hurt? Perhaps by... discouraging use from companies that want to keep their changes private?

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?

Your forgetting an important one. The default is a bsd-3 like license. Google prefers to release everything under that single license unless there are strongly compelling reasons to do otherwise, and "it can't hurt", even if it we're true, is not strongly compelling.

> (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) [...]

> 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.

> 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?

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 :

http://www.wi-fiplanet.com/tutorials/article.php/3562391

https://en.wikipedia.org/wiki/DD-WRT

> Even the FSF doesn't think GPLv2 is the right license for linux?

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.

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.

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 licenses are better for businesses.

First, it's already been done. Like, all the time. People already do this with Linux and ship it in user devices.

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.

It would be hard to argue the inverse hypothetical outcome, but I do think that licensing (GPLv2) had a significant role in where Linux is today. It is precisely because the license obligates the distributors to share the code that made the whole a better software and a more attractive platform to contribute to. In fact, most contributors, big and small, work with the upstream to streamline their contributions. Having to share the source has worked out well for both programmers (individuals, companies) and end users in the long run.

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.

> why?

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.

If you aren't distributing the binaries, you don't have to release your changes to GPL software. That's what the AGPL tried to fix.

> 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!

"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.

> "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.

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.

That's a good point, but the Linux development community also has a practice of very aggressively refactoring Linux internally / breaking internal APIs whenever it makes sense, and they update all code that's in Linux mainline but don't provide patches or migration guides for anyone else. I've definitely seen the perspective that this is not only done for technical reasons but to put pressure on people to incorporate their code into mainline when possible.

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.

>In fact, the fuchsia kernel is completely open source, so ...

That's orthogonal. Open source != GPL (which lots of companies avoid). Or is it GPL too?

It is not.

https://fuchsia.googlesource.com/magenta/+/master/kernel/LIC...

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.

OK, but that's irrelevant.

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.

"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.

"Things changed after enough time and revenue with a huge gap between ASOP and Android experience."

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.

> still happily compile Google's entire kernels

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 release their kernels

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.

"You are thinking of userspace."

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.

> You can literally go download and compile the entire fuchsia kernel, right now.

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.

It's a microkernel, somewhere in the middle of the spectrum. Not as extremly reduced as L4, but not the heavyweight that Mach is, either.

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.

Yes, indeed, that makes it even more distressing that they didn't bother to license even the core of the system with the GPL. It sends a signal that they really completely don't care about the freedom for users to modify the software and run it on their own hardware.

the "users" of fuchsia most likely will not be developers only, if GPL is just a symbol, a golden star to show you are a good kid then it does not look so foundamental to me.

as other have said the driver API should actually make that easier (in intents).

Why license the kernel GPL if it doesn't matter any because every vendor would be totally willing to put it up in any case (or defer to the official repo because they made no changes anyway)?

Such an approach smells of virtue signalling, and IMNSHO we have way too much of that already.

Don't forget the difference between "free software" and "open source". Open source was, from day one, pushed as a tool of capitalism: big companies could make more money if they collaborated on common code with each other. The free software movement (whence the GPL) always operated on the idea that, in an ideal world, software wouldn't be copyrighted at all and everyone would just publish their source because that was the right thing to do. The open source movement (whence the MPL) merely argued that open source was the profitable thing to do.

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.

>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...

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.

Google didn't invent Android though, they bought it. Fast time to market probably trumped all other concerns at the time. This project probably has a less aggressive timeline.

I'm not sure what that has to do with it. Apple didn't invent OSX/MacOS either, they bought it from NeXT and then used that base to build iOS. Google bought Android in 2005 so they had plenty of time to switch out kernels if licensing concerns were really a factor for them.

Would they? Especially given that they'd already heavily modified their fork to meet their specific needs with ashmem, binder, and logcat? And the fact that they pretty much completely changed direction with user-space development in 2007 to meet the iPhone and not BB?

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.

GPL implicit patent grab, Google thus prefers more open licenses than GPL.

Reply on news.ycombinator.com