Re: License for not human generated files

--RDKXvFxfQxTXriYc
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello Michael,

Michael Stehmann dijo [Wed, May 20, 2026 at 11:28:21AM +0200]:
>Hello,
>
>my question is: How should Debian treats not human generated files.
>
>Starting point:
>
>An .orig.tar.[g|x]z contains files, which are not human generated.
>
>(I know that there is an discussion on debian-vote about a General=20
>Resolution "Allow AI-Assisted Contributions". But the content of files=20
>might also generated by (non AI) application (example: tools for=20
>autoconfiguration).)
>
>My assumption is that content generated by machine is not human=20
>artwork and not copyrightable.
>(...)
>Should Debian allow a pseudo copyright remark like "not copyrightable"=20
>to clarify the legal situation of the files mentioned above?

Just thinking out loud here...

Many files are not the _direct_ output of human actions, but the result of
some transforms over it. For example, if I create a set of icons, I am not
directly writing the SVG or PNG renditions. But they are directly created
=66rom my actions. It is not even an exactly repeatable action... I could
show how I built a given SVG, but the result would very likely not be
bit-identical. Still, we will accept SVG as the _closest we can get_ to a
source document, and as a preferred form of modification.

Autoconf and such files would be something similar: Across the many build
systems and languages, we will find an existing, human-generated
manifest. This manifest is processed, together with the running system
information (which we now care to document enough for it to be
reproducible!), and a =E2=80=9Cverbosified=E2=80=9D autoconf / cargo / Make=
file.PL /
composer / whatever non-human-generated file is generated.

So, given a (simpler) human-generated manifest, together with build
environment information, the autoconf system works as some sort of
compiler. And we often ship this compiled file for convenience =E2=80=94 bu=
t (in
principle, at least) we could just regenerate it from =E2=80=9Creal=E2=80=
=9D sources.

Yes, I'm oversimplifying many bits, and I know there are some procedural
details that probably make my point not always valid. But would you find
this a better point to work from?

Greetings,

=E2=80=89=E2=80=94=E2=80=89Gunnar.

--RDKXvFxfQxTXriYc
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRgswk9lhCOXLlxQu/i9jtDU/RZiQUCag3L4wAKCRDi9jtDU/RZ
ibh0AP9Rb0ee0w6fnhm9OaQkvxyVZ2Fv1NDYDPvfdxeyVp4SFQEAh/P2Qp+sp5V9
GBpazfpX8dh8vQ6nhsZwjonXsB/I3Qg=
=Ao4L
-----END PGP SIGNATURE-----

--RDKXvFxfQxTXriYc--