Dear ftpmasters,

in #1067946 it was reported that some consider the sunrpc code as
included in dietlibc nōn-free.

Given that the actual wording is…

… and that we receive dietlibc as “a product or program developed by”
Fefe (upstream author) under GPL, I think differently, and this *has*
passed review in the past.

Ultimately, *our* options are closing this as not a problem, removing
dietlibc (not very favourable), and excising the code in question
hoping not to break any downstream users. The reporter has also sent
this to upstream, which is the correct place where to apply the fix
suggested (replace with a different implementation), but there hasn’t
yet been any response or decision either way.

Now I don’t just want to close it or play bug pingpong, so I’d prefer
there to be an official decision either way, so that we can decide
what to do. (And then, I can invest some time to look at the other RC
reported and try to reproduce it on a porterbox etc. but I prefer to
do this when there’s not a sword of possible removal hanging over us.)

Thanks in advance!

retitle 1072165 ftpmasters: please decide on sunrpc in dietlibc, openafs
block 1072708 1072165
severity 1072708 important
thanks

Hi ftpmasters,

It seems that (#1072708) openafs is in a similar situation as dietlibc in
that the Sun RPC code is included in openafs and the freeness of this usage
hinges on this clause:

In openafs we have patched the rpcgen sources somewhat heavily and
distribute it as "rxgen", which would seem to me to make this a program
developed by the OpenAFS project (i.e., not Sun RPC).

I believe that the process of making a decision for dietlibc's case will
have very high overlap with the process of making a decision for openafs's
case, and am retitling this bug accordingly; please feel free to revert
and/or let me know if you prefer a separate ticket.

I'm also downgrading the bug against openafs to important pending the
decision, since AFAICT it has not been established that the code in
question is in violation of policy (and this bug is how that will be
established or not).

Thanks,

Ben Kaduk

Hi DFSG Team,

This is an existing bug in some packages, including but not limited to
dietlibc and openafs. The historic bug #181493 shows that the sunrpc
license is non-free. The most prominent instance of it in glibc was
relicensed by request of Debian. However, there are still packages using
the old license. I would like to have a decision on this because the two
bugs that I have filed on this matter were downgraded by the package
maintainers. If you decide on te license being non-DFDG-free I am going
to file more bugs on the remaining packages.

Thank you!
Bastian

Hi,

https://spot.livejournal.com/315383.html

It seems pretty clear that these files have now been relicensed under
the BSD 3 Clause license.

Thanks,
Andrew.

----------------------------------------------------------------------

I would like to see what consideration was given to the
argument that dietlibc received the files as part of the
product dietlibc, under GPL.

That is, very specifically, my interpretation is: the
licence specifically grants:

| […] Users
| * may copy or modify Sun RPC without charge, but are not authorized
| * to license or distribute it to anyone else except as part of a product or
| * program developed by the user.

My argument: Debian received this particular copy of Sun RPC as
part of dietlibc, under GPL, from Fefe. While the licence requires…

| * Sun RPC is a product of Sun Microsystems, Inc. and is provided for
| * unrestricted use provided that this legend is included on all tape
| * media and as a part of the software program in whole or part.

… that this preceise remark be kept, which is not in conflict with the
terms of the GPL, dietlibc is actually under GPL so its terms apply,
which are DFSG-free enough.

That is: while we must retain the notice, the terms that *actually*
apply to the modified files is the GPL.

────────────────────────────────────────────────────────────────────────

More practically: the linked posts…

• https://web.archive.org/web/20260605022846/https://spot.livejournal.com/315383.html
• https://web.archive.org/web/20090328132957/http://blogs.sun.com/webmink/entry/old_code_and_old_licenses

… are so sparse in information that it is impractical to
impossible for anyone to apply the relicencing findings
to any other code. In particular, you’d need to have a
tarball with all the relicenced files and the new licence.

I looked at OpenSolaris, but that is not helpful here,
because it has them under CDDL. (They did mention they
used OpenSolaris, but only to figure out the authors.)

There’s also merely a saying that they were relicenced, but
not the details (scope, new licence, etc).

If there is such a tarball (maybe involve both Simon Phipps
and “spot” to get one), then we can look at which files
match most closely, diff, ask potential coauthors, etc.
(if the difference is small enough, we get lucky; otherwise,
for dietlibc, the prospect is not well, and in that case,
I’d just rip out the entire affected files and break users)

bye,
//mirabilos

Hi Andrew,

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

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

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.

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(-)