XPost: linux.debian.devel, linux.debian.devel.release
"Chris" == Chris Hofstaedtler <zeha@debian.org> writes:
Chris> brian m. carlson (one of the git upstream copyright holders)
Chris> claims in Bug #1094969 that git cannot be distributed when
Chris> linked with OpenSSL. IIRC the Debian position is to use the
Chris> system library exception.
[This was prematurely sent]
TL;DR: I think that an individual upstream copyright holder's
interpretation should be given less rather than more weight in
interpreting a license.
I think that Debian should adopt a project-wide interpretation of the
system library exception and apply it inconsistently. Allowing the
exception to be interpreted differently on different packages harms our
users and the free software community.
here is a longer proposal on how I would recommend approaching an issue
like this:
1) Debian maintainers have a lot of flexibility. If the Git maintainers
wish to change what they link with, they have that flexibility. I view
this more as "Upstream asked us to ship the software differently and we
decided to disagree." I do not think an NMU has this level of preference.
2) The people involved need to be comfortable with their legal
liability. If Debian were a legal entity this would be easy: we would
ask for legal review and make a decision after receiving it. Such a
decision would typically be made at a fairly high level as to whether a particular issue posed unacceptable legal risk. To the extent that any
party is concerned about their legal liability, please discuss in private--probably by first reaching out to the DPL and asking how to
engage with lawyers. Do not discuss the specifics of the situation
except in private mail (not copying a bug) with the lawyers.
3) Generally, copyright holders trying to interpret a license after the
fact should be given less weight rather than more. After all the
copyright holder could have chosen a different license or published a clarification along with their release. Clearly if it turns out that
the system library exception does apply in this situation, but Git wants
it not to for git-remote-https, then effectly they copyright holders
would be creating a fork of GPL-2 (gpl-2-restrictive-system-library)
that is GPL 2 incompatible.
Allowing copyright holders to do that after the fact--especially when
they selectivly try to enforce that interpretation against some parties
but not others--serves the community poorly.
4) We should interpret the system library exception consistently. If we
believe it allows us to link with openssl, we should stick to that
position.
I think it is cleare that software freedom and our users are served by
letting free software link with Openssl. (I understand some parties
argue that the consequences of interpreting the system library exception
in a manner that permits that linking are worse than the consequences
of avoiding GPL-2 OpenSSL combinations.)
However our position does generally seem to be that we interpret the
system library exception as allowing that linking.
If our interpretation is challenged, we should respond the same way we
would to any other legal challenge to software freedom.
We should seek out people who have aligned interests and try and find
common cause. In this instance I'd definitely suggest the DPL reach out
to Canonical and Redhat.
5) If a license is being interpreted in a manner that discriminates
against Linux distributions--it allows everyone but Linux distributions
to distribute some combination--I think that license discriminates
against a kind of use/field of endeavor. In other words, such a license
would not be DFSG free.
--Sam
-----BEGIN PGP SIGNATURE-----
iHUEARYIAB0WIQSj2jRwbAdKzGY/4uAsbEw8qDeGdAUCZ/0/sgAKCRAsbEw8qDeG dFZFAQCTEMBuKj6WjkCiLk3l2nSlnHfVqtu5DG8eR+G5gDIOOQD/Ur0qRVB5C/Ei NJaqxEt6tvNiurhipE/ST0PAJ9ygIgA=
=pLXN
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)