[lrossi]

What 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 distributions.

[gnfargbl]

The article says that Google is committing funding to the ISRG (https://abetterinternet.org). It isn't really clear whether that is one-off funding, or the start of an ongoing relationship.

The ISRG seems to have two projects of this type mentioned on its website: an improvement to curl (https://www.abetterinternet.org/post/memory-safe-curl/), in which the ISRG funded the curl author directly; and an improvement to httpd (https://www.abetterinternet.org/post/memory-safe-tls-apache/), in which Google (via the ISRG) are funding an httpd committer.

[giantandroids]

lets encrypt are under the ISRG

[jaas]

(Executive Director of ISRG here)

> What 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.

This's not what's happening. Here's what is:

ISRG plans and coordinates investments in moving open source software to memory safe languages. We have a strong preference for working on these plans with maintainers and developers, and then funding them to execute the plan.

Once we have a plan prepared, and, ideally, maintainers/developers on board, then we pitch it for funding. Once someone (e.g. Google) funds the project, then ISRG handles contracts with the project developers/maintainers to get the work done. In some cases maintainers may be on board but want us to find a contractor to actually do the work.

In both of the first two projects, and in most future cases, the money that Google (or another company) provides will largely go to project maintainers / developers.

[lrossi]

This sounds great, thanks for clarifying!

Also, thanks for Let’s Encrypt. I didn’t make the connection between the two names. This initiative looks much better to me now.

Is rust the only language that you are considering? Would go make sense as well?

[Cullinet]

so potentially the result is a complete rewrite not involving the original authors in a language the original authors may not be current with, by a contractor code publisher / producer.

given the potential for security theater and general fud and the potency that appeals to authorities such as sponsors like Google can create in the minds of the public, how has this been evaluated in terms of the possibility for widespread disintermediation of the open source software community at large?

[folex]

> 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.

Incrementally – that means in-place. You can't fork and rewrite incrementally since there will be no adoption/users of the fork.

Also they talk about maintainers of the projects. I think that largely means original authors and maintainers, not forks.

I don't see how you come to that conclusion. Could you clarify? Thanks :)

[the_duke]

At least for curl the project leadership is closely involved, as evidenced by a related article on Stenbergs blog [1] and the ISRG annoucement [2], which mentions funding Stenberg directly and is actually linked from this anouncement...

Please don't make statements like that without doing a minimal amount of effort to verify.

[1] https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyp...

[2] https://www.abetterinternet.org/post/memory-safe-curl/

[lrossi]

Maybe I got it backwards, but it’s a PR post, and the burden is on the author to make the point clear. I’ve read it 3 times and still can’t find any sentence where they state clearly what the development strategy is.

And from link #2 that you posted, I see they talk about the curl stuff, but also show a bunch of repos with tools rewritten from scratch, e.g. https://github.com/ctz/rustls

So I really cannot draw a conclusion one way or the other.

Normally I’m an optimist, but after the recent chromium misunderstandings, I am going to err on the cynical side.

[klelatti]

The example from the ISRG blog [1] directly contradicts the assumption you're making:

> Memory safety vulnerabilities represent one of the biggest threats to Internet security. As such, we at ISRG are interested in finding ways to make the most heavily relied-upon software on the Internet memory safe. Today we’re excited to announce that we’re working with Daniel Stenberg, author of ubiquitous curl software, and WolfSSL, to make critical parts of the curl codebase memory safe.

> ISRG is funding Daniel to work on adding support for Hyper as an HTTP back-end for curl. Hyper is a fast and safe HTTP implementation written in Rust.

I too found the post terse and the lack of quantification of the financial commitment makes me suspicious but I think they deserve the benefit of the doubt for now.

[1] https://www.abetterinternet.org/post/memory-safe-curl/

[flohofwoe]

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.

[mfer]

I’m not sure “hijack” is the right word. They are using money to entice projects to rewrite in memory safe languages.

[Miner49er]

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.

[tptacek]

You're scare-quoting "an organization", which suggests you don't know what the ISRG is. You might look them up. They're pretty well-liked.

[Miner49er]

I was quoting OP.

[chii]

> 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.

[cnfhsg]

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.

[aaomidi]

> 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.

[adrianN]

Now you only need a lawyer army bigger than Google's to win your case.

[TheReverend403]

> 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.

[ardy42]

>> 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.

[emteycz]

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?

[lullibrulli3]

*to entice projects to rewrite other peoples projects

[coldtea]

If they pay for the rewrite, they have control over it.

[pyb]

-

[sgift]

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.

And a link to: https://www.abetterinternet.org/post/memory-safe-curl/

[chii]

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.

[machello13]

Wouldn't feel great, but what in the article gave you the idea they're doing that?

[flohofwoe]

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.

[piokoch]

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.

[nojito]

Most of those project authors refuse to rewrite or adopt memory safe languages in their projects.

[lullibrulli3]

No reason no exclude them in the first place.

[nojito]

Sure, but the internet shouldn't be too upset when a fork happens with a version that has feature parity and is memory safe.

[mempko]

Any why shouldn't they?

[encom]

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!

[jk563]

They specifically mention rust based backends for curl where the author of curl was funded to integrate as a starting point. I don't see any mention of funding being exclusively for organisations other than the author(s)?

[turminal]

Agreed 100%.

Sadly everyone expressing concerns like this will be dismissed and everyone is going to once again hail google for being community friendly and supportive of FOSS.

[lrossi]

Replying to myself as I cannot edit anymore.

As others pointed out, it’s not clear who will do the rewrites. Based on the curl example, it might be the maintainers. It would have been great if they could state that concretely.

I’m also wondering why there’s a middle man instead of funding the projects directly, but that’s another story.

[jaas]

I'm the head of ISRG, the "middle man" entity you're referring to.

We have a memory safety initiative in which we plan and fund projects to move popular open source software to memory safe languages. For each plan we make we seek a funder - in a couple of cases now that has been Google, but it may be others in the future.

We are in the "middle" of the financing in the sense that funding passes through us, but the memory safety initiative is coordinated primarily by us. We select projects and work with maintainers to make plans. Part of that coordination we perform is matching up projects with funders like Google, and then managing the contracts and overseeing the work to completion.

[lrossi]

Thank you for your reply.

If I understand correctly, this is an initiative that might have multiple sponsors, so it makes sense to have a central entity organizing it, and following up with all the projects involved. This makes perfect sense to me now.

Also, I was not aware that your org is behind Let’s Encrypt. This puts things into a very positive light.

It might make sense to post a sibling blog post/announcement to explain what this project is about and how it would work. I feel that Google’s post left a lot of questions to be answered.

If you don’t mind me asking, is rust the only language that you have in mind? Would go work as well?