AI policy?

Speaking to the specific question posed:

"How can I trust OpenSSL when you use AI-generated imagery? How far and pervasive is your use of AI in your business and by OpenSSL?"

I don't really follow the logic of the premise. That is to say, I don't see a connection between the use of AI to generate imagery, and the relative trust one places in the software that organization produces. The latter should be derived from testing/validation on the part of the consumer, and the cumulative success/failures that the consumer has observed.

That said, It probably wouldn't hurt to have a policy regarding AI. Though I don't know that any policy that makes a statement regarding the use of AI in the generation of code that goes into openssl is going to be either pragmatic or enforceable. Much like the person above, they correctly identified the image provided as being AI generated, but they did so based, effectively on, for lack of a better term, a feeling. AI generated images look a certain way that tips a human off, and I'm not sure thats really applicable to code, at least not in a consistent fashion. While we might get the feeling that code was generated by AI, theres no definitive way to tell, and something like a trivial patch that corrects typos in a function may likely slip through without any notice, nor should it if its such a trivial patch. Any policy that restricts AI usage is likely to quickly fall into a grey area that we will have a hard time discerning.

Instead, it might be better to follow the KISS policy here to ensure that, regardless of the source of some bit of code, we ensure that we as humans have a point in the process in which we are guaranteed that acceptance into our code base is predicated on human review.

Something as simple as an adjustment to to our committer policy, indicating that all comitters must not be attached to a generative AI model, and that reviews must be done manually might be enough to ensure that code that may or may not come from an AI source has been looked at by human eyes and deemed to be acceptable.

Instead, it might be better to follow the KISS policy here to ensure that, regardless of the source of some bit of code, we ensure that we as humans have a point in the process in which we are guaranteed that acceptance into our code base is predicated on human review.

A problem here is code ownership and CLAs. Currently all non-trivial code contributions must have a CLA in place for all authors. Where the author is fully or in part an AI tool, how can we achieve this? The AI is pulling on source material from other authors who we do not know and likely to not have a CLA in place, and cannot consent for their contribution to be included. We could amend the CLA policy to allow AI contributions - but this seems to just open ourselves up to problems.

One possibility is to allow AI assistance for trivial commits but not for non-trivial commits.

We can't distinguish code written with and without AI

A problem here is code ownership and CLAs. Currently all non-trivial code contributions must have a CLA in place for all authors. Where the author is fully or in part an AI tool, how can we achieve this?

Thats a fair question, but (in my opinion, of course keeping in mind I am not a lawyer), is that the CLA requirements cover us here already. Specifically section 4 of the CLA:

You represent that you are legally entitled to grant the above license. If your employer(s) has rights to intellectual property that you create that includes your Contributions, you represent that you have received permission to make Contributions on behalf of that employer, that your employer has waived such rights for your Contributions to the Foundation, or that your employer has executed a separate Corporate CLA with the Foundation.

That to me says that the contributor, when code is submitted, attests to the fact that they are legally granted permission to assign copyright to us. If an AI writes and submits code, either it (the AI) will also (somehow) be smart enough to sign and submit a cla against an email that it (the AI) uses, or a human driving the AI will do so, or there will be no CLA for the submitting email.

In the last case, thats trivial, the code doesn't get accepted, because there is no CLA. In the first two cases, that seems equivalent to a situation in which human A writes some code, but human B takes credit for it and submits its with their CLA. In either scenario (AI submits to openssl, Human uses AI and submits to openssl, or human steals code and submits to openssl), we are euqally unable to determine the true provenance of the submitted code, but for the purposes of the CLA (which I assume is to legally indemnify us from copyright violation), we seem equally covered.

In any of the above scenarios, I imagine we may be required to remove code that was submitted in bad faith, but the use of AI vs god old plain plagiarism, I don't think affects that outcome.

@Neil Horman 

attests to the fact that they are legally granted permission to assign copyright to us

Uhm, no, the CLA is not the copyright assignment variant, please do not mischaracterise it that way

Of course, it may be worthwhile to add a clause to the CLA that indicates if AI was used to create a submission in any way, that the contributor further attests to the fact that they assume the same responsibilities for copyright infringement that the use of AI may have caused. Thats definately something for a lawyer to comment on though.

I am not a lawyer. I am not a lawyer. I am not a lawyer. :)

IMO, we absolutely want to avoid code going into the codebase that we do not have rights for. I suspect many people that use AI assistance will not have given any consideration to the copyright issues involved, even if they have signed a CLA. It's not enough for us to say "well, even if code we don't own goes into the codebase at least we can sue the person that submitted it for breaching their CLA". By having an explicit policy (including an explicit clause in the CLA) saying "you must not use AI assistance for non-trivial commits" then we can at least go someway to avoiding this situation.

Matt, I'm not sure it's realistic. If a contributor looked at some stackoverflow example and is inspired by it - is it an issue to consider?

This is a good point. To some level we are all products of our previous experience. We have all seen what other developers produce and learn techniques and approaches from them. If you see someone use a particular novel design pattern you might store that idea away, and apply it in some code of your own later. I think (probably) these high level ideas and concepts aren't really copyrightable (otherwise we're all sunk). The problem comes in the cross over between high level ideas and concepts and actual code that you copied from somewhere else. The problem with AI is that (most of the time) you really don't know what the true source of the code it is producing is (is it actually an amalgamation of many different people's ideas thus producing something really new, or is it based on a much more restricted set of input - essentially copying what someone else did before).

There is also different level of AI assistance - for example Github Copilot, that's AI, but do we really want to ban its use for non-trivial contributions?

I look at what others have already done in this department... curl went through exactly this sort of question, albeit their angle was different (they did it as a reaction to lots of AI slop in bug bounty program), and made a policy that isn't overly draconian: https://github.com/curl/curl/blob/master/docs/CONTRIBUTE.md#on-ai-use-in-curl

It seems like other projects I've my eyes on haven't really had a reason to deal with AI enough to worry yet...

@Richard Levitte this was on my feed today: https://blog.stuartspence.ca/2025-08-declining-ai-slop-mr.html

one thing I mentioned yesterday at the Foundation BAC meeting is the duality of the problem: we want to guide our (contributing) users into an acceptable use of AI tools when engaging with the project. On the other hand our users might desire to read about how the project consider acceptable using generative AI for its tasks, to determine if they find it acceptable and in line with their values when deciding to adopt OpenSSL for their needs, investing time and resources on the project, or endorsing the project or the mission in any public forum.

Here’s a provoking point to make an example.

Authors should be explicitly aware that the burden is on them to ensure no unlicensed code is submitted to the project.

This is independent if AI is used or not.

The above excerpt from the curl policy seems to me more or less in line with my interpretation of the current OpenSSL CLA.

Would it be acceptable for OpenSSL to have language like the above in our policy, but then carelessly use generative AI for creating engaging images in their communication material? Would it be correct to ask our users about the authorship implications of generative AI when submitting code to the project and disregard them when the same authorship issues apply to “non-technical” material?

We had a discussion on this yesterday, and one argument was the technical cost for the project of having to remove code from released sources in case of contention as being something quite dear to us as engineers. But I am pretty confident that if we had affected artists in the discussion they would advocate as much about the costs in terms of reputation and trust in disregarding human authorship, as well as the indirect damages OpenSSL would be contributing to for the disregarded exploited artists.

@Nicola Tuveri 

In the arts, there's this fuzzy line between outright plagiarism and "being inspired by" (which can be methods, which may be color choices, which may be overall style).
Younger artists start with mimicking older artists, or are just drawn to the same genre and end up doing similar things, but that may develop into something unique but still inspired later.
Musicians make covers for other musicians' work, and start composing their own stuff later on.
What of all that is "being inspired by" and what is straight plagiarism? Sometimes, it's quite hard to tell, and sometimes, it's more about intent.
Quoting from a book is considered "fair use", as long as it's within reason.

(oh boy, have I discussed these things with my mom, who was a sculptress, and oh boy, have I discussed these things with fellow photographers)

From a photographer standpoint, I do have pictures out there, some being crap, others I'm really proud of. I would find it quite disturbing if I saw one of them whole with just small edits, but I wouldn't find it overly disturbing if I found my eyes being used as a detail in a grander image.

Going back to code, I view it the same way. The way I understand AI, it's still a piecemeal generator of tokens, based on very complicated statistical models, more or less (yeah, there's more to it, but...). Is it very likely to reproduce big pieces of code verbatim, or does it recombine pieces that are likely to be seen together? On which side of the line between outright plagiarism and "being inspired by" does that fall? That's an open question I have that's still looking for an answer.

Also, another question is what we actually view as the thing covered by IP rights. Is the whole, or is it every detail? After all, there's only so many ways to write a skeleton for loop, right? When can we talk about "fair use" in the same way as for quotes from a book?

@Nicola Tuveri 

The thing that I see being an outright threat with AI isn't so much about where the code it generated came from, but rather that it can produce code so damn fast, and with obvious slop that people using it don't always pay attention to. It's scary to realize that others may accept that, 'cause quicker in spite of the quality deterioration.

So folks who care more react... and some want to reawaken Ned Ludd (https://en.wikipedia.org/wiki/Ned_Ludd)

No, I'm personally not that negative... but I gotta admit, I'm in a "wait and see" state

Circling back to the provoking point, "Authors should be explicitly aware that the burden is on them to ensure no unlicensed code is submitted to the project", I wouldn't take it farther than "to the best of your knowledge".

As was pointed out before, we run the same sort of risk because people might "be inspired by" stuff on stackflow or whatever forum, guides, book on programming they've read, yada yada yada

https://github.com/orgs/open-quantum-safe/discussions/2253 this discussion seems relevant