--nextPart4913147.31r3eYUQgx
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; protected-headers="v1"
From: Volker Krause <vkrause@kde.org>
To: kde-community@kde.org
Cc: kimageshop@kde.org
Subject: Re: Licensing for models and datasets
Date: Tue, 26 Mar 2024 17:33:56 +0100
Message-ID: <6035525.lOV4Wx5bFT@vkpc5>
Organization: KDE
In-Reply-To: <4905945.31r3eYUQgx@thinkstation>
References: <4905945.31r3eYUQgx@thinkstation>
MIME-Version: 1.0

On Montag, 25. M=E4rz 2024 15:17:48 CET Halla Rempt wrote:
> We're looking into adding an experimental AI-based feature to Krita:
> automated inking. That gives us three components, and we're not sure about
> the license we should use for two of them: the model and the datase. Would
> CC be best here?

Looking at https://community.kde.org/Policies/Licensing_Policy the closest=
=20
thing would either be "media" files (generalized to "data files") and thus =
CC-
BY-SA (and presumably CC-BY/CC0) or "source code" (xGPL, BSD/MIT).

I think this is a bit more tricky though, depending on whether we assume a=
=20
model is derivative work of the input data, and whether the output generate=
d=20
from a model is derivative work of the model (and thus potentially derivati=
ve=20
work of the input data). The industry assumption so far seems to be that at=
=20
least one of those isn't derivative work (AFAIK that has yet to be legally=
=20
tested though), but I'm not sure that interpretation is in the best interes=
t=20
of FOSS developers or artists...

One scenario that would work regardless I think is using a license with=20
practically no constraints (CC0, MIT, etc), but that also offers no protect=
ion=20
for the training or model data (which might or might not be what you want).

Any other scenario I can think of involving more protective licenses runs i=
nto=20
interesting issues:
=2D if the output is derivative work, Krita users would be bound by e.g. th=
e=20
attribution or share-alike requirements of the license (which I guess is no=
t=20
what you want).
=2D a Bison/Flex style "code generator exception" to state that the model o=
utput=20
is free of any license requirements regardless of the model license itself=
=20
requires that either the model isn't derivative work of the input or that t=
he=20
input data is licensed in a way compatible with that.
=2D In the latter case we are back to essentially unprotected CC0-like inpu=
t, or=20
a protective license with a special exception, which then gets awfully clos=
e=20
to developing new licenses.

So I guess this boils down to how much protection you have in mind for the=
=20
input and model data?

Interesting topic, sorry if my ramblings on this are of limited help :)

Regards,
Volker
--nextPart4913147.31r3eYUQgx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

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

iF0EABECAB0WIQQAnu3FVHA48KjZ07R/lszWTRLSRwUCZgL49AAKCRB/lszWTRLS
RzTBAJ94lNKjSOPvuC/a3H/Y8FgsQ9ZazwCeJLq5eTBotK1KsQ00R72t41pRdvw=
=l5Bx
-----END PGP SIGNATURE-----

--nextPart4913147.31r3eYUQgx--