I'm on with the allow list(1) or option 2. 3 just isn't realistic anymore.
Patrick On Mon, Jun 16, 2025 at 3:09 PM Caleb Rackliffe <calebrackli...@gmail.com> wrote: > I haven't participated much here, but my vote would be basically #1, i.e. > an "allow list" with a clear procedure for expansion. > > On Mon, Jun 16, 2025 at 4:05 PM Ariel Weisberg <ar...@weisberg.ws> wrote: > >> Hi, >> >> We could, but if the allow list is binding then it's still an allow list >> with some guidance on how to expand the allow list. >> >> If it isn't binding then it's guidance so still option 2 really. >> >> I think the key distinction to find some early consensus on if we do a >> binding allow list or guidance, and then we can iron out the guidance, but >> I think that will be less controversial to work out. >> >> Or option 3 which is not accepting AI generated contributions. I think >> there are some with healthy skepticism of AI generated code, but so far I >> haven't met anyone who wants to forbid it entirely. >> >> Ariel >> >> On Mon, Jun 16, 2025, at 4:54 PM, Josh McKenzie wrote: >> >> Couldn't our official stance be a combination of 1 and 2? i.e. "Here's an >> allow list. If you're using something not on that allow list, here's some >> basic guidance and maybe let us know how you tried to mitigate some of this >> risk so we can update our allow list w/some nuance". >> >> On Mon, Jun 16, 2025, at 4:39 PM, Ariel Weisberg wrote: >> >> Hi, >> >> On Wed, Jun 11, 2025, at 3:48 PM, Jeremiah Jordan wrote: >> >> Where are you getting this from? From the OpenAI terms of use: >> https://openai.com/policies/terms-of-use/ >> >> Direct from the ASF legal mailing list discussion I linked to in my >> original email calling this out >> https://lists.apache.org/thread/lcvxnpf39v22lc3f9t5fo07p19237d16 It's >> not clear from that thread precisely what they are objecting to and whether >> it has changed (another challenge!), but I believe it's restrictions on >> what you are allowed to do with the output of OpenAI models. And if you get >> the output via other service's it's under a different license and it's fine! >> >> Already we are demonstrating that it is not trivial understand what is >> and isn't allowed >> >> On Wed, Jun 11, 2025, at 3:48 PM, Jeremiah Jordan wrote: >> >> I still maintain that trying to publish an exhaustive list of acceptable >> tools does not seem reasonable. >> But I agree that giving people guidance is possible. Maybe having a >> statement in the contribution guidelines along the lines of: >> >> The list doesn't need to be exhaustive. We are not required to accept AI >> generated code at all! >> >> We can make a best effort to just vet the ones that people actually want >> to widely use and refuse everything else and be better off than allowing >> people to use tools that are known not to be license compatible or make >> little/no effort to avoid reproducing large amounts of copyrighted code. >> >> “Make sure your tools do X, here are some that at the time of being added >> to this list did X, Tool A, Tool B … >> Here is a list of tools that at the time of being added to this list did >> not satisfy X. Tool Z - reason why” >> >> I would be fine with this as an outcome. If we voted with multiple >> options it wouldn't be my first choice. >> >> This thread only has 4 participants so far so it's hard to get a signal >> on what people would want if we tried to vote. >> >> David, Scott, anyone else if the options were: >> >> 1. Allow list >> 2. Basic guidance as suggested by Jeremiah, but primarily leave it up >> to contributor/reviewer >> 3. Do nothing >> 4. My choice isn't here >> >> What would you want? >> >> My vote in choice order is 1,2,3. >> >> Ariel >> >> >> On Wed, Jun 11, 2025, at 3:48 PM, Jeremiah Jordan wrote: >> >> >> I respectfully mean that contributors, reviewers, and committers can't >> feasibly understand and enforce the ASF guidelines. >> >> If this is true, then the ASF is in a lot of trouble and you should bring >> it up with the ASF board. >> Where are you getting this from? From the OpenAI terms of use: >> https://openai.com/policies/terms-of-use/ >> >> 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. >> >> >> 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. >> >> >> I still maintain that trying to publish an exhaustive list of acceptable >> tools does not seem reasonable. >> But I agree that giving people guidance is possible. Maybe having a >> statement in the contribution guidelines along the lines of: >> “Make sure your tools do X, here are some that at the time of being added >> to this list did X, Tool A, Tool B … >> Here is a list of tools that at the time of being added to this list did >> not satisfy X. Tool Z - reason why” >> >> -Jeremiah >> >> >> On Jun 11, 2025 at 11:48:30 AM, Ariel Weisberg <ar...@weisberg.ws> wrote: >> >> >> 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 verbatim >> >> 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. >> >> >> 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 >> >> >> >> >> >> >> >>
