Hi, I am not saying you said it, but I respectfully mean that contributors, reviewers, and committers can't feasibly understand and enforce the ASF guidelines. We would be another link in a chain of people abdicating responsibility starting with LLM vendors serving up models that reproduce copyrighted code, then going to ASF legal which gives us guidelines without the tools to enforce those guidelines, and now we (the PMC) would be doing the same to contributors, reviewers, and committers.
> I don’t think anyone is going to be able to maintain and enforce a list of > acceptable tools for contributors to the project to stick to. We can’t know > what someone did on their laptop, all we can do is evaluate the code they > submit. I agree we might not be able to do a perfect job at any aspect of trying to make sure that the code we accept is not problematic I some way, but that doesn't mean we shouldn't try? We don't even necessarily need to be that restrictive beyond requiring tools that make at least some effort not to reproduce large amounts of copyrighted code that may/may not be license compatible or tools that are themselves not license compatible. This ends up encompassing most of the ones people want to use anyways. How many people are aware that if you get code from OpenAI directly that the license isn't ASL compatible, but that if you get it via Microsoft services that use OpenAI models that it's ASL compatible? It's not in the ASF guidelines (it was but they removed it!). How many people are aware that when people use locally run models there is no output filtering further increasing the odds of the model reproducing copyright encumbered code? There is a non-zero amount we can do to educate and guide that would be better than pointing people to the ASF guidelines and leaving it at that. The ASF guidelines themselves have suggestions like requiring people to say if they used AI and then which AI. I don't think it's very useful beyond checking license compatibility of the AI itself, but that is something we should be doing so it might as well be documented and included in the PR text. Ariel On Mon, Jun 2, 2025, at 7:54 PM, Jeremiah Jordan wrote: > I don’t think I said we should abdicate responsibility? I said the key point > is that contributors, and more importantly reviewers and committers > understand the ASF guidelines and hold all code to those standards. Any > suspect code should be blocked during review. As Roman says in your quote, > this isn’t about AI, it’s about copyright. If someone submits copyrighted > code to the project, whether an AI generated it or they just grabbed it from > a Google search, it’s on the project to try not to accept it. > I don’t think anyone is going to be able to maintain and enforce a list of > acceptable tools for contributors to the project to stick to. We can’t know > what someone did on their laptop, all we can do is evaluate the code they > submit. > > -Jeremiah > > On Mon, Jun 2, 2025 at 6:39 PM Ariel Weisberg <ar...@weisberg.ws> wrote: >> __ >> Hi, >> >> As PMC members/committers we aren't supposed to abdicate this to legal or to >> contributors. Despite the fact that we aren't equipped to solve this problem >> we are supposed to be making sure that code contributed is non-infringing. >> >> This is a quotation from Roman Shaposhnik from this legal thread >> https://lists.apache.org/thread/f6k93xx67pc33o0yhm24j3dpq0323gyd >> >>> Yes, because you have to. Again -- forget about AI -- if a drive-by >>> contributor submits a patch that has huge amounts of code stolen from some >>> existing copyright holder -- it is very much ON YOU as a committer/PMC to >>> prevent that from happening. >> >> We aren't supposed to knowingly allow people to use AI tools that are known >> to generate infringing contributions or contributions which are not license >> compatible (such as OpenAI terms of use). >> >> Ariel >> On Mon, Jun 2, 2025, at 7:08 PM, Jeremiah Jordan wrote: >>> > Ultimately it's the contributor's (and committer's) job to ensure that >>> > their contributions meet the bar for acceptance >>> To me this is the key point. Given how pervasive this stuff is becoming, I >>> don’t think it’s feasible to make some list of tools and enforce it. Even >>> without getting into extra tools, IDEs (including IntelliJ) are doing more >>> and more LLM based code suggestion as time goes on. >>> I think we should point people to the ASF Guidelines around such tools, and >>> the guidelines around copyrighted code, and then continue to review patches >>> with the high standards we have always had in this project. >>> >>> -Jeremiah >>> >>> On Mon, Jun 2, 2025 at 5:52 PM Ariel Weisberg <ar...@weisberg.ws> wrote: >>>> __ >>>> Hi, >>>> >>>> To clarify are you saying that we should not accept AI generated code >>>> until it has been looked at by a human and then written again with >>>> different "wording" to ensure that it doesn't directly copy anything? >>>> >>>> Or do you mean something else about the quality of "vibe coding" and how >>>> we shouldn't allow it because it makes bad code? Ultimately it's the >>>> contributor's (and committer's) job to ensure that their contributions >>>> meet the bar for acceptance and I don't think we should tell them how to >>>> go about meeting that bar beyond what is needed to address the copyright >>>> concern. >>>> >>>> I agree that the bar set by the Apache guidelines are pretty high. They >>>> are simultaneously impossible and trivial to meet depending on how you >>>> interpret them and we are not very well equipped to interpret them. >>>> >>>> It would have been more straightforward for them to simply say no, but >>>> they didn't opt to do that as if there is some way for PMCs to acceptably >>>> take AI generated contributions. >>>> >>>> Ariel >>>> >>>> On Mon, Jun 2, 2025, at 5:03 PM, David Capwell wrote: >>>>>> fine tuning encourage not reproducing things verbatimI think not >>>>>> producing copyrighted output from your training data is a technically >>>>>> feasible achievement for these vendors so I have a moderate level of >>>>>> trust they will succeed at it if they say they do it. >>>>> >>>>> Some team members and I discussed this in the context of my documentation >>>>> patch (which utilized Claude during composition). I conducted an >>>>> experiment to pose high-level Cassandra-related questions to a model >>>>> without additional context, while adjusting the temperature parameter >>>>> (tested at 0.2, 0.5, and 0.8). The results revealed that each test >>>>> generated content copied verbatim from a specific non-Apache (and >>>>> non-DSE) website. I did not verify whether this content was copyrighted, >>>>> though it was easily identifiable through a simple Google search. This >>>>> occurred as a single sentence within the generated document, and as I am >>>>> not a legal expert, I cannot determine whether this constitutes a >>>>> significant issue. >>>>> >>>>> The complexity increases when considering models trained on different >>>>> languages, which may translate content into English. In such cases, a >>>>> Google search would fail to detect the origin. Is this still considered >>>>> plagiarism? Does it violate copyright laws? I am uncertain. >>>>> >>>>> Similar challenges arise with code generation. For instance, if a model >>>>> is trained on a GPL-licensed Python library that implements a novel data >>>>> structure, and the model subsequently rewrites this structure in Java, a >>>>> Google search is unlikely to identify the source. >>>>> >>>>> Personally, I do not assume these models will avoid producing copyrighted >>>>> material. This doesn’t mean I am against AI at all, but rather reflects >>>>> my belief that the requirements set by Apache are not easily “provable” >>>>> in such scenarios. >>>>> >>>>> >>>>>> My personal opinion is that we should at least consider allow listing a >>>>>> few specific sources (any vendor that scans output for infringement) and >>>>>> add that to the PR template and in other locations (readme, web site). >>>>>> Bonus points if we can set up code scanning (useful for non-AI >>>>>> contributions!). >>>>> >>>>> My perspective, after trying to see what AI can do is the following: >>>>> >>>>> Strengths >>>>> * Generating a preliminary draft of a document and assisting with >>>>> iterative revisions >>>>> * Documenting individual methods >>>>> * Generation of “simple” methods and scripts, provided the underlying >>>>> libraries are well-documented in public repositories >>>>> * Managing repetitive or procedural tasks, such as “migrating from X to >>>>> Y” or “converting serializations to the X interface” >>>>> >>>>> Limitations >>>>> * Producing a fully functional document in a single attempt that meets >>>>> merge standards. When documenting Gens.java and Property.java, the output >>>>> appeared plausible but contained frequent inaccuracies. >>>>> * Addressing complex or ambiguous scenarios (“gossip”), though this >>>>> challenge is not unique to AI—Matt Byrd and I tested Claude for >>>>> CASSANDRA-20659, where it could identify relevant code but proposed >>>>> solutions that risked corrupting production clusters. >>>>> * Interpreting large-scale codebases. Beyond approximately 300 lines of >>>>> actual code (excluding formatting), performance degrades significantly, >>>>> leading to a marked decline in output quality. >>>>> >>>>> Note: When referring to AI/LLMs, I am not discussing interactions with a >>>>> user interface to execute specific tasks, but rather leveraging code >>>>> agents like Roo and Aider to provide contextual information to the LLM. >>>>> >>>>> Given these observations, it remains challenging to determine optimal >>>>> practices. In some contexts its very clear to tell that nothing was >>>>> taking from external work (e.g., “create a test using our BTree class >>>>> that inserts a row with a null column,” “analyze this function’s >>>>> purpose”). However, for substantial tasks, the situation becomes more >>>>> complex. If the author employed AI as a collaborative tool during “pair >>>>> programming,” concerns are not really that different than google searches >>>>> (unless the work involves unique elements like introducing new data >>>>> structures or indexes). Conversely, if the author “vibe coded” the entire >>>>> patch, two primary concerns arise: does the author have writes to the >>>>> code and whether its quality aligns with requirements. >>>>> >>>>> >>>>> TL;DR - I am not against AI contributions, but strongly prefer its done >>>>> as “pair programing”. My experience with “vibe coding” makes me worry >>>>> about the quality of the code, and that the author is less likely to >>>>> validate that the code generated is safe to donate. >>>>> >>>>> This email was generated with the help of AI =) >>>>> >>>>> >>>>>> On May 30, 2025, at 3:00 PM, Ariel Weisberg <ar...@weisberg.ws> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> It looks like we haven't discussed this much and haven't settled on a >>>>>> policy for what kinds of AI generated contributions we accept and what >>>>>> vetting is required for them. >>>>>> >>>>>> https://www.apache.org/legal/generative-tooling.html#:~:text=Given%20the%20above,code%20scanning%20results. >>>>>> >>>>>> ``` >>>>>> Given the above, code generated in whole or in part using AI can be >>>>>> contributed if the contributor ensures that: >>>>>> >>>>>> 1. The terms and conditions of the generative AI tool do not place any >>>>>> restrictions on use of the output that would be inconsistent with the >>>>>> Open Source Definition. >>>>>> 2. At least one of the following conditions is met: >>>>>> 2.1 The output is not copyrightable subject matter (and would not be >>>>>> even if produced by a human). >>>>>> 2.2 No third party materials are included in the output. >>>>>> 2.3 Any third party materials that are included in the output are >>>>>> being used with permission (e.g., under a compatible open-source >>>>>> license) of the third party copyright holders and in compliance with the >>>>>> applicable license terms. >>>>>> 3. A contributor obtains reasonable certainty that conditions 2.2 or 2.3 >>>>>> are met if the AI tool itself provides sufficient information about >>>>>> output that may be similar to training data, or from code scanning >>>>>> results. >>>>>> ``` >>>>>> >>>>>> There is a lot to unpack there, but it seems like any one of 2 needs to >>>>>> be met, and 3 describes how 2.2 and 2.3 can be satisfied. >>>>>> >>>>>> 2.1 is tricky as we are not copyright lawyers, and 2.2 and 2.3 is a >>>>>> pretty high bar in that it's hard to know if you have met it. Do we have >>>>>> anyone in the community running any code scanning tools already? >>>>>> >>>>>> Here is the JIRA for addition of the generative AI policy: >>>>>> https://issues.apache.org/jira/browse/LEGAL-631 >>>>>> Legal mailing list discussion of the policy: >>>>>> https://lists.apache.org/thread/vw3jf4726yrhovg39mcz1y89mx8j4t8s >>>>>> Legal mailing list discussion of compliant tools: >>>>>> https://lists.apache.org/thread/nzyl311q53xhpq99grf6l1h076lgzybr >>>>>> Legal mailing list discussion about how Open AI terms are not Apache >>>>>> compatible: >>>>>> https://lists.apache.org/thread/lcvxnpf39v22lc3f9t5fo07p19237d16 >>>>>> Hadoop mailing list message hinting that they accept contributions but >>>>>> ask which tool: >>>>>> https://lists.apache.org/thread/bgs8x1f9ovrjmhg6b450bz8bt7o43yxj >>>>>> Spark mailing list message where they have given up on stopping people: >>>>>> https://lists.apache.org/thread/h6621sxfxcnnpsoyr31x65z207kk80fr >>>>>> >>>>>> I didn't see other projects discussing and deciding how to handle these >>>>>> contributions, but I also didn't check that many of them only Hadoop, >>>>>> Spark, Druid, Pulsar. I also can't see their PMC mailing list. >>>>>> >>>>>> I asked O3 to deep research what is done to avoid producing copyrighted >>>>>> code: https://chatgpt.com/share/683a2983-dd9c-8009-9a66-425012af840d >>>>>> >>>>>> To summarize training deduplicates training so the model is less likely >>>>>> to spit reproduce it verbatim, prompts and fine tuning encourage not >>>>>> reproducing things verbatim, the inference is biased to not pick the >>>>>> best option but some neighboring one encouraging originality, and in >>>>>> some instances the output is checked to make sure it doesn't match the >>>>>> training data. So to some extent 2.2 is being done to different degrees >>>>>> depending on what product you are using. >>>>>> >>>>>> It's worth noting that scanning the output can be probabilistic in the >>>>>> case of say Anthropic and they still recommend code scanning. >>>>>> >>>>>> Quite notably Anthropic for its enterprise users indemnifies them >>>>>> against copyright claims. It's not perfect, but it does mean they have >>>>>> an incentive to make sure there are fewer copyright claims. We could >>>>>> choose to be picky and only accept specific sources of LLM generated >>>>>> code based on perceived safety. >>>>>> >>>>>> I think not producing copyrighted output from your training data is a >>>>>> technically feasible achievement for these vendors so I have a moderate >>>>>> level of trust they will succeed at it if they say they do it. >>>>>> >>>>>> I could send a message to the legal list asking for clarification and a >>>>>> set of tools, but based on Roman's communication >>>>>> (https://lists.apache.org/thread/f6k93xx67pc33o0yhm24j3dpq0323gyd) I >>>>>> think this is kind of what we get. It's on us to ensure the >>>>>> contributions are kosher either by code scanning or accepting that the >>>>>> LLM vendors are doing a good job at avoiding copyrighted output. >>>>>> >>>>>> My personal opinion is that we should at least consider allow listing a >>>>>> few specific sources (any vendor that scans output for infringement) and >>>>>> add that to the PR template and in other locations (readme, web site). >>>>>> Bonus points if we can set up code scanning (useful for non-AI >>>>>> contributions!). >>>>>> >>>>>> Regards, >>>>>> Ariel >>>> >>
