On Wednesday, March 11, 2026 6:30:33 PM India Standard Time Ulrich Müller wrote: > >>>>> On Wed, 11 Mar 2026, Michael Orlitzky wrote: > > Setting LICENSE="dubious $LICENSE" would indicate that there is enough > > obvious LLM use that the license cannot be trusted, even if we don't > > have a copy of the victims on our bookshelves to point to. The need > > for every license in $LICENSE to be in $ACCEPT_LICENSE maps this > > nicely onto the UI in my opinion. > > So LICENSE="dubious" would imply mirror and bindist restrictions? > > If we have strong indications that a package violates sombody else's > copyright, then we must not distribute the package at all. At least > not if we want to stay on the safe side, legally. (And I wonder if any > developer would actually add an ebuild for such a package.) > > Otherwise, our LICENSE variable is pretty much based on trust. So if > we've done our due diligence then we list what is provided by upstream. > Because it is (and always was) impossible to trace the origin of every > line of the source code in detail. > > Ulrich While I like these suggestions I would like to suggest also having a license, "LLM-OVERUSE"/"LLM-OVER-RELIANCE" for projects like autobhan which have had a significant loss in quality due over use/reliance on LLMs. This should also help clear up the questions about what qualifies to get the license, for example the Linux kernel would not fall under this as there is currently no overuse/reliance.
Having this split would also make it clearer to end users why a certain license was used at a glance. A one size fits all solution is most likely not the best solution as it obscures reasoning. There is also currently nothing preventing a package from defining multiple licenses at the same time[1]. Luna [1] see www-apps/kibana-bin for an example of a package with a large number of licenses.
signature.asc
Description: This is a digitally signed message part.
