On Wed, 14 May 2025 at 12:04, Simon Josefsson <si...@josefsson.org> wrote:
> Thank you for articulating this! How is that any different from my 2)?
>
> > 2) It is acceptable to not have DFSG-compliant licensing for things that
> > aren't important for Debian and still ship those, because doing so helps
> > our users and helping users is more important than DFSG-licensing.
Your 2) is IMHO equivalent to the 2a) in my list short-definition list
(in AI context, but has a wide definition that can be abused in other
contexts), which is putting fewer requirements on data than my
preferred option of 2b&2b+.
The additions in 2b and 2b+ are there to add requirement to source
data information (from which training data can be reconstructed, with
external downloads) and a requirement for practicality of modification
based on an already trained model.
I believe these additional points are required to resolve practical
questions that arise from DFSG requirements, for ability to create
derived works, specifically. And I do not believe it is a good idea to
carve out big DFSG exceptions for this.
Describing how the particular solution must look like and behave in
order to satisfy the original intent of DFSG is IMHO more valuable
than carving out exceptions. (That said, I do believe there should
have been a specific exception formulated for documents that describe
established contracts and protocols (like licenses and Internet
RFCs).)
>From that perspective, I would, personally, even rank option 1) higher
than option 2a) - it is always easier later to relax requirements than
to remove something from the archive.
--
Best regards,
Aigars Mahinovs
