Re: GnuTLS in Debian
Excerpts from Russ Allbery's message of 2013-12-23 16:42:29 -0800:
> Clint Byrum <spamaps@debian.org> writes:
> > Excerpts from Russ Allbery's message of 2013-12-23 10:54:49 -0800:
> >> Clint Byrum <spamaps@debian.org> writes:
>
> >>> An author is not the only party to text. There are also those who have
> >>> received this license, and adhered to it for the sake of the author
> >>> and the copyright holders who have also adhered to it.
>
> >>> So, it is rather disrespectful and could cause harm to those who have
> >>> worked within the confines of the text to at some point ignore the
> >>> text. I'm not suggesting it _will_ cause harm, but it may. In fact,
> >>> RedHat has harmed Debian and enriched themselves by ignoring it.
>
> >> This strikes me as equivalent to a long-distance runner who insists on
> >> running barefoot due to an idiosyncratic understanding of the rules of
> >> the race that isn't shared by anyone else, including the judges, and
> >> then gets upset at the other runners for winning while wearing shoes.
> >> (Analogy intentionally chosen because it is possible to compete and win
> >> in long-distance races barefoot, but most runners don't.)
>
> > This is a really confusing analogy. The runners are the end users of the
> > free software in question, and the GPL is the rules of the race? What is
> > the OpenSSL license then? How are these runners forced to resolve
> > ambiguous licenses exactly?
>
> The runners are the users, such as distributions, and the rules of the
> race are the interpretations of the licenses, including both the GPL and
> OpenSSL licenses. Debian is insisting on running barefoot, and you're
> saying that because Red Hat wears shoes, because no one else believes that
> the rules ban shoes, Red Hat has some sort of unfair advantage.
>
Let's not quibble over analogies. I don't really think it is helpful
still.
> On the contrary, it's Debian's insistence on following an idiosyncratic
> license interpretation that's creating the supposed unfairness. This is
> obviously not Red Hat's fault.
>
To be clear what I am saying is that RedHat has taken a short cut for
their own interests and it is not known to be fair to the authors of
some software.
> >> Red Hat is not responsible for our license interpretations. If the
> >> rest of the world doesn't care, standing by our interpretation looks
> >> less like ethics and more like masochism.
>
> > Adhering to a strict code of ethics is often fairly painful.
>
> So is masochism. That doesn't make masochism a strict code of ethics.
> You have to present some sort of argument that this is actually an ethical
> question, as opposed to just weird literalism, which means making an
> argument that it somehow matters to someone. I've already stated my
> opinion on that position in previous messages.
>
Fair enough, I think it is an ethical conundrum and thus must be dealt
with delicately.
> > If the GPL licensors do not care, then they should be happy to grant an
> > OpenSSL exception.
>
> This is demonstrably false, plus it can pose the same challenge as
> changing the OpenSSL license, for which see below.
>
Demonstrably false in what way? Agreed the challenge is gathering all of
the licensors together to grant the exception.
> > If the OpenSSL licensors do not care, then they should be happy to
> > strike the incompatible requirement from the license.
>
> This is a significant amount of work that they have no meaningful
> incentive to do. Debian refusing to use their software in some situations
> is not any sort of real incentive; Debian just acquires a reputation for
> being weird outliers, and there's no real negative effect for the project.
> The current OpenSSL authors didn't create the license terms. They were
> inherited from the SSLeay project. It's hard to see why they should
> invest significant time and energy and legal resources into this problem
> when Red Hat and many others don't believe the problem exists to a
> significant extent to worry about. They, like most of us, would much
> rather use their resources to write code instead of hire lawyers and
> debate legal issues.
>
This is just one way Debian is different than RedHat and others.
"They're doing it so we should too" didn't work when I was a teenager
and it doesn't really work now. :-P
> It's great that some projects, like Moria and Angband, have done this work
> to get rid of bad licenses, but I'll point out that in those cases the
> license they got rid of was "no commercial use," which is much more
> restrictive and problematic, not to mention less ambiguous. Getting rid
> of the advertising clause is far more borderline, and as Clint points out,
> is routinely violated by the whole free software community with no
> noticable negative effects.
>
I'm not entirely sure that the advertising clause is violated by Debian
or even RedHat. I don't have data though. Seems like it would be fairly
simple for Debian to comply but it might be rather awkward for RedHat to
have to put a little * next to ever mention of SSL in RedHat products
with a subtext from the license.
> That's the other problem with this analysis of ethics: it's not like we're
> complying with every jot and tittle of the licenses of software in the
> archive right now. For example, see Bug#709382 (which I haven't done
> anything about), or the numerous examples of packages where we don't
> maintain a complete GPL-compliant log of changes. Rather, we make a huge
> deal about, and go through extensive contortions over, *some* license
> issues, like OpenSSL, while completely ignoring other ones that are harder
> to check and verify. This is, in part, because applying that consistently
> tight level of license compliance across *every* license requirement would
> be paralyzing for anyone attempting to produce a Linux distribution. It's
> just not feasible; there are too many weird corners of licenses with odd
> implications that, in practice, everyone just ignores. The audit effort
> required would be immense.
>
"We're compromising our ethics elsewhere so why not also accept
compromising them more here?"
AFAIK, we respond promptly to bug reports from licensors. For the bug
mentioned, I think we are acting in good faith by providing the sources
of the build-depends even if there is a bit of version skew. I understand
you're arguing that we would be acting in good faith by declaring libssl a
system library. I am not so sure, but thus far I don't think any consensus
has been reached on that.
> In this specific case, I believe we are taking an expansive interpretation
> of the spirit of these licenses that is almost never shared by the people
> who actually chose those licenses, as demonstrated by the reactions of
> upstreams on those projects when pestered about this supposed issue.
>
And what about those upstreams that do actually care?
> I'm sure we could find some GPL-only upstream out there somewhere who
> replies with "yes, I really don't want my code used with OpenSSL," just
> like we ran into the University of Washington and their bizarre
> interpretation of the MIT license. But we could deal with those as
> individual cases, like we did with Pine and XFree86. By far the most
> common reactions I've seen have been either "oh, sure, I'll add this
> exception" because they never objected to this in the first place or
> (sadly common), "Why are you bothering me with nonsensical legal bullshit?
> If I didn't want the software to be used with OpenSSL, I wouldn't have
> added OpenSSL support. Go away and bother someone else."
>
"I wouldn't have added OpenSSL support" does not necessarily reflect the
position of all of the copyright holders of the licensed work. It is
entirely possible, even likely, that code gets merged into a project
without the consent of all copyright holders. That doesn't mean that one
can or should violate the license.
Reply to: