Hi Andrew, Thanks for the thoughtful reply.
For clarity, the content in question here is the ~3500 lines of code [0] that have been added to the Sun RPC code since it was imported into OpenAFS. Everyone agrees that the snapshot imported into OpenAFS is covered by the BSD relicensing from 2010, but we are assuming that any changes to those files while they bear a Sun RPC license would have inherited the same license, and thus that OpenAFS must obtain permission from the copyright holders of those additions, in addition to the core Sun RPC code having been relicensed, in order to distribute them as 3-clause BSD. So we seem to be distributing it under the Sun RPC license until that consent is obtained (which, per the previous note, is in progress). Back when Bastian first filed a bug against OpenAFS I did try to make sense of the old discussions on debian-legal but had failed to find something conclusive, especially since the prominent instances of the code ended up relicensing or otherwise sidestepping the issue fairly quickly. (That is, I did not get a clear sense that the discussions actually resolved, rather than being overtaken by events.) Of course, that was quite a while ago and my recollection may be faulty, but at least I now have a clear picture of where you're coming from and what my next steps would be to pursue the topic. Thanks again, Ben [0] $ git diff --stat openafs-ibm-1_0..origin/master src/rxgen [...] 18 files changed, 3627 insertions(+), 3898 deletions(-) On Sat, Sep 12, 2026 at 05:55:50PM +1200, Andrew McMillan wrote: > 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. > ----------------------------------------------------------------------
