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?