Mastodawn

got hit by a wave of slop prs last week so i guess it’s time to buckle down and spend my morning…

writing an ai policy

this looks-legitimate-but-trash slop reminds me of corporate phishing tests

the biggest tragedy for me is that i’ve spent A LOT of time and energy to encourage contributions to my projects and now i have to spend TBD energy on gate-keeping

Show thread

Hynek Schlawack Feb 21

it’s very disheartening to try to walk the line between “if you need help, reach out” and “don’t waste our time with thoughtless slop”

Show thread

Stephen Rosen Feb 21

@hynek the part I dislike the most is the pressure to include "instructions for agents" in contrib docs. I might do it (at the end, clearly delineated so that nobody has to read it) because it seems somewhat effective, but it feels inherently icky.

Also, I'm sure you've seen it, but the FastAPI policy seems closest to your vibe. Having done a lot of reading in this space, that one stands out for being short, clear, and friendly in tone.

Show thread

Hynek Schlawack Feb 21

@sirosen I'm moving ours into a separate file to not tone-poison the hopefully-welcoming contributing guide. and I honestly don't think with our guide there is a need for instructions for agents.

https://github.com/python-attrs/attrs/pull/1518

Add explicit AI policy by hynek · Pull Request #1518 · python-attrs/attrs

Due to recent events, I'm afraid this is necessary.

GitHub

Show thread

Paul Ganssle Mar 8

@hynek @sirosen The legal stuff in that AI policy isn't sitting quite right with me. I understand the concern with the legal status of AI generated content but I think the menu of outcomes here is probably some combination of:

1. AI generated content is owned by the person who wrote the prompt
2. AI generated content is not eligible for copyright
3. AI generated content is owned by the model owner (or the model itself??)
4. AI generated content is a derivative work of its training data and context

If it's 1 or 2 you are fine because 1 is equivalent to hand-written code and 2 is equivalent to incorporating public domain code (modulo jurisdictions that CC-0 was created to address). 3 is probably also fine because it's roughly a work for hire.

Scenario 4 means that those contributions are derivative works of a combination of a bunch of GPL and proprietary works and the contributor doesn't have the right to offer it under a less restrictive license in the first place, so "you take legal responsibility" doesn't seem like it helps the situation. If you are asking the contributor to indemnify you if it turns out they had no legal right to contribute and you get sued by someone claiming attrs is now a derivative work of their material? If so you should probably be explicit about that.

Would it be valuable for me to comment about this in the issue / PR?

Show thread

Stephen Rosen Mar 8

@pganssle @hynek
I think that suite of options is correct. Notably there is a lot of money bound up in the answer *not* being (4).

(In my heart of hearts, it feels the most correct. But I don't know what to do with that feeling.)

Show thread

Paul Ganssle

@sirosen @hynek What is missing as a possibility? My analysis is basically saying that scenario 4 is the only one where maintainers incur legal risk so it's the only one you need to think about when designing a policy to protect yourself from uncertainty here. If there is another scenario where the maintainer has legal risk - especially where a more likely one - I would love to hear it.