Re: GnuTLS in Debian
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.
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.
>> 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.
> 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.
> 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.
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.
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.
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.
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."
Has anyone asked the Git maintainers whether they object to their software
being linked with a libcurl that uses OpenSSL? What did they say?
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: