-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 On Wed, 7 May 2025, Simon Josefsson wrote:
>I'll second this option. I think it describes an internally consistent >policy and give clear practical recommendations. Thank you. I’ve been made aware-ish of a few questions regarding this via LWN. The most important one is that this should of course only apply after the release of course, we don’t want to change things while preparing a release. We could even give already-existing packages that predate the current craze a long grace period (like backgammon). And geofft wrote: | (if I'm reading right) Thorsten's proposal allows a DFSG-free AI with | redistributable but DFSG-incompatible training data to go into contrib | with its training data packaged up in non-free That was not my intention, and please help me clean up the wording if others read it as that as well. In my eyes, there is not such a thing as “a DFSG-free AI with DFSG-incompatible training data”, as the model includes (lossily compressed) the training data. Not sure how geofft came up with this interpretation (especially as I specifically wrote that I think models in contrib should only be allowed non-free runtime dependencies, such as special GPU drivers, but not compile dependencies — though contrib is probably the least interesting area for this?). >> 2 Models are not suitable for the non-free-firmware archive. > >I think this will be difficult to enforce. We have no idea what's in >the non-free-firmware blobs, nor is there any reliable way for us to >ever gain that, and it seems likely that LLM models will end up inside >non-free firmware blobs if they haven't already. … oh! That’s a way to look at this I haven’t considered yet. >How about removing that paragraph and replace 'non-free' with >'non-free(-firmware)' in the rest of your proposal? Not sure this is the right fix. What I wanted to say is: models are, while data, run on the main system (CPU) or as main workload (this part is important) on adjacent chips (GPU, specific ASIC/FPGA); models are not a firmware in the sense of enabling the use of such hardware and therefore not for non-free-firmware. So, in that direction: models we’d have packaged as models, used by ordinary packages on the system, driven by the user (or an automatism on their behalf). The other direction, if there’s non-free-firmware that *also* includes models: yes, we cannot control that, and I’d be fine with that as long as these models are ⓐ a part of the firmware in question (and not pak‐ kaged separately) as well as ⓑ not available/used by packages in main (or contrib) for purposes beyond how the firmware itself, running on its separate chip, uses them. Is this clear? Is this a good idea? Can someone suggest wording? I’m unfamiliar with the formal procedures needed in the GR process, do we need to do anything other than to post and have seconded the updated wording, and in which timeframe? Thanks, //mirabilos - -- 15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-) -----BEGIN PGP SIGNATURE----- iQIcBAEBCQAGBQJoG+NfAAoJEHa1NLLpkAfgLMAQAIpc/1mPHov4VNpCHJfja/yo 8Nk4mjCjiphihLUp6cgx/+RiNrGfQpbUEzZZbGkt2A/aH7hv6mWNO7J+vT6G4nZh Kp+BPBGln2tWXLJ/CAifGBpvDxmOQiz9DRjRUvh653FL/20Oc9nQuS/WpGLJuEBR iwjlnYH/1AWBAio4hhT99RzaEU7LbF6+xx11L0I6mMnSYcy+G9m4cHA4Jjwbc0yO q+ZZh3/CUPj7uPKybibwitUS1sElBNBuKF0S5UXECwjV3k08FMam93ZRiUJI9yfj bHtUex2QUpnfNPu1z3iwvxeTQPNzO72cIIstBKWfaVtAuCBckibyQ43mDbV0wUKX hD7S1BohQ+1TuQrsHarwxq0PsnctjNYCiAY8U9dJZegsTnilkzAJ50CwIDUfhSny GII4sMt+DFViw+7j8nFVJLSX06in5DukngShyY+ExxcfAmny0oOqiTPaC+1UV41f 03BvX7c5yH40Zg7CERA52FDRL8w4oxU46orlciYx26nj4/tKvCzTr2q8cULamkFM DPaPanMwxHzJbNKeR77w96ntmSBQdXm/4wRQsT+qqeWK75vfwZwX849zLuGSr+jg KVb/bbmJrCZw1h68iX/OHd3sDZs/sZIFdilB3CiTT1mHAfmKbuwtAAbTy2N1oNdk Xdtzmwz90gH3T2WfO8/m =97mT -----END PGP SIGNATURE-----
