Hi Ben, It seems clear from the page you link, that the SunRPC code in OpenAFS is a part of the relicensing to BSD 3 Clause in 2010.
Bastian, on the other hand, was explicitly saying that he is concerned about code that was not relicensed. I don't know what that code is and I'm not going to try and arrange for any relicensing - that is the responsibility of the package maintainers. I also don't want to relitigate the exact wording of the sunrpc license and it's "restrictions on distribution" and suddenly decide that it's OK after so many years of both Debian and Red Hat saying otherwise. If you want to start a discussion on the exact terms of the license on debian-legal and can persuade them over there that we should just accept it, then I'm fine with that too. While I think it is OK for the DFSG Team to be some kind of a "tie breaker" in the event that the people who love to discuss this kind of thing over on debian-legal, I think they usually have excellent opinions, and their discussions are a worthwhile read. No doubt somewhere back in the ancient archives there is such a discussion about this ancient license. FWIW I am also fine with Thorsten's proposal (that these files were received from dietlibc) and should be listed as GPL in debian/copyright with an appropriate explanatory notice included. Cheers, Andrew. On Fri, 2026-09-11 at 21:54 -0700, Benjamin Kaduk wrote: > 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 -- ---------------------------------------------------------------------- Porirua, New Zealand +64 (27) 288 6741 https://andrew.mcmillan.net.nz Life is a sexually transmitted disease with 100% mortality. ----------------------------------------------------------------------
