Hi Andrew, > In that case you will need to do the case-by-case review of those > files. If the old license still applies it is clearly not DFSG-free.
While I recognize that as part of the DFSG team you make determinations of what is or is not DFSG-free, could you perhaps expound a bit more or provide a reference for why this is "clearly" not DFSG-free? In particular, why no further case-by-case analysis is needed to determine whether the "except as part of a product or program developed by the user" clause is not relevant? In OpenAFS, the original Sun code has been modified quite heavily for a different purpose, such that (IMHO) even when just the code under the Sun license is excised from the OpenAFS source code tree it remains OpenAFS-specific rather than a general-purpose RPC-handling code, and thus could plausibly retain its nature as "a product developed by the user". So, with the data I have at hand, I find it "plausible" that the old license in this case is DFSG-non-free, I myself cannot say that it is "clearly" non-free, hence the request for additional information from the domain expert. And while I'm here, for Bastian >> use of a relicensed version. For openafs this is not possible as-is >> because they have non-trivial changes which are under the old >> license. And both Debian packages where this bug was filed do not >> want to put in the work without a decision whether the license is >> non-DFSG-free. That does not seem like an accurate characterization of OpenAFS's position, see, e.g., https://www.openafs.org/relicense/relicensing-openafs.html and the 07-July-2026 "Recent OpenAFS News" entry at https://www.openafs.org/ . In a word, the work is already happening. Thanks, Ben
