News for hackers. Stuff that matters.
Re:Mitigating Memory Safety Issues in Open Source Software by chii on Thursday February 18, 2021 @08:20AM (#26179478)
> 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.

Re:Mitigating Memory Safety Issues in Open Source Software by cnfhsg on Thursday February 18, 2021 @12:13PM (#26182531)
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.

Re:Mitigating Memory Safety Issues in Open Source Software by aaomidi on Thursday February 18, 2021 @12:44PM (#26182991)
> 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.

Re:Mitigating Memory Safety Issues in Open Source Software by adrianN on Thursday February 18, 2021 @12:55PM (#26183131)
Now you only need a lawyer army bigger than Google's to win your case.
Re:Mitigating Memory Safety Issues in Open Source Software by TheReverend403 on Thursday February 18, 2021 @12:42PM (#26182942)
> If you translate an existing project into Rust, it is a derivative work and should retain the original license.

By this logic, WINE is a derivative of Windows and should retain their license.

Re:Mitigating Memory Safety Issues in Open Source Software by rcxdude on Thursday February 18, 2021 @01:17PM (#26183416)
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.
Re:Mitigating Memory Safety Issues in Open Source Software by ardy42 on Thursday February 18, 2021 @11:46AM (#26182105)
>> 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.