From: "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>
To: "Scott Chacon" <schacon@gmail.com>,
"brian m. carlson" <sandals@crustytoothpaste.net>,
"Scott Chacon" <scott@gitbutler.net>,
git@vger.kernel.org
Subject: Re: [RFC PATCH 1/1] SubmittingPatches: allow responsible AI assistance
Date: Thu, 08 Oct 2026 07:53:09 +0200 [thread overview]
Message-ID: <a54e82eb-1252-4d6b-8b4c-6e99da59252d@app.fastmail.com> (raw)
In-Reply-To: <CAP2yMa+kgphMe-cpcZSvPSqwm-npUDVp=HaNRW+MPmPzZ_aOXw@mail.gmail.com>
On Thu, Oct 8, 2026, at 06:49, Scott Chacon wrote:
> On Wed, Oct 7, 2026 at 11:42 PM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
>>[snip]
>
> I agree that generated output can reproduce material we don't have
> permission to distribute (though I think this is incredibly rare for
> anything complex). What I question is whether that possibility means
> knowing every source in the training set is necessary to make any DCO
> certification.
>
> Human contributors have also read code under many different licenses
> (and news articles and blogs) . We don't ask them to account for
> everything they've ever read before signing off on a patch.
Metaphors gone amok. You don’t regulate how submarines and human bodies
can operate in territorial waters based on the fact that they both swim.[1]
Corporations already have non-compete clauses in order to keep knowledge
workers from applying their braincraft to competing businesses.
>[snip]
>
>> I'm a distributor of Git and I don't want to be sued or arrested because
>> I end up distributing code that I don't have the right to distribute.
>>[snip]
>
>[snip]
>
>>[snip]
>
> I'm not saying that other projects haven't taken positions as
> conservative as Git's current policy. I'm saying that much larger
> projects with much larger legal surface area such as Linux have
> adopted more progressive ones. Linus is fine with it on a project with
> the same DCO, the same license, and honestly, a lot more legal
> scrutiny.
Honestly, if an individual wants to avoid the risk of getting sued over
copyright then that’s their prerogative.
>[snip]
[1] I’m not a lawyer so maybe one does.
next prev parent reply other threads:[~2026-10-08 5:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-07 14:29 [RFC PATCH 0/1] SubmittingPatches: allow responsible AI assistance Scott Chacon
2026-10-07 14:29 ` [RFC PATCH 1/1] " Scott Chacon
2026-10-07 21:42 ` brian m. carlson
2026-10-08 4:49 ` Scott Chacon
2026-10-08 5:29 ` Luca Milanesio
2026-10-08 5:53 ` Kristoffer Haugsbakk [this message]
2026-10-08 16:15 ` brian m. carlson
2026-10-07 22:44 ` Junio C Hamano
2026-10-08 13:53 ` Scott Chacon
2026-10-09 10:22 ` Patrick Steinhardt
2026-10-09 20:39 ` Junio C Hamano
2026-10-08 18:10 ` [RFC PATCH 0/1] " D. Ben Knoble
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a54e82eb-1252-4d6b-8b4c-6e99da59252d@app.fastmail.com \
--to=kristofferhaugsbakk@fastmail.com \
--cc=git@vger.kernel.org \
--cc=sandals@crustytoothpaste.net \
--cc=schacon@gmail.com \
--cc=scott@gitbutler.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox