Hi Fabio, Fabio Natali <[email protected]> skribis:
>> The leading commercial genAI services run non-free software, are a threat to >> user privacy, and achieve a concentration of power over the lives of people >> rarely seen before. > > Does "running non-free software" here refer to training models or to > offering Generative AI services? Both. It’s the same reason why many free software projects prefer Codeberg over GitHub for instance: both are services but in one case the software behind it is free. > Furthermore, would this argument be a reason to ban Generative > AI-based contributions in Guix, to avoid packaging Generative AI > tools, or to avoid packaging projects that have been developed using > Generative AI? IMO this argument alone, no. > What about using LLMs that do not come from leading commercial > services? Assuming local models could be used on off-the-shelf hardware for similar functionality, this particular argument would no longer hold. Other questions would remain open: risk of plagiarizing the input data, licensing of the output, cognitive debt buildup, loss of autonomy. [...] >> At the time of writing, only proposed interpretations of copyright law >> exist: that depending on the level of human intervention, genAI output could >> be considered not copyrightable... > > The legal concern would be a basis to (possibly temporarily) reject > Generative AI contributions, but I am not sure it could justify > refusing to package Generative AI tools and projects developed using > Generative AI. The copyright situation of fully vide-coded works is currently unclear. In that sense, for the purposes of package inclusion criteria, they can be treated as non-free software—and thus excluded. You’re right though: this is still being debated and may change in the future. > Separately, while I see potential Intellectual Property concerns when > it comes to core parts of Guix, I wonder how significant the IP risk > would be for more formulaic contributions such as (simple) package > definitions and package updates. Good point: simple package definitions are arguably often not subject to copyright because they are not a “creative work”, which is what copyright applies to (some are generated by ‘guix import’, making the lack of creativity obvious). More complex package definitions (with ‘arguments’, special phases, patches, etc.) as well as package sets (picking version combination, optional dependencies, etc., for instance as is done for Python upgrades) are arguably copyrightable. To summarize, there is no reason to worry about the provenance of simple package definitions/updates from a copyright perspective. >From a technical perspective, these simple package definitions/updates are also those that our tools can produce in a deterministic, transparent, and accurate way. Thanks for commenting, Ludo’.
