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

Expanding Fuchsia's open source model

opensource.googleblog.com

Post reply on HN
Print view View original

31–40 of 334 posts

Re: Expanding Fuchsia's open source model

#31

Post by trasz »

brandmeyer wrote: post #10

Looks like you still cannot contribute without granting copyright ownership to Google. In turn, GOOG licenses it out under a BSD (or BSD-like) license. This is a big difference relative to Linux, and its part of why Linux works so well as a collaboration between competitors. The GPL's copyleft acts as a joint development agreement between equals. IMO, Fuchsia's model only works well for integration partners that are…

With BSD-style licenses there's still a strong incentive to share code. That's why permissively-licensed projects, from Node, to PostgreSQL, to FreeBSD, work.

With GPL-style licenses, there's an incentive to avoid putting effort into development, and instead undercut other parties who did invest, and then had to share their code.

Re: Expanding Fuchsia's open source model

#32

Post by hollerith »

brandmeyer wrote: post #24
hollerith wrote: post #19

Earlier quoted context omitted.

Are you saying that collaboration on Gnu Compiler Collection, binutils, bash, bison, CLISP, coreutils, etc, has been inhibited by the requirement for copyright assignment to the FSF?

There's a big difference between GNU and Linux in terms of their collaboration. With the exception of GCC, most of the utilities you named have been maintained by a very small group of people. GCC itself has definitely been inhibited by the copyright assignment. There have been a few different ports that were not upstreamed specifically because of the CLA. AVR32 and C6000 come to mind off the top of my head.

As far as I am aware, the only times contributions were not incorporated were because the work was done by under the terms of an employment contract with the result that the employer ended up owning the copyright, then the employer decided not to sign the CLA.

Can you think of a single instance in which code written by an individual contributor not bound by an employment contract was prevented from being incorporated into a project that required copyright be assigned to a central entity?

I have read multiple accounts of open-source contributors who have successfully negotiated when being hired that copyright to any code written on their own time on the own hardware will remain with them (so as not to complicate their contributions to open-source projects).

Re: Expanding Fuchsia's open source model

#33

Post by kerneis »

outside1234 wrote: post #11

That is the most hideous source control system ever. Do they really need to be developer hostile just because Github is owned by Microsoft? I mean seriously, who has time to commit to a project with a random set of tooling.

You may want to browse it using https://cs.opensource.google/fuchsia. Much nicer interface.

(disclosure: I work on Fuchsia at Google)

Re: Expanding Fuchsia's open source model

#34

Post by jmgao »

moron4hire wrote: post #25
mmastrac wrote: post #16

Earlier quoted context omitted.

Welcome to the world of Building Large Google Projects. This is somewhat painful in the Android and Dart/Flutter world. I haven't tried building Chromium yet but I'm sure it's just as complex.

Yeah, I've tried building Chromium on my own before. Chromium's build process is so inscrutable and changes so often that several Googlers I've talked to have said you can't really do it without handholding from another Googler in-the-know.

Well, it could be worse: you could be building Chrome OS, which builds both Chrome and Android as part of its build.

Re: Expanding Fuchsia's open source model

#35

Post by jononor »

hollerith wrote: post #32
brandmeyer wrote: post #24

Earlier quoted context omitted.

There's a big difference between GNU and Linux in terms of their collaboration. With the exception of GCC, most of the utilities you named have been maintained by a very small group of people. GCC itself has definitely been inhibited by the copyright assignment. There have been a few different ports that were not upstreamed specifically because of the CLA. AVR32 and C6000 come to mind off the top of my head.

As far as I am aware, the only times contributions were not incorporated were because the work was done by under the terms of an employment contract with the result that the employer ended up owning the copyright, then the employer decided not to sign the CLA. Can you think of a single instance in which code written by an individual contributor not bound by an employment contract was prevented from being incorporated…

That is a significant limitation. A considerable amount of open source software is written while people are employed, as part of their work.

Re: Expanding Fuchsia's open source model

#36

Post by CogitoCogito »

hollerith wrote: post #26
CogitoCogito wrote: post #22

Earlier quoted context omitted.

If I want to distribute derivative works of the Linux kernel, I need to release those works to all. My competitors can take advantage of this, but in the end they are bound by similar rules. This produces a feedback loop in which contributions back may be used by everyone under pretty much equal terms. If you assign your copyright to Google, they may make use of those changes and integrate them into further developme…

You are describing the difference between the GPL and BSD-like licenses. You have not said anything about the difference between a BSD-like license with copyright remaining with the contributors versus BSD-like license with copyright assigned to Google.

Well if I have the copyright I can straight up sell software based upon it without telling people you made it. Or I can release your code or derivatives of it under a different license while privately selling it under other licenses for profit. If these things don't bother you, then feel free to contribute.

In fact, what I'm trying to understand exactly is if I assume that you are correct that there is no difference, then why would Google require the contribution in the first place?

edit: If this ( https://cla.developers.google.com/about/google-individual ) is the CLA in question, then you additionally agree on a patent grant to Google and those those Google distributes it to. So if Samsung takes the code and distributes it to other customers those customers and Samsung are not covered by the same grant? Why is this all centered on Google? Why is not simply a general patent grant as part of the submission to anyone receiving the code?

Re: Expanding Fuchsia's open source model

#38

Post by jtsiskin »

torben-friis wrote: post #3

I'm still not clear on what fuchsia is trying to be - or more specifically, why is Google developing it. What is the end goal here, from a business perspective?

It’s already running on some of their embedded devices, such as google home. A capability based OS with a micro kernel sounds great to me.

Things like the networking stack can run in user space, and be written in memory safe languages like Rust.

An OS that “can’t” get viruses or be hacked sounds pretty desirable. Cynically it makes things like “jail breaking” a google home much more difficult.

Re: Expanding Fuchsia's open source model

#39

Post by brandmeyer »

hollerith wrote: post #32
brandmeyer wrote: post #24

Earlier quoted context omitted.

There's a big difference between GNU and Linux in terms of their collaboration. With the exception of GCC, most of the utilities you named have been maintained by a very small group of people. GCC itself has definitely been inhibited by the copyright assignment. There have been a few different ports that were not upstreamed specifically because of the CLA. AVR32 and C6000 come to mind off the top of my head.

As far as I am aware, the only times contributions were not incorporated were because the work was done by under the terms of an employment contract with the result that the employer ended up owning the copyright, then the employer decided not to sign the CLA. Can you think of a single instance in which code written by an individual contributor not bound by an employment contract was prevented from being incorporated…

I'm not sure what your point is. The exceeding majority of the work done on these foundational projects has been done as works for hire. The issue isn't the relationship between Google and Coder Jane. Its between Google and Red Hat. Its between Google and Samsung.

Intel and ARM both collaborate on GCC and Linux all the time while being fierce competitors. Google, Canonical, Red Hat, etc all contribute to Linux while being fierce competitors.

But the only companies that contribute to Android and ChromeOS are device partners, and the partner contributions are far more limited in scope.

Re: Expanding Fuchsia's open source model

#40

Post by bestorworse »

jsnell wrote: post #5

I find it kind of hilarious how large a proportion of the roadmap is just migrations of various kinds. If the goal here was to encourage external contributions, I can't imagine a much worse sales pitch.

I see it as better way of developing a product. Or actually, a foundational system, if Fuchsia really ends up becoming something like that. You see, lots of things that today are fundamental were just "developed organically", and that is OK because people never tought that it would end up being what it is.

Besides, a greater part of the cruft we have today is rooted in the development model companies adopt that is "develop it, make it work, and ship so not to delay the schedule/budget so much". And that is OK too given that companies just want to develop a product and don't have lots of time, budget and resources... But, as things are in software engineering, that model doesn't produce as good a piece of software as it would with more iterations and refactoring seeking the best software model and implementation. In the end, that results in greater issues issues than what was really needed and the backward compatibility hinders an actual solution. But Fuchsia being meant as a foundation, cannot be developed like that. Like a product that "just works". It would end up being just another bad designed (and chances are, bad implemented too) system based on concepts of the beginnings of computer industry that doesn't necessarily apply for today's systems.

As I've loosely accompanied Fuchsia's development, they've done a lot of early bring up work just so that other parts of the system could be developed. And that is expected because they developed arguably almost everything from scratch. You cant expect ending up with really great system design and implementation just from these first iterations. Then, with the experiences from that, they've done lots of refactorings that refined system's abstractions, APIs and implementation. And, if they are serious about Fuchsia being a good foundational system, they have to solve these left over from the early development.

Post reply on HN