111–120 of 172 posts
Earlier quoted context omitted.
Which means they can fork it anytime into a proprietary one.
They can do that regardless of the license since they own the copyright. As long as they do not accept external contributions or require a CLA it does not matter what license they offer, they can still make future versions proprietary.
They do tho.
Earlier quoted context omitted.
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 so…
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 ker…
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.
Earlier quoted context omitted.
"- 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 co…
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 i…
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?
"dev, gn, /svc, /pkg, PA_VMAR_ROOT" Hate this old unix approach for name shortening, what makes them unreadable and non intuitive. If they break compatibility anyway, they could name things in a way, that people can read like a book.
"dev, gn, /svc, /pkg, PA_VMAR_ROOT" Hate this old unix approach for name shortening, what makes them unreadable and non intuitive. If they break compatibility anyway, they could name things in a way, that people can read like a book.
svc is especially cringy.
Android for all practical purposes is as good as a closed ecosystem with apps tied to closed source Google services and the inability to run Linux on your Android phones. This kind of lip service and self serving tip toeing around the spirit of open source in many ways does more harm to open source than closed source. How is it that devices drivers that work on Android perfectly are not available for use on Linux? Wh…
This is definitely true, and I have a lot of issues with Google and their lip service to open source. (People reading my history will attest, I'm sure.) But at the very least, Fuchsia will be a lot more secure by design than Android, and Android is the dominant OS platform on earth. The state we are right now, where 85% of mobile devices run Android, and 0.7% of them are actually up to date, is a terrifying place to…
"dev, gn, /svc, /pkg, PA_VMAR_ROOT" Hate this old unix approach for name shortening, what makes them unreadable and non intuitive. If they break compatibility anyway, they could name things in a way, that people can read like a book.
Fully agree. No need for the shitty parts of UNIX to be in a new OS. Use full names. I've never used OSX/macOS but I do admire how they've gone about doing the whole UNIX thing, there seems to actually be some standard to it unlike the LSB and from what I gather to uninstall a program you just delete it's directory. Try doing that on literally any other mainstream OS!
"dev, gn, /svc, /pkg, PA_VMAR_ROOT" Hate this old unix approach for name shortening, what makes them unreadable and non intuitive. If they break compatibility anyway, they could name things in a way, that people can read like a book.
Fully agree. No need for the shitty parts of UNIX to be in a new OS. Use full names. I've never used OSX/macOS but I do admire how they've gone about doing the whole UNIX thing, there seems to actually be some standard to it unlike the LSB and from what I gather to uninstall a program you just delete it's directory. Try doing that on literally any other mainstream OS!
My take is that Fuchsia is Google's attempt to unify their mobile ecosystem under one proprietary OS like Apple does with iOS (yes, yes I hear you, "But Darwin is OSS..." try making that into iOS though...): which is a good move for Google.
> under one proprietary OS fuchsia and all it's components are licensed under BSD 3 clause, MIT, Apache 2.0