Your missing what the two parent comments are driving at. Google says that's what it is doing, but this money is going to "an organization" that will seemingly get it's money from Google, giving Google control over whatever open source projects they target.
> control over whatever open source projects they target.
but if they rewrite the project in rust, why _shouldn't_ they control that project? If other people choose to switch, then it's not wrong for them to move, and not wrong for to google gain control of those users.
The original project maintainers is a third party to this whole process, and i would argue, is uninvolved tbh. It is up to the users of the project to decide to trust google's rewrite (and their tendencies to abandon projects...), vs the original maintainer's version, balanced against the security aspect.
If you translate an existing project into Rust, it is a derivative work and should retain the original license.
If the rewritten project gets more successful than the original (perhaps due to corporate promotion), you have morally stolen the work of the original authors.
If you write a project from scratch without looking, this of course does not apply. But I doubt that is how Rust rewrites actually happen, the temptation is too great.
> If the rewritten project gets more successful than the original (perhaps due to corporate promotion), you have morally stolen the work of the original authors.
Ownership is by "moral" definition something completely arbitrary and made up.
If you work in open-source you most likely have different views on ownership than others.
WINE goes to some length to avoid any reverse engineering of windows components and certainly any glimpse of the source code (such as the leaks which have happened over the years: if you have seen any of them then WINE does not want your code). They do this to avoid any accusations of their code being a derivative work. If you re-implement an open-source project on the same terms then it does not qualify as a derivative work. However if you look at the source code and use that to develop your new implementation, then that qualifies.
>> control over whatever open source projects they target.
> but if they rewrite the project in rust, why _shouldn't_ they control that project? If other people choose to switch, then it's not wrong for them to move, and not wrong for to google gain control of those users.
I think the issue is the more critical projects Google controls, the more they can make decisions by fiat. Those decisions will favor Google's interests, and could sacrifice everyone else's interests in some way.
It's sort of like web browsers. My understanding is that Chrome is so dominant that Google can basically dictate HTML standards at this point, or at least effectively push them in directions that are favorable to its ad-based business.
And? Google can't decide to fund organization that rewrites open source projects, or what? How is that different from forking the projects - apart from Google not taking anything at all?
This is like the archetypical lowbrow dismissal, since the ED of ISRG is literally on this thread saying that their M.O. is to fund project maintainers directly to get this work done. These workers control the means of production.
A rewrite is not taking it "to the next level". It provides a new version in a new language that does the same things, and if things go according to plan, will have fewer safety issues. There's nothing that binds them to maintain any of these projects. Given Google's history, it's irresponsible to not consider long-term maintenance and other issues.
No, C and Rust definitely don't do the same things. If the project is open source, I don't see how any maintenance concerns are relevant - everybody can judge for themselves.
It's not that smart to mistake the purpose or specification of a program, with its implementation.
Anyway, if everybody can judge for themselves, then I guess it's cool to judge that giving Google an inch over many critical open source projects is a horrible idea.
Since they don't do that (it's right there in the announcement, which no one in this thread seems to have bothered to read) that whole point is moot:
> The ISRG's approach of working directly with maintainers to support rewriting tools and libraries incrementally falls directly in line with our perspective here at Google.
Then be satisfied that your project is a good enough idea that someone else is willing to put up money to rewrite it using a safe language.
But if you're not the one doing the rewrite, why would google pay you? And if you would be capable of such a rewrite, may be they would pay you to do so.
If such changes had been planned in the project all along and the money injection can help speeding this process up that's fine. But I can't see Google security people getting involved being a good thing otherwise. They come across as prioritising security problems over anything else (e.g. "if all you have is a hammer...") and I'd be surprised if this sort of extremism will be healthy for a project in the long run. Memory safety is just one of many aspects to juggle in a software project.
Could be something great, but could end up with some "entity" will rewrite, say, ls or cp and suddenly it will turn out, that ls is still free and open source, but sends all user listed files to that entity (obviously for the sake of the noble purpose of making ls even better and all those stats are anonymous).
And there will be some pro version that does not grab that stats, but you need to purchase subscription.
I don't know, reinventing the wheel with the latest buzzword compliant language sounds like a fun time. Think of all the exciting new bugs you get to fix!
It'll be interesting to watch how this plays out. But I pity the projects where Google's gaze falls upon.