291–300 of 334 posts
Earlier quoted context omitted.
Can you elaborate on what you mean by "doesn't count"?
It's not an official package. The Arch Linux project cannot be held responsible for what non-official packages do.
But, I also don't see anyone ever talk about this, and I think it's worth people being aware.
Earlier quoted context omitted.
They aren’t really. Safari is based on WebKit, which is very much open. Chromium is based on blink which is a fork of WebKit.
WebKit is open source but Safari isn't meanwhile Chromium is. WebKit is sometimes a bit closed until it reaches embargo that Apple sets. But anyway Safari is good to web diversity.
What I did say is that Chromium was based on WebKit and then a fork of WebKit, blink.
Let’s not credit Google for Chromium without recognizing that it was Apple’s open source work that made it possible.
To suggest that WebKit isn’t open makes no sense at all. It may not have a governance model or development processes people like, but the fact that the source is open and has been used to build competitor products and has been forked means that it is unquestionably open source.
Earlier quoted context omitted.
Since Fuschia seems to be a replacement for Android, why would you think it isn’t a way for Google to exert control over the market? As for forking, that option only becomes practical if the community version can muster adequate resources versus the Google controlled version.
As of today, there are no phones running Fuchsia, so it's hard to evaluate if it's going to be useful for any kind of control. Does it have feature parity with Linux? Forking can be practical without competing for the same use case.
However that seek unlikely given that there are many actors who would like to exclude Google services from their devices and Google is at the same existential risk if that happens as they were when they introduced Android.
And yes forking can be practical, but it very often isn’t, partially in the case of a very large corporately sponsored codebase. So ‘we can just fork it’ doesn’t mitigate the concerns.
Earlier quoted context omitted.
I'm playing Devil's Advocate here because I sympathize with your point, but isn't there a way you can squint and look at this weird that it's true of pretty much everything else? IBM makes tons of money off of Linux, for example. iXsystems profits off of FreeBSD. Facebook profits off of their wildly popular C++ libraries. I think we really need to divorce "profit" from "open source". OSS is great because we can contr…
> IBM makes tons of money off of Linux, for example. Personally I would rather contribute to a GPL licensed project, because if big companies try to profit of it, they will also have to release their changes. Those could improve the project, and now the community does no longer have to do themselves -> Community devs get payed back in development time that they would have to spend themselves. With permissively licens…
Strictly speaking, they only have to release their changes to people they distribute their product to. It's convenient to keep it entirely open, but not a requirement.
I agree that folks should contribute code to places they feel comfortable in any case. As I mentioned in GP, if you separate out pay, there are other reasons to work on OSS, and these motivations can coexist.
Earlier quoted context omitted.
It's kind of unfortunate because existing developers have the privilege of experience with the systems and where they're going that external contributors simply don't have, and it will take a non-trivial amount time for interested parties to develop that knowledge. At the same time, it is an active project with active development that are informed by goals and processes not all of which are open. And really, while th…
> However, the "bazaar" is also a bit of a myth in this regard. I'm not really aware of any open source projects where I can go submit a PR without talking to anybody and have the expectation that it'll be merged without discussion. Bazaar is not a myth at all. The distinction was never 'are patches always merged' but is the development done in public. The issue with Google projects is more about in-group and out-gro…
Earlier quoted context omitted.
> The difference isn't relevant 99% of the time, but it comes up if the maintainership of a work tries to re-license the work. Works without assigned ownership cannot practically be re-licensed, as you'd have to get individual consent from all owning parties. Yeah I understand this. Hence there _is_ a difference and maybe one I don't prefer. I understand why Google would want this, but maybe I view Google's inability…
IIRC in most cases it wasn’t so much that anyone actively disagreed with the licensing change, as that it was infeasible to even get in contact with the literally thousands of contributors — especially since many of them have left no contact details that could be used for legal correspondence. Imagine a country with direct democracy, where a 100% consensus of all citizens is required for any law to be passed. Now ima…
Maybe yes and maybe no.
> ...The legislative process grinds to a halt!
You're being a bit overly dramatic. The software development process can continue just as it did before, they just can't retroactively change the license on code they do not own. It is true that maybe the project might die partially due to a lack of adoption due to people not liking the license, but he project may die for many other reasons as well. Also the project isn't gone anyway. It continues just as before.
> This is, of course, why no government is run that way. And it's equally silly to run a FOSS project that way. Even if literally everybody likes some change, just one contributor failing to get in contact means you're stuck without the ability to make the change.
There is one government, but there are many competing software projects. If one goes into decline it's not the end of the world. Besides the software project is not gone, it's still there. The fact that there are so many popular projects without the ability to change their licenses shows that the model can work just fine.
Look if you want to start a project and require a CLA be my guest. If you want to join a project with a CLA, go ahead. Just be aware that CLA's will deter some contributors. Weigh these trade-offs however you wish.
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…
> If I want to distribute derivative works of the Linux kernel, I need to release those works to all. This is false. The GPL does not require you to make source code available to anybody who asks, only those you distribute the software too (in source or binary form). If you modify a GPL'ed application and then distribute that to 3 friends, those friends have the right to ask for the (modified) source code. Nobody els…
However, Google need not provide the source to people that they do not distribute the code to (well obviously there are differences between e.g. GPLv2 and GPLv3, but whatever this isn't a legal analysis). For example, if Google uses it internally they may not need to release the source to anyone at all. They're all important points that more people need to understand, but they aren't really the ones that I was making in this thread and none of them are really specific to Google vs. other companies.
Earlier quoted context omitted.
An open platform would have a framework that supports multiple back ends.
It already does. https://bubu1.eu/openpush/ The fact that this is possible is something I have commented about on this very forum for years. It is trivial for the Amazons and Huaweis of the world to build an API like this that supports Google's FCM, Amazon's ADM, etc. and provide a library for developers to use that will let them easily deploy push-enabled apps on devices across all ecosystems.
“The OpenPush project aims to create ... Development is still ongoing.”
Doesn’t sound like it from the website.
Earlier quoted context omitted.
I understand the concern. I spent the vast majority of my career not at Google while also involved in open source communities, and I can empathize with this. I think one place we have a leg up here is that we do have documented processes for performing this type of work. It's certainly possible that the outcome of a proposal is rejection, but the hope would be the process does that quickly. We're all human and we don…
I think the important part will not be what gets rejected, but what gets accepted. Nobody will ever remember the rejected error handling or genetics proposals; but people will definitely take notice if the eventually accepted one come attached with Google names. It's hard for an open source project started (or dominated) by a single company to shake the appearance of being insular. At this point I believe Kubernetes…
I guess, but my point is that many of the rejected ones are attached with Google names. Also it's unclear to me that the reason for not remembering is due to who proposes and implements the things -- it seems more likely that this is due to a huge volume of proposals over a long span of time. WRT generics, it's also very clear that community feedback is being incorporated.
So this is why I think the issue is really rejection. Nobody's really upset about how error reporting or generics are being handled because it's clear that community feedback is being honored, and it's clear that the core team is holding themselves to the same standard the community is being held to. Those two properties aren't as clear in the packaging situation.
That's why I think Fuchsia having a documented community process and also having been working within that process for some time is important. We're already holding ourselves to the standard we're asking of the community.
> I believe it takes extra concerted effort.
This is absolutely true, and it's why I'm here trying to make sure that folks know there are people involved in the project who care greatly about its open nature.
Many people have pointed out that the existence of open source doesn't necessarily make the project accessible for contribution, and that's I think the more difficult problem to solve in the short-to-medium-term.
Earlier quoted context omitted.
It already does. https://bubu1.eu/openpush/ The fact that this is possible is something I have commented about on this very forum for years. It is trivial for the Amazons and Huaweis of the world to build an API like this that supports Google's FCM, Amazon's ADM, etc. and provide a library for developers to use that will let them easily deploy push-enabled apps on devices across all ecosystems.
Already does? “The OpenPush project aims to create ... Development is still ongoing.” Doesn’t sound like it from the website.