What if any requirements are there on the licensing of these reinvented wheels? Specifically would GPL or AGPL be acceptable?
Mitigating Memory Safety Issues in Open Source Software
11–20 of 244 posts
Re: Mitigating Memory Safety Issues in Open Source Software
#12and abandon it right after they become technically uninteresting. seriously aside from not supporting current GPL licence on these open source projects I dont see a reason to not support them.
Re: Mitigating Memory Safety Issues in Open Source Software
#13What is left out of the title is that they do not provide funding to the current authors/maintainers of these open source projects. Instead, they fund an organization that will rewrite these tools. Correct me if I’m wrong, but that’s my understanding of the rather terse article. I would rather have the original maintainers funded and still in control of the many pieces that form the basis of the major Linux distribut…
Yeah, it sounds a lot like Google is going to "hijack" popular open source projects for the sake of "security". It'll be interesting to watch how this plays out. But I pity the projects where Google's gaze falls upon.
Most of those project authors refuse to rewrite or adopt memory safe languages in their projects.
Re: Mitigating Memory Safety Issues in Open Source Software
#14Earlier quoted context omitted.
Yeah, it sounds a lot like Google is going to "hijack" popular open source projects for the sake of "security". It'll be interesting to watch how this plays out. But I pity the projects where Google's gaze falls upon.
I’m not sure “hijack” is the right word. They are using money to entice projects to rewrite in memory safe languages.
*to entice projects to rewrite other peoples projects
Re: Mitigating Memory Safety Issues in Open Source Software
#15Earlier quoted context omitted.
Yeah, it sounds a lot like Google is going to "hijack" popular open source projects for the sake of "security". It'll be interesting to watch how this plays out. But I pity the projects where Google's gaze falls upon.
Most of those project authors refuse to rewrite or adopt memory safe languages in their projects.
No reason no exclude them in the first place.
Re: Mitigating Memory Safety Issues in Open Source Software
#16Earlier quoted context omitted.
Yeah, it sounds a lot like Google is going to "hijack" popular open source projects for the sake of "security". It'll be interesting to watch how this plays out. But I pity the projects where Google's gaze falls upon.
Most of those project authors refuse to rewrite or adopt memory safe languages in their projects.
Any why shouldn't they?
Re: Mitigating Memory Safety Issues in Open Source Software
#17Earlier quoted context omitted.
Yeah, it sounds a lot like Google is going to "hijack" popular open source projects for the sake of "security". It'll be interesting to watch how this plays out. But I pity the projects where Google's gaze falls upon.
I’m not sure “hijack” is the right word. They are using money to entice projects to rewrite in memory safe languages.
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.
Re: Mitigating Memory Safety Issues in Open Source Software
#18Would not be cheaper to fix those unsafe languages, such as C, and offer safe mechanisms that could be used upon need? Why spend thousands, if not millions of dollars, on rewriting existing codebases when they could help fixing the existing toolset and make it safer? I don't get it.
How do you "fix" C?
Re: Mitigating Memory Safety Issues in Open Source Software
#19Would not be cheaper to fix those unsafe languages, such as C, and offer safe mechanisms that could be used upon need? Why spend thousands, if not millions of dollars, on rewriting existing codebases when they could help fixing the existing toolset and make it safer? I don't get it.
The main strength of a memory-safe language is that the safety mechanisms are opt-out, not opt-in: you can confine the unsafe behavior to a small, manageable portion of the codebase. And trying to "fix" C to become a memory-safe language would probably just result in something like a Rust dialect that merely bears more superficial resemblance to C. In any case, thorough re-writing of existing codebases would be required. You might as well re-write in a language that currently exists, rather than add creating a new language to the top of the to-do list.
Re: Mitigating Memory Safety Issues in Open Source Software
#20Do they also have a study what the cost is of reimplementing an existing project in a new project regarding feature parity existing bugs people might depend on?