Re: System libraries and the GPLv2
On Thu, Mar 30, 2017 at 11:37:32PM +0200, Francesco Poli wrote: > On Wed, 29 Mar 2017 23:28:46 -0400 Richard Fontana wrote: > > > On Thu, Mar 30, 2017 at 05:08:24AM +0200, Carlos Alberto Lopez Perez wrote: > > > > > Do you (or anyone else) _really_ think the copyright holders of the GPL > > > program in question had any intention ever of not allowing their program > > > to be used along with OpenSSL, when they where the ones implementing > > > support for using it on the first place? > > > > This, I would say, encapsulates the real Fedora/Red Hat position on > > this issue to the extent there is one. It assumes that the intent of > > the copyright holders can be determined from their actions. > > What about programs that link both with OpenSSL and with a > third party purely-GPL-licensed library? I don't think that would change anything, but maybe I'm overlooking something. RF
Re: System libraries and the GPLv2
On Thu, Mar 30, 2017 at 10:27:46AM +0200, Florian Weimer wrote: > On the other hand, when a larger upstream project > granted us a linking exception for OpenSSL, they probably did not > obtain consent from all the copyright holders, either. Right. For example, I remember one case where a Debian developer contacted Red Hat to ask that Red Hat include an explicit OpenSSL linking exception, for some GPL-licensed project maintained by Red Hat. They did not inquire into the actual state of copyright ownership of the GPL code in question or attempt to identify and contact individual copyright owners AFAIK. It just shows you that everyone is making simplifying assumptions. > What really annoys me about this whole situation is this: I think no > one presently argues that the GPLv2 prevents people from distributing > pre-built binaries for proprietary operating systems. I can take > Hotspot (a component of OpenJDK which is GPLv2-only), compile it with > Microsoft Visual Studio, and distribute the result. But I suddenly > can't ship pre-built binaries, as a free software distribution, > because I happen to have upgraded the system compiler past GCC 4.2, > thus got the new GPLv3+ license for libgcc, and can't link GPLv2-only > Hotspot against that anymore. This can't be right, can it? One of the general approaches I take to GPL and LGPL interpretation is that, in cases of textual ambiguity, results that are absurd from a policy perspective (for example, interpretations that privilege proprietary software over free software) should normally be treated as incorrect. Richard
Re: System libraries and the GPLv2
On Thu, Mar 30, 2017 at 05:08:24AM +0200, Carlos Alberto Lopez Perez wrote: > Do you (or anyone else) _really_ think the copyright holders of the GPL > program in question had any intention ever of not allowing their program > to be used along with OpenSSL, when they where the ones implementing > support for using it on the first place? This, I would say, encapsulates the real Fedora/Red Hat position on this issue to the extent there is one. It assumes that the intent of the copyright holders can be determined from their actions. Richard
Re: System libraries and the GPLv2
On Thu, Mar 30, 2017 at 02:49:04AM +0200, Carlos Alberto Lopez Perez wrote: > However, I still don't understand why we don't just declare OpenSSL a > system library; or at least define a clear policy for when a package is > considered part of the base system (so the GPL system exception applies > to it). > > RedHat did this (see me previous (by date) mail on this thread), and > they didn't had any problem in this regard (AFAIK). The "Red Hat did this" part is not accurate. I addressed this in a talk I gave in 2014 - see https://www.youtube.com/watch?v=MZ_AKFkDWFc&feature=youtu.be&t=1672 (through about 29:40) Richard
Re: AGPLv3 Compliance and Debian Users
On Thu, Jul 11, 2013 at 08:27:31AM -0700, Clint Byrum wrote: > Excerpts from Richard Fontana's message of 2013-07-11 06:55:12 -0700: > > On Thu, Jul 11, 2013 at 03:12:39PM +0200, Ansgar Burchardt wrote: > > > > I'm no expert but that would be my interpretation. Also when I asked > > > > about the basis of the network part of the AGPL during the GPLv3 talk > > > > at DebConf10 in NYC, Bradley said the AGPL was specifically based on > > > > modification, _not_ on public performance or other use. > > > > > > You have to make the source available in this case. Otherwise it would > > > be a trivial way around the AGPL (just have a third party modify the > > > program and give it to you). > > > > Co-author of AGPLv3 here, including the section at issue. You do not > > have to make the source available in this case, in general. In unusual > > cases of circumvention, like what I believe you are suggesting, the > > answer might arguably be different, but in the context of ordinary > > Linux distributions, when a user gets AGPLv3-licensed software that > > the *distro* has modified, that software is *unmodified* from the > > standpoint of that user downstream from the distro and therefore the > > user needs to do something to trigger the section 13 requirement. > > > > Otherwise you have to explain why modification was made to be the > > trigger. If the modified/unmodified distinction was meant to be > > meaningless, section 13 would have been drafted not to make any > > reference to modification. Indeed, other Affero-like licenses > > typically are broader than AGPLv3 in the sense that they work by > > redefinition of 'distribution' and thus are not limited to cases where > > the user has modified the software. This approach was specifically > > rejected when AGPLv3 was being drafted. > > > > So are you suggesting that the AGPL's protections against commercial > takeover are basically moot? No. The main problem I have been seeing is in the opposite direction: overbroad interpretations of AGPLv3, one of the reasons I am chiming in here. It is the tendency to overbreadth that is tragic. > How would the AGPL be applied in this > scenario: > > Company A starts a business based on unmodified MediaGoblin. They hire > a firm, Consultants-R-Us, to manage their MediaGoblin code base and > develop a new new video encoder. > > Their contract with Consultants-R-Us keeps ownership of all code in > Consultants-R-Us name, and C-R-U simply gives a tarball to Company A > which they then use to serve users. > > Can we honestly say that Company A modified the software? Possibly, in that case -- but that's entirely different from the distro packaging scenario. > If not, then > what is the point of the AGPL? To protect C-R-U? > > I am not suggesting that this is absolutely not modification by Company A. > However, to a non-lawyer like me, it sure _looks_ like a big hole. Just a general comment which I think is important to say: The GPL/AGPL licenses were not designed to be guaranteed to eliminate all possible creative loopholes. They *can't*. I don't recall anyone raising your hypothetical during the (relatively quiet) drafting of AGPLv3 but for GPLv3, although the specifics elude me at the moment, I recall many people, usually developers or technical users, having raised parade-of-horribles hypotheticals that belonged to this general category (essentially, a kind of conspiracy in a licensing chain to evade the requirements of the license, often by splitting 'you' into more than one licensee). The FSF's view was essentially that reasonable legal systems would likely treat such things as copyright infringement, without the license text having to spell it out. I think this was consistent with some of what the FSF had said in the past regarding interpretation of GPLv2. - RF -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130711174500.ga22...@redhat.com
Re: AGPLv3 Compliance and Debian Users
On Thu, Jul 11, 2013 at 03:12:39PM +0200, Ansgar Burchardt wrote:
> > I'm no expert but that would be my interpretation. Also when I asked
> > about the basis of the network part of the AGPL during the GPLv3 talk
> > at DebConf10 in NYC, Bradley said the AGPL was specifically based on
> > modification, _not_ on public performance or other use.
>
> You have to make the source available in this case. Otherwise it would
> be a trivial way around the AGPL (just have a third party modify the
> program and give it to you).
Co-author of AGPLv3 here, including the section at issue. You do not
have to make the source available in this case, in general. In unusual
cases of circumvention, like what I believe you are suggesting, the
answer might arguably be different, but in the context of ordinary
Linux distributions, when a user gets AGPLv3-licensed software that
the *distro* has modified, that software is *unmodified* from the
standpoint of that user downstream from the distro and therefore the
user needs to do something to trigger the section 13 requirement.
Otherwise you have to explain why modification was made to be the
trigger. If the modified/unmodified distinction was meant to be
meaningless, section 13 would have been drafted not to make any
reference to modification. Indeed, other Affero-like licenses
typically are broader than AGPLv3 in the sense that they work by
redefinition of 'distribution' and thus are not limited to cases where
the user has modified the software. This approach was specifically
rejected when AGPLv3 was being drafted.
> Section 13 (Remote Network Interaction) requires modified version to
> offer access to the source. If you modify the software, but do not
> provide this, you violate this license requirement and lose the right to
> modify and distribute the covered work under section 8 (Termination).
>
> And with open source software you often deal with "modified" versions,
> so claiming this is a special case ("[...] was specifically based on
> modification, _not_ on public performance or other use") seems a bit odd
> to me.
That's another issue, what does it take for the software to be
'modified' for purposes of that section, and you rightly call
attention to it. But to say that the package *as received from the
distro* triggers section 13 *inherently* is inconsistent with the
language of section 13 and the intent of the drafters.
- RF
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130711135511.ga19...@redhat.com
Re: Berkeley DB 6.0 license change to AGPLv3
On Tue, Jul 02, 2013 at 06:20:48PM +0200, Ondřej Surý wrote: > I don't believe I have spread any FUD. > [...] > 2. AGPLv3 is incompatible with Apache 2.0 license (http://www.apache.org/ > licenses/GPL-compatibility.html) Only in the same sense that GPL or LGPL (any version) is incompatible with any noncopyleft license in the copyleft-to-permissive direction. The Apache License 2.0 is compatible with AGPLv3 in the other direction. - RF -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130702170356.ga16...@redhat.com
