| opendevreview | Grzegorz Grasza proposed openstack/contributor-guide master: docs: add guidelines for tool-generated contributions https://review.opendev.org/c/openstack/contributor-guide/+/984061 | 15:57 |
|---|---|---|
| *** vhari_ is now known as vhari | 16:59 | |
| gouthamr | https://www.kubernetes.dev/docs/guide/pull-requests/#ai-guidance was updated today.. some interesting things to note, and ponder upon | 19:21 |
| gouthamr | https://groups.google.com/a/kubernetes.io/g/dev/c/7Y9016gdFZw/m/nUUmxFPzAQAJ?utm_medium=email&utm_source=footer | 19:21 |
| fungi | interesting that they bring up dependabot in the discussion there, i made a similar point on xek's documentation proposal | 19:32 |
| clarkb | its also interesting that putting the info in the commit message is bad bceause the machines can't agree to the things (which has been aprt of my concern), but then its ok to use them anyway and note them in the PR outside of git itself | 19:33 |
| fungi | in particular, "signed-off-by" has whatever meaning the project's leadership wants to assign to it. if the tc wants to say it means one thing for commits pushed by people and another thing (or nothing at all) for commits pushed from agreed-upon automated accounts, that's perfectly fine and sensible | 19:35 |
| clarkb | right, though in the k8s case the email explicitly says `Kubernetes cannot and will not allow co-authoring PRs or co-signing commits with AI for the simple reason that the AI cannot sign a CLA; this is a legal requirement.` but its okt to actually co author the PR and note it it outside of git | 19:36 |
| gouthamr | clarkb: the commit message tagging has been quite inconsistent in our space, so i also wonder about the usefulness.. maybe we should evaluate this part.. but, we don't have any other way to quickly signal to reviewers that AI was used - PR descriptions on GitHub/Gitlab are easy metadata | 19:36 |
| clarkb | to me thats an indication youcannot accept and ai assisted contributions under your legal agreement (the CLA), but they must see it differently | 19:37 |
| clarkb | gouthamr: right I'm trying to get to the lawyer below the human UX | 19:37 |
| clarkb | "is this even legal" | 19:37 |
| fungi | lawyer or layer? | 19:37 |
| clarkb | and I think if you do an honest read of the DCO and likely their CLA the answer you come up with is "no" | 19:37 |
| clarkb | but no one wants to accept that so instead we hand wave around it and say things like the machien can't sign off on this so you do it and we'll pretend no one cares | 19:38 |
| clarkb | fungi: layer but I like the typo | 19:38 |
| clarkb | for me personally it makes me question why we have the rules and policies in the first place if we can ignore them the instant it inconveniences the right/wrong people | 19:38 |
| * gouthamr replays JayF's accountable.computer mention | 19:38 | |
| gouthamr | i think we need the foundation to help us with legal review again, things have changed since the last version of this | 19:39 |
| fungi | i'll just note that if openstack *does* decide they're going to require a "responsible human" to sign-off on every change pushed by the proposal and release bot accounts, i'm not volunteering to be that human | 19:39 |
| clarkb | (and as I've noted in other contexts I think challenging that stuff and changing the rules is healthy. So I'm not opposed to that. What I do have concersn with is keeping the rules as they are and pretending that we can ignore them)( | 19:39 |
| gouthamr | fungi: we'll gather wider feedback on the tooling thing, maybe we start with a resolution that we want to allow DCO sign-offs for OpenDev automation patches with no LLM usage explicitly. This is our explicit acknowledgement that we have technical constraints to do anything else, and would rather not spend the time to evolve a process | 19:41 |
| fungi | expecting to bring our longstanding automation into compliance with new policies designed to gatekeep people who send in ai slop is essentially an obstructionist move straight out of the simple sabotage field manual | 19:41 |
| fungi | which, by the way, is an interesting historical read for anyone not familiar with it: https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/SimpleSabotage.pdf | 19:43 |
| gouthamr | omg | 19:44 |
| fungi | you'll recognize a lot of common tactics in there that crop up regularly in open source communities | 19:45 |
| gouthamr | i only knew of a probably much less nefarious one in our community :P the queen's duck strategy | 19:48 |
| * gouthamr context: https://blog.codinghorror.com/new-programming-jargon/ | 19:51 | |
| clarkb | re the DCO specifically I've thought about this a lot and if you read it the intent seems to be that the content that is in the commit is either written by you and you have permission adn give permission to contribute it under the license or it is written by someone else who has done so. Within that context what our existing bots do is completely fine imo. For example with | 19:53 |
| clarkb | translations we're taking translations from people who have signed off on the contributions similarly but using a different transport layer and are merely including their work within the software | 19:53 |
| clarkb | where I trip up with the LLM stuff is the LLM services and the non open models in particular (but even using an open model on a hosted service) is typically providing you with content under different license terms. That is at odds with clause b and c of the DCO | 19:54 |
| clarkb | 'The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file;' <- | 19:55 |
| clarkb | this is b | 19:55 |
| clarkb | claude for example does not output content that is licensed with an appropriate open source license | 19:55 |
| gouthamr | yeah let’s you copyright it, license it however you prefer | 19:56 |
| clarkb | no there are a bunch of stipulations | 19:56 |
| clarkb | which are at odds with open source licensing in particular | 19:56 |
| fungi | similarly https://openinfra.org/legal/ai-policy calls out "Source training data, and thus resulting material, may come from materials which have unclear or incompatible copyrights and/or licenses. In other cases, copyright of any generated code may be explicitly retained by the vendor operating the AI technology, which is incompatible with contribution to projects. Furthermore, | 19:57 |
| clarkb | there are like 5 things you are forbidden from doing | 19:57 |
| fungi | some tools have demonstrated the ability to source context from the contents of a project being worked upon. Ultimately this requires awareness of the End-User License Agreement by the contributor." | 19:57 |
| clarkb | my argument would be that if we feel these tools are so valuable and that copyright is so weak anyway that we can simply ignore the rules we have for ensuring proper open source licensing then we should do away with the DCO entirely | 19:58 |
| clarkb | then we can focus on the UX how how to keep developers and reviewers sane | 19:58 |
| fungi | the policy also states: "Contributors need to verify they have the right to contribute output from AI tools, just like they do for their own original work, work owned by their employer, work copied or modified from another open source project, or work submitted on behalf of a third party." | 19:58 |
| gouthamr | honestly that’s a big bar | 19:58 |
| fungi | i read it as "you shouldn't push changes written in part or in whole by an llm unless you're really, really, really sure it's okay, and even then you probably shouldn't" | 19:59 |
| gouthamr | there isn’t any verifiable way to know for sure; you ask Claude this question and it’ll make up some stuff like “nope I didn’t copy any code from anywhere” | 19:59 |
| clarkb | gouthamr: there is: you build a model that was built only from compatibly licensed content | 20:00 |
| clarkb | for some value of you | 20:00 |
| clarkb | I think we would accept a reasonable assertion that someone else did so and distributed the resulting weights too | 20:00 |
| gouthamr | which is true, it synthesized it from its training, which was probably all the stuff we have produced under open source licenses for decades | 20:00 |
| clarkb | but yes I agree the bar is high and I don't think anyone is actually clearing it in their current use of the tools within openstack | 20:00 |
| fungi | it's getting discussed again in the cpython community as well, with a similar interpretation that the seemingly permissive ai contribution policy there is really mostly an impossible hurdle to clear in most popular cases, so anyone who is using an llm for their contributions is basically just yolo | 20:01 |
| clarkb | so we either stop using the tools and possibly find tools taht clear the bar. Or we need different rules. | 20:01 |
| clarkb | but I feel more and more strongly that until we answer these more fundamental questions then worrying about how to keep code reviewers sane is impossible | 20:02 |
| clarkb | because if I am asked to review something the only response I can currently give is "I'm sorry I believe this isn't acceptable under the terms of the DCO and I won't be able to accept it" | 20:02 |
| fungi | the two sides of the discussion in cpython are "we should ban use of llms for contributions because you can't know for sure they're legally safe" and "we should welcome safe use of llms for contributions in case someone eventually creates a popular llm that is safe for this purpose, even though probably none are now" | 20:03 |
| fungi | but yes, people continue to use them under the expectation that if they're determined to be a problem eventually someone else will be on the hook to deal with the resulting fallout | 20:04 |
| clarkb | fungi: I'm ready to start having nightmares about git filter branchin every openstack repo and force pushing the result | 20:05 |
| gouthamr | if they’ve declared it | 20:05 |
| clarkb | or if it is an obvious copy pasta reproduction as the models have been shown to do | 20:06 |
| fungi | filter-branch probably isn't enough even if they did declare it, because subsequent commits are likely derivative works of the commits you're filtering out too | 20:06 |
| fungi | the counterargument of course is that there are likely illegally-supplied commits already present in most large open source project from long before llms came into existence, so this isn't an llm-specific problem | 20:07 |
| gouthamr | some community focused short term measures may be required; maybe we consider a blanket ban on “sloppy” contributions.. because there are two sections in our community too - those that have access to these tools and are willing to use it, and those that don’t and are genuinely continuing their work without the need for this… | 20:07 |
| clarkb | as a reviewer of code that gets included in these projects I think ideally there would be a concrete set of guidance to go along with whatever policy there is. "For example qwen next coder is ok due to its licensing terms. Claude is not." Or "Claude is fine have at it" | 20:08 |
| clarkb | because unfortunately our existing policy is hopeful and vague and hands off a lot of ersponsibility to individuals who really shouldn't be making these decisions (and I include myself in that bucket) | 20:08 |
| fungi | i have a feeling it's going to end up getting ignored because so many people did it that undoing it now will be intractable and the affected ecosystems/industries are "too big to fail" | 20:08 |
| fungi | another way to look at it is that llms call the very nature of copyright into question, and maybe it won't exist in the near future | 20:09 |
| clarkb | gouthamr: there is a third group: those of us with access who feel they acnnot use them due to the rules | 20:09 |
| clarkb | (it me) | 20:09 |
| fungi | yeah, i have personally never used an llm in my professional work or even personal hobby projects | 20:10 |
| fungi | nor am i particularly interested in doing soi | 20:10 |
| gouthamr | ack; this is good fodder for the discussion at the PTG, I’ve heard murmurs that project teams have specific feedback | 20:10 |
| gouthamr | maybe you’ll see this in the maintainers survey too, if folks are planning to take it | 20:10 |
| fungi | yes, we added some questions about it in the maintainer and contributor surveys because we know it's on a lot of people's minds | 20:11 |
| clarkb | another way of looking at it imo is would we accept BSL code? No so why is this ok? Mostly because hype? or is it actually sound in terms of contract agreements? | 20:12 |
| clarkb | I mean we don'y even allow gplv3 code beacuse ti si viral | 20:12 |
| clarkb | but gplv3 is compatibile with apache2 and it is open source and it preserves your rights as a user | 20:13 |
| clarkb | we'er more afraid of GPLv3 than we are of undefined nebulous llm output | 20:13 |
| sean-k-mooney | well not really. apahe2 does not allwo reliseing and gpl would requrie it for the combined work | 20:13 |
| fungi | yes but, horror of horrors, if someone makes a modified copy of the software they're going to be required to supply the source code to anyone they provide binary builds to | 20:13 |
| clarkb | sean-k-mooney: right tahts what I meant by viral. It forces the combo into gplv3 | 20:14 |
| sean-k-mooney | right which you cannot do | 20:14 |
| sean-k-mooney | that would violate the apache2 requiremetns | 20:14 |
| clarkb | no gplv3 is generally considered apache2 compatible iirc | 20:14 |
| clarkb | gplv2 is not | 20:14 |
| fungi | apache2 doesn't say that a derivative work can't be distributed under a license which preserves the same set of terms as a minimum | 20:14 |
| clarkb | the only reason we don't allow gplv3 is taht we don't want to be bound by the additional requirements of gplv3 | 20:15 |
| clarkb | but it is doable aiui and is open source and preserves user rights | 20:15 |
| sean-k-mooney | i htink it prevent relsisint of the apache2 content | 20:15 |
| sean-k-mooney | but maybe your right on the v2 vs v3 case | 20:16 |
| fungi | there is no legal requirement not to relicense a derivative, the license of the derivative simply has to preserve the requirements of all the original works from which it was derived (which might be equivalent to one of the two licenses if one is a strict subset of the other, or may be a wholly new composite license that preserves the terms of both original licenses) | 20:16 |
| sean-k-mooney | """Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. """ | 20:16 |
| sean-k-mooney | https://www.apache.org/licenses/GPL-compatibility.html | 20:16 |
| clarkb | ya so the openstack sdk into ansible is ok | 20:16 |
| clarkb | but you couldn't copy ansible code out of ansible and put it in nova | 20:17 |
| fungi | right, so the resulting derivative is distributed under the gplv3 because apache license v2 is a strict subset of the terms of gpl v3 | 20:17 |
| clarkb | BUT you can release openstack-ansible-modules as part of openstack as a separate deliverable | 20:17 |
| sean-k-mooney | right i was thinkign fo the case last year or the year before where we removed an embeded ansible script form neutorn | 20:17 |
| clarkb | its just that that portion of the openstack reelase would be gplv3 not apache2 | 20:17 |
| sean-k-mooney | becuase the asnsibel was potitcaly gpl licensed i belive | 20:17 |
| fungi | you *could* copy gpl v3 code into nova and distribute the resulting derivative work under the gpl v3 | 20:17 |
| sean-k-mooney | and we just wanted to not get anywere near that | 20:17 |
| sean-k-mooney | but never upstream it | 20:18 |
| clarkb | sean-k-mooney: yup and I think not getting anywhere near that is a fine stance. until everyone suddenly becomes ok with the current situation with llms then I'm a bit confused | 20:18 |
| fungi | depends on who "upstream" is. from that perspective the person distributing the resulting derivative may be the "upstream" maintainer of the derivative | 20:18 |
| sean-k-mooney | well while that is evlvoign the current situration in the use is LLM work is consiered transformaitive even if traitned on copyrighted matiral and llm contend that is explcity not guided by a human cannot have copyright | 20:19 |
| clarkb | which is why I go back to if the rules don't make sense anymore then we should talk about it.Figure out why the rules existed in the first place, determine if there is still value to having these rules, and if not change them. This applies to more than just teh current discussion | 20:19 |
| clarkb | but more and more it seems we've just decided to ignore the rules, do what we want, and worry about it later if ever | 20:20 |
| sean-k-mooney | what not ruled on is content that has beend generated based idrectly on human input | 20:20 |
| fungi | but yes, the nova maintainers would rightfully refuse contributions ported from the "tainted" gplv3 derivative for license reasons. doesn't mean the licenses are incompatible, just that nova (and openstack) requires contributions be licensed under apache license v2 | 20:20 |
| clarkb | (part of my concern is probably the fact that I tend to be the person dealing with the fallout if/when there are issues with things like code history) | 20:20 |
| clarkb | whereas most others change jobs ever couple of yaers and completely leave all this behind them | 20:20 |
| sean-k-mooney | fungi: in that speciic can it woudl also be a dco issue in that you cant attest to contibute it under the lisces of the proejct | 20:21 |
| clarkb | so the risk to them as the individual is so low to not matter | 20:21 |
| sean-k-mooney | becuase you cant grant the gplv3 to apche2 rights (well unless its entirly yoru code and you dual or relaise it) | 20:21 |
| fungi | sean-k-mooney: right, that's essentially how the project enforces its license expectation | 20:21 |
| sean-k-mooney | ok dinner arived so im going to call it a day o/ | 20:22 |
| fungi | on the other hand, mit/expat licensed code can be accepted into nova, because that license is a strict subset of the terms of the apache license v2 and so can effectively be relicensed to apache license v2 | 20:22 |
| fungi | enjoy dinner! | 20:22 |
| gouthamr | yeah. light Friday discussion this :P | 20:23 |
| fungi | it's more fun than fixing the apt-puppetlabs mirroring config | 20:23 |
| fungi | which i should get back to | 20:23 |
| clarkb | I've got a lodgeit change proposed where I wholesale copy a werkzeug helper lirbary to fix a bug with new python because the lib is basically unmaintained. And ya aiui its fine because three clause bsd is compatible that direction and I preserved attribution: https://review.opendev.org/c/opendev/lodgeit/+/982311/8/lodgeit/vendor/secure_cookie/_compat.py | 20:24 |
| fungi | (but if it were 4-clause bsd it would be a problem!) | 20:25 |
| clarkb | which would be an example of clause b) where I have done the due diligence and it should be ok | 20:25 |
| clarkb | (I had to modify the code to fix the bug so its like 90% there 10% mine but acceptable in the end | 20:25 |
| fungi | though if memory serves, the university did announce anything they hold copyright on can officially be relicensed from 4-clause to 3-clause | 20:25 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!