Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fuchsia overview

fuchsia.dev

Post reply on HN
Print view View original

71–80 of 235 posts

Re: Fuchsia overview

#71

Post by joking »

ColanR wrote: post #33
mbrukman wrote: post #30

Earlier quoted context omitted.

Disclosure: I work at Google (but not on Fuchsia), and I contribute quite a bit to open-source projects. Disclaimer: I'm not a lawyer, this is not legal advice, etc. I'm not sure what you mean by "you grant a license to Google to use it in non-proprietary code" — was that a typo and did you mean "proprietary"? In any case, Apache/BSD/MIT licensed code can already be used in proprietary code, the CLA does not change t…

>> If you submit code, you grant a license to Google to use it in non-proprietary [ sic , I assume] code. > it's a copyright license, not a copyright assignment >> So, at some point, once users and developers are locked in, Google can make later versions closed and proprietary enough to stop clones. > you're welcome to fork it if you wish, or distribute proprietary, non-open-source versions of the code It sounds like…

The thing is that anyone can make that fork and use the code on a proprietary system, not only google. The same that apple did with the mach kernel and any other one could have done.

Re: Fuchsia overview

#72

Post by mbrukman »

ColanR wrote: post #52
choppaface wrote: post #37

Earlier quoted context omitted.

The point is that when a non-Googler contributes code, it’s non-proprietary since the non-Googler is by definition a non-Googler. What the CLA does not prohibit is proprietary use—- your lengthy answer. The OP makes the point that Google will find a way to use public contributions for Google’s own profit. The sheer size of the response above, let alone content, is what creates the tone of “talking past the customer”…

They aren't disagreeing. Parse what they said, and notice nothing contradicts the post they're replying to. That's what I didn't want to say explicitly in my other comment: they made a long-winded comment that appeared to express a negative statement about what the poster said, while technically agreeing. To me, it's a perfect example of a lawyer's yes-that-sounds-like-no. Edit: glad I didn't say this in the other co…

I've added a response to your earlier comment to clarify: https://news.ycombinator.com/item?id=23365469

Re: Fuchsia overview

#73

Post by ColanR »

mbrukman wrote: post #70
ColanR wrote: post #33

Earlier quoted context omitted.

>> If you submit code, you grant a license to Google to use it in non-proprietary [ sic , I assume] code. > it's a copyright license, not a copyright assignment >> So, at some point, once users and developers are locked in, Google can make later versions closed and proprietary enough to stop clones. > you're welcome to fork it if you wish, or distribute proprietary, non-open-source versions of the code It sounds like…

Sorry for not making it more clear; I was responding to the statement: > Not really open. If you submit code, you grant a license to Google to use it in non-proprietary code.[1] So, at some point, once users and developers are locked in, Google can make later versions closed and proprietary enough to stop clones. The CLA does not change anything about the license, and does not prevent or make it possible (or easier)…

That's a very fair point. Thanks for clarifying.

Re: Fuchsia overview

#74

Post by [deleted] »

jccalhoun wrote: post #66

>Fuchsia's goal is to power production devices and products used for business-critical applications People have guessed that Fuchsia is some successor to Android or unification of Chrome OS and Android. However, this statement makes me wonder if it is meant to run their backend hardware and not consumer products.

[deleted]

Re: Fuchsia overview

#75

Post by mbrukman »

choppaface wrote: post #37
mbrukman wrote: post #30

Earlier quoted context omitted.

Disclosure: I work at Google (but not on Fuchsia), and I contribute quite a bit to open-source projects. Disclaimer: I'm not a lawyer, this is not legal advice, etc. I'm not sure what you mean by "you grant a license to Google to use it in non-proprietary code" — was that a typo and did you mean "proprietary"? In any case, Apache/BSD/MIT licensed code can already be used in proprietary code, the CLA does not change t…

The point is that when a non-Googler contributes code, it’s non-proprietary since the non-Googler is by definition a non-Googler. What the CLA does not prohibit is proprietary use—- your lengthy answer. The OP makes the point that Google will find a way to use public contributions for Google’s own profit. The sheer size of the response above, let alone content, is what creates the tone of “talking past the customer”…

Disclaimer: I'm not a lawyer and this is not legal advice.

I've added a clarification separately, please take a look there first: https://news.ycombinator.com/item?id=23365469

> The point is that when a non-Googler contributes code, it’s non-proprietary since the non-Googler is by definition a non-Googler.

I think we are using different definitions of "proprietary". I'm using it to mean "non-open-source" [1], and you're using it to mean "employed by a specific company" (or something else); can you please clarify what you mean or rephrase what you're trying to say?

> What the CLA does not prohibit is proprietary use—- your lengthy answer. The OP makes the point that Google will find a way to use public contributions for Google’s own profit.

That's not the purpose of a CLA; that's the purpose of a project's license. That was the point of my post. Anyone can take a project with an Apache/BSD/MIT license (whether or not the project has a CLA, it's orthogonal), make a proprietary product from it, distribute it, sell it, etc. and they would be just fine doing it, without also sharing any of the source.

To put it another way, a CLA cannot restrict proprietary or commercial use of a patch or contribution, if the underlying project license is Apache/BSD/MIT, because all those licenses already allow commercial use, incorporating software into proprietary / closed-source products, etc. Such a CLA would be incompatible with the project's license.

I've never seen an Apache/BSD/MIT project where the CLA (and only the CLA) prohibits commercial / proprietary / closed-source or any other use cases — if you have an example or two, could you please point them out? I'm very curious to see how this would work in practice, because this seems like a strong contradiction, so I would be interested to see how this plays out in practice.

[1] https://en.wikipedia.org/wiki/Proprietary_software

Re: Fuchsia overview

#76

Post by plerpin »

netdur wrote: post #57
catern wrote: post #35

>Fuchsia aims to provide drivers with a binary-stable interface. In the future, drivers compiled for one version of Fuchsia will continue to work in future versions of Fuchsia without needing to be modified or even recompiled. This approach means that Fuchsia devices will be able to update to newer versions of Fuchsia seamlessly while keeping their existing drivers. This is a massive step back for open source. The fa…

sorry but that's just naive idealism, my wife has android flagship, a Samsung s10, she will receive one more year of updates, then she will be on her own, my daughter has iPhone 6S, this old device will receive iOS 14 soon. my wife do not care about updates, she will not hesitate a second to get iPhone once she knows her social media or pictures is not safe on her android device, this is the issue Android have and Fu…

I'm pretty sure Qualcomm not giving a shit about supporting their SoC is why my Android watches were practically EOL'd within months.

Re: Fuchsia overview

#77

Post by zozbot234 »

plerpin wrote: post #76
netdur wrote: post #57

Earlier quoted context omitted.

sorry but that's just naive idealism, my wife has android flagship, a Samsung s10, she will receive one more year of updates, then she will be on her own, my daughter has iPhone 6S, this old device will receive iOS 14 soon. my wife do not care about updates, she will not hesitate a second to get iPhone once she knows her social media or pictures is not safe on her android device, this is the issue Android have and Fu…

I'm pretty sure Qualcomm not giving a shit about supporting their SoC is why my Android watches were practically EOL'd within months.

Not sure how Fuchsia is supposed to solve this. If you can port those Qualcomm SoC drivers to the fixed Fuchsia interface, you could just as easily port them to the mainline Linux kernel and submit them upstream.

Re: Fuchsia overview

#78

Post by rob74 »

clumsysmurf wrote: post #4
matchbok wrote: post #2

Another Google project that will end up being abandoned. Flutter, Dart, messaging, etc. They need to just fix Android.

Maybe they will fix Android by replacing it with Fuchsia :P I think the problems with Android run so deep, it can't just be "fixed".

No idea why you're being downvoted... I also think that would be one of the most obvious areas where Google could eventually put Fuchsia to use - it would have several advantages: a new OS with a more modern architecture (getting rid of the GPL-licensed Linux kernel, which Google probably sees as an advantage); the possibility to update the kernel independently of the drivers; getting rid of Java and its legal liabilities which Oracle could exploit in the future etc.

Re: Fuchsia overview

#79

Post by uluyol »

catern wrote: post #35

>Fuchsia aims to provide drivers with a binary-stable interface. In the future, drivers compiled for one version of Fuchsia will continue to work in future versions of Fuchsia without needing to be modified or even recompiled. This approach means that Fuchsia devices will be able to update to newer versions of Fuchsia seamlessly while keeping their existing drivers. This is a massive step back for open source. The fa…

Once upon a time, Linux had terrible support for laptop hardware. Remember ndiswrapper? That thing you used to get Windows wifi drivers working on Linux. Or how about when ATI (AMD) provided only the most buggy drivers. How about printers?

These days Linux has better hardware support (imo) than Windows. Solving it for laptops was about creating the right incentives for hardware manufacturers. It can happen for mobile too.

Re: Fuchsia overview

#80

Post by cameronbrown »

catern wrote: post #35

>Fuchsia aims to provide drivers with a binary-stable interface. In the future, drivers compiled for one version of Fuchsia will continue to work in future versions of Fuchsia without needing to be modified or even recompiled. This approach means that Fuchsia devices will be able to update to newer versions of Fuchsia seamlessly while keeping their existing drivers. This is a massive step back for open source. The fa…

I really want to agree with you, and in principle, it would be far better for hardware manufacturers to upstream their drivers. In practice this hasn't happened and will never happen, because there's no incentive to support hardware no longer making money (a chip is only sold once, after all).

I think the mounting cost of e-waste is a far bigger deal. Think of the unimaginable amount of carbon impact from the millions of trashed Android phones out there. Do we really want to continue down this path, until there's billions of obsolete machines sitting in landfills (there probably already is)? Updatability can save devices for much longer, and now people are upgrading less often, there's a huge opportunity for impact there.

Disclosure: I work for Google, but not on the Android OS or Fuchsia.

Post reply on HN