git-remote-http is linked against incompatibly licensed OpenSSL
26 points by runxiyu
26 points by runxiyu
OpenSSL is under the Apache License 2.0, which is, despite everyone’s best intentions, not actually compatible with the GNU General Public License version 2, and thus the Git binary is not actually distributable.
I feel like “best intentions” is doing a lot of work in that assessment. This aspect of the GPL always feels like a ridiculous posture. To the extent that it’s sensible to care about the difference between dynamically linking to a program (apparently bad!) and using posix_spawn(2) to run said program (apparently good!), it seems especially frivolous that the code being taken advantage of here is apparently in the library being used, not in the actual GPL work. It would make more sense to complain about this sort of thing if someone was making use of the GPL code itself in this way.
I take every opportunity (and I bet you do too) to complain about the related issue of Linux packagers mostly deciding that ZFS can’t be part of their Linux distribution even though the CDDL is so similar in intent to the GPL. With friends like that, who needs enemies?
CDDL’s intent was to be GPL-incompatible. It’s a relatively well documented fact that Sun based the CDDL on the MPL v1 with the explicit intention to make it unsuitable for GPL software (meaning Linux). See: https://en.wikipedia.org/wiki/Common_Development_and_Distribution_License#GPL_compatibility
CDDL’s intent was to be GPL-incompatible. It’s a relatively well documented fact that Sun based the CDDL on the MPL v1 with the explicit intention to make it unsuitable for GPL software (meaning Linux)
That’s not well documented at all. One person claims that, while pretty much everyone else who was involved disagrees.
And frankly, being incompatible with the GPL regardless of how closely aligned your goals are is just how the GPL works. Every copyleft license that’s compatible with the GPL is only so because it has a clause that essentially boils down to “in some circumstances, you’re allowed to ignore the terms of this license and just treat it as GPL licensed instead”. If you make a license that is almost identical to the GPL but don’t include such a clause, your license is not GPL compatible. So I’m always going to blame the FSF, not the authors of other licenses.
I’ll blame the FSF for licenses which are well-intentioned but accidentally GPL-incompatible, such as the MPL 1.1. I will blame the author of a license when the license is intentionally GPL-incompatible.
I think it’s ridiculous that the GPL should be allowed to be absolute and inviolable, but other licenses must bend their terms to suit the GPL. Copyleft licenses can be compatible without special provisions. A code base with MPLv2 (without the secondary licenses clause), CDDL, and EUPL code would work just fine without any special tricks, even though they’re all copyleft and impose different requirements. The GPL is just so hostile and overzealous in its virality that it cannot coexist with other reasonable copyleft licenses.
The sole exception to this the AGPL, because the GPLv3 has a special exception for that. Actually, since the AGPL obviously isn’t a FOSS license due to violating freedom 1, I guess the GPLv3 doesn’t count as copyleft as it allows you to launder FOSS into non-FOSS.
The AGPL does not violate any freedoms. The service provider is not the user and is therefore not entitled to user freedoms. In fact, it is often the desire of service providers to deny their users freedom 0 and 1: “The freedom to run the program as you wish, for any purpose” and “The freedom to study how the program works, and change it so it does your computing as you wish”. The goal of SaaSS is to prevent you from running the software on your own terms and to prevent you from being able to study the software at all, not even in the form of an obfuscated binary. The AGPL does a better job at protecting these freedoms in a SaaSS setting, which is why service providers who aim to deny their users these freedoms despise it.
The service provider is not the user and is therefore not entitled to user freedoms.
But the AGPL doesn’t actually directly impact the service provider at all, it impacts anyone who edits the source code. For example, let’s say Alpine Linux needs to apply a patch to a piece of AGPL software to make it work with musl libc. Now they need to make their patch also change the software in such a way that the source code offer displayed when running the app points to the code. How long after they distribute that patched package do they have to continue to keep that source code download link valid? The license doesn’t specify, so like, is it forever?
If the license put a restriction on the party providing the service, it’d be easy, they’d just have to keep the source link valid for as long as they continue to provide the service. But the license wants the party that did the modification to provide the hosting for the source code, so it’s very unclear.
This seems like an onerous requirement for mere modification.
The GPL was founded upon this rock: you shall not pass on to others less freedom than you yourself received.
Nothing could be simpler or more moral. Nothing could be more respecting of freedom. For years – decades! – the noble freedom-loving defenders of freedom fought back the hordes who would compromise this. There can be no compromise with enemies of freedom.
But then, those who styled themselves defenders of freedom revealed the truth about themselves, and published a new version of the GPL which declared: you can pass on to others less freedom than you yourself received. And then they endorsed it, and endorsed its use alongside another new license which required you, when combining with GPL software, to pass on less freedom than you yourself had received from the authors of the GPL software.
They now are fallen. Corrupt. They are become what they crusaded against. And you have joined with their forces. You, who despise freedom, you who hate freedom, you who received freedom with one hand and celebrated the destruction of it with the other. I alone stand against you, but I am enough. I, the lone defender of freedom remaining in a world now crawling with traitorous vermin. I, who stand for freedom and REFUSE to compromise, as you have. I, who REFUSE to attack freedom, as you have. I, who am free. Unlike you, who have sold the sacred heritage of freedom you received and entered willingly into bondage and chains unending.
I am the most dangerous man alive, and you and all other enemies of freedom will hunt me to the ends of the world to destroy me and to destroy that freedom which I possess and for which I stand. But the gates of your hell shall not prevail. I am the most dangerous man alive, because your hateful crusade against freedom cannot stop me, a free man. I will see your crusade, and you, fall.
I didn’t mean “in intent” (although that is exactly what I said! Sorry!). I meant that it’s copyleft and so now that Oracle is happy with anybody using ZFS and OpenZFS is in the wild it’s ridiculous that Linux distributions have to have any hesitation in packaging it.
the difference between dynamically linking to a program (apparently bad!) and using posix_spawn(2) to run said program (apparently good!)
The significant difference is that dynamic linkage implies multiple entry points and binary parameters, while posix_spawn() runs a program with text parameters passed on the commandline and in the shell/environment variables.
I’m not inclined to defend Debian’s love of nitpicking, but that seems like a reasonable place to draw a line.
If it’s okay to posix_spawn a child and use JSON-RPC to communicate with it, but not okay to dlopen a library and call functions it exposes, then you have written a very strange license that somehow encodes the C/UNIX linkage model in legalese.
Even languages that are close to C have problems. We had all sorts of fun with GNUstep being LGPL’d because Objective-C has run-time reflection. You can, in a program, write an Objective-C category that replaces a bunch of methods in an object that comes from a library that you’ve dynamically linked. If that program is proprietary, but still allows you to replace the GNUstep .so files, is that a violation of the LGPL?
This kind of thing is why I avoid FSF licenses wherever possible. Even the FSF’s lawyers were not able to give a GNU project a self-consistent answer to what their license actually meant.
Although I usually accept whatever the FSF says when it comes to the GPL, I don’t necessarily agree about this. I see little difference between binary 1 50 13 < blob.something and function(1, 50, 13, &something_blob) when dynamically linked, especially when you are providing your own headers (see also Google v. Oracle for some (not that well-explained imo) reasoning on why using “declaring code” may be considered fair use).
I see little difference between…
That’s because you’re a programmer who has a C compiler installed, and you know how to use it.
Users experience the difference because they can’t write C, often don’t have a compiler installed, and if they did they wouldn’t necessarily know how to use it to change that 50 into something else.
I can guarantee a Judge would understand the difference too.
So it’s needing a C compiler that makes it different? What about a Python interpreter? If the text sent to the binary is a Python or Lua program, does that count as a GPL boundary? What about if the text is a JSON-RPC serialisation? What if I create a program that just does dlopen on a program and exports all of its functions as JSON-RPC calls?
If I have an Objective-C class that’s GPL’d and I link the shared library, does that trigger the GPL? What happens if I load it into a program and expose it via Distributed Objects, does that trigger the same thing?
Please point to specific text in the GPL and relevant case law for your answers.
IANAL, but AFAIK: A work that incorporates another work derives from that other work; distributing statically linked binaries does precisely that, and causes a derivative work to be created. This is generally not done in dynamic linking other than header files which seems to fall into fair use as stated in Google. Never have I seen precedents to support the claim that ease of use is relevant in determining whether a derivative work is created. Also apologies for this somewhat C and U.S. centric perspective.
Breyer didn’t make an opinion about dynamic linking or header files, but about Java APIs, and whether copying the interface is fair-use.
That’s not what’s going on here: Debian’s libcurl links to libgnutls which links to libldap which links to openssl instead of libgnutls or libnss.
I am using the Court’s opinion to support my claim that header files in general (e.g. perhaps excluding complex macros or extern inline functions), as “declarative code” (see Google LLC v. Oracle America, Inc., 593 U.S. 1, 10 (2021)), may fall under fair use, since header files serve as a declaration for the interface.
This is part of a discussion on whether dynamic linking creates derivative works. It is relevant because while dynamic linking generally does not incorporate “implementing code” from the library to the main program, it does incorporate headers, which generally contains declarative code.
Though this is indeed slightly tangential from the discussion on Debian’s situation at hand.
To the extent that it’s sensible to care about the difference between dynamically linking…
It is different, because users can run programs, programs that are useful by themselves, but are not expected to write new C libraries and interface with the dynamic linker in order to use a library, which is of no use to anyone except the developers who wanted to ship their software.
Judges aren’t stupid: They absolutely understand the difference.
especially frivolous that the code being taken advantage of here is apparently in the library being used, not in the actual GPL work
That’s not what frivolous means. https://www.law.cornell.edu/wex/frivolous
It would make more sense to complain about this sort of thing if someone was making use of the GPL code itself in this way
It would make more sense to just link libldap with gnutls or libnss. OpenSSL is trash software anyway.
It is different, because users can run programs, programs that are useful by themselves, but are not expected to write new C libraries and interface with the dynamic linker in order to use a library, which is of no use to anyone except the developers who wanted to ship their software.
Saying that the user can run binaries directly, seems to bear no relevance when comparing the copyright implications of dynamic linking vs spawning processes, when the caller/spawner does so programmatically without user request. I am not sure I understand your argument.
It is different, because users can run programs, programs that are useful by themselves, but are not expected to write new C libraries and interface with the dynamic linker in order to use a library, which is of no use to anyone except the developers who wanted to ship their software.
This is just a different calling convention, though. One could easily write a shell that called C functions via FFI instead of calling into ELF executables via fork/exec. Indeed, bash has a limited facility for doing exactly this: it can load and execute new shell builtins from shared libraries.
Judges aren’t stupid: They absolutely understand the difference.
I am familiar with exactly one US judge who I am confident has taken software issues seriously enough to educate themselves and make sound decisions, and he was overruled on appeal by hacks in another jurisdiction.
That’s not what frivolous means
It absolutely is what the English word frivolous means. This isn’t a court room, and I’m not using a legal term.
OpenSSL is trash software anyway.
I’ve seen a few posts here against OpenSSL — could anyone explain why?
I can’t speak for everyone, but I tend to avoid it as much as I can in all of my Rust projects because it’s a royal pain to get to build and link properly during development, especially for binaries which would otherwise be (mostly) static (and statically linking OpenSSL is not fun either IIRC) and then to try and deploy that binary on various distros with different version requirements. it’s also been kind of… not great security-wise for a long time AFAIK, there’s CVEs published fairly regularly for it, and then there’s things like OpenSSL taking years to ship QUIC support only to use a different API than everyone else for seemingly no good reason. there’s probably other reasons I’m not privy to as well, but yeah, not exactly a library a lot of people have faith in for one reason or another.
This used to be a lot worse before OpenSSL 3 relicensing it from the funny OpenSSL license to Apache 2.0…
Also, it feels weird to do this over transitive dependencies. If git was linked directly against OpenSSL, then maybe, but having a build of libcurl with a reasonable feature set enabled and the alleged violation happen two recursive dependencies deep doesn’t intuitively feel right. And of course, because Linux distributions treat the OS like it’s all the same thing rather than have any sort of system base layer…
(I am confused by the execution path presented in the bug tracker so I’ll just split it up here)
My intuition is that GPL requirements do spread when the use of Git calls into OpenSSL indirectly.
But if Git is merely linked to cURL which is linked to OpenSSL, but the usage of Git never calls OpenSSL routines (which I do not believe to be the case here?),
If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.
I would probably consider Git and OpenSSL to be reasonably separate and independent if OpenSSL is merely linked by the loader and is never called during the usage of Git. The language in the license here is fuzzy and difficult to interpret, imo.
Also, I am not sure where the boundary of “separate works” lie. I would consider packages to be a reasonable boundary between them, although this is very much up to interpretation.
As people mentioned in the thread, I don’t understand why Debian’s position of the system library exception w/r to OpenSSL would not apply here. Which is also the same position that Fedora and other distros have.
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
Emphasis added; I think Debian, as a distribution, distributes the component (OpenSSL) itself that accompanies the executable (Git).
In the distant past, Sun used to put the GPL crud on a second CD (I think called the “open source companion disc”) from the regular Solaris bits. In 2025 we don’t really ship people CDs or tapes anymore, it’s all just blobs/images and files and so on.
I think it would be just as reasonable to say files only “accompany” one another if they are in the same package. It seems extremely likely that any base Debian system is going to have OpenSSL installed in such a way that you can’t remove it. The question of what repository it’s in doesn’t seem particularly material – but if it is material, could one “solve” this by just having a second apt repository for packages with intransigent licences?
Apt depends on openssl now I think. You definitely cannot remove it (well, maybe you could for apt but you’d lose the ability to use https sources at least). You don’t need to have git installed on the other hand and I’m sure you’ll find minimal isos without it.
I think the best answer I’ve read in the thread is Timo’s in #89 after Chris noticed that upstream’s configure default to linking against openssl:
Let’s assume for the sake of the argument that your interpretation is correct.
Then help me make sense of this. You are not objecting against linking with OpenSSL on principle but on a technicality: we are creating the very same distro package that literally anyone except us is supposedly allowed to link against with Git.
So why does upstream not grant the OpenSSL linking exception, which is one common way to deal with this issue? Surely the discrimination against Linux distributions is not the desired outcome but merely an artifact?
Apt depends on openssl now I think. You definitely cannot remove it
Yeah, I realise now, unfortunately, my phone completed the wrong word and reversed my position! I agree it seems vanishingly unlikely that you can uninstall OpenSSL usefully on a Debian system.
And, yes, that answer reflects the patent absurdity of this aspect of the GPL. I watched a talk by Linus some time in the last few years, where he was trying to explain why he had picked the GPL at the time: it was because he wanted people to give back their changes to the source, and that’s it. All the navel gazing about whether linking in different ways, or putting things on the same distribution tape or on different tapes, and how that all impacts whether a work is “derived” or not, is such a monumental waste of human life. Most of my software work is licenced under either the CDDL or the MPLv2, which are ultimately similar: you give back changes on any files you modify, but with no nebulous claims to how larger works are made. The file is the licence boundary. This enables open source projects to work together to grow the commons: we can exchange code with, say, FreeBSD, which is why they have no problem shipping and benefiting from ZFS and DTrace and whatever else.
I find
the file is the license boundary
to be rather arbitrary. It is entirely possible to use things like GNU_IFUNC, macros, special build systems, or perhaps monkeypatching in languages like Python, to effectively do the same thing as would naturally be done by modifying one file without touching that file.
That said, my familiarity with MPL only spans from very rough readings when I didn’t even know how to use a computer properly, so take that with a grain of salt.
I’ve never felt like that part of the GPL fully made sense except in the early years. IIUC, it was a way to enable GPL software on proprietary operating systems which were the norm. Of course, it still applies to a number of OSes nowadays but the situation has changed. Right now this may hamper Debian more than Windows where git could (indirectly) link against windows’s schannel freely. This doesn’t make sense and an update is warranted imho.
I understand the FSF’s position to not compromise in order to avoid introducing loopholes but that constraint is really a pain and just makes thinking about completely changing license.
All the navel gazing about whether linking in different ways, or putting things on the same distribution tape or on different tapes, and how that all impacts whether a work is “derived” or not, is such a monumental waste of human life.
When you get a properly licensed copyleft software, you are guaranteed that you have all freedoms and you will be able to study or change any aspect of this software. You are guaranteed that it is not just a masquerade, just a thin layer of useless „free“ code that depends on proprietary software that actually provides all the functionality you are using.
It allows one exception – its purpose is to allow adapting that free software so it can run also on various non-free operating systems. However the idea behind it is that you can (or will be in future) able to run such software completely free, including the free operating system (and ideally also free BIOS or other firmware). This expects that the interface to non-free components is optional (these non-free components are optional, not essential for given program) and needed only to run that program in this non-free environment; or it is kind of abstract standard interface that has (or will have in foreseeable future) multiple implementations including free ones.
So it is not „You can depend on any non-free components (that actually voids the freedom) and just comply with some random ridiculous rules“. It is „You can depend only on free software components that guarantees the same level of freedom for whole program. And there is also a little exception that softens this rule, so you can adapt the software and run it on a non-free operating system or compile it with a non-free compiler.“
It is sometimes difficult to express such ideas in unambiguous legal language that can be used in court if necessary. It is always important to look at the spirit of the law, not just the letter of the law. I hope that with this perspective the rules will seem less ridiculous.
All the navel gazing about whether linking in different ways, or putting things on the same distribution tape or on different tapes, and how that all impacts whether a work is “derived” or not, is such a monumental waste of human life.
This is why I’ve been pondering using the EUPL for my future projects. It tries to be all encompassing in what counts as distribution, like the AGPL, but it’s not viral. Though unlike the simple per file licensing rule of the MPLv2, it leaves the questions of boundaries and derivative works up to copyright law and courts, rather than trying to define such things.
Note that the EUPL is viral (it quite literally has a clause named the “Copyleft clause”) but if you combine something licensed under the EUPL with something licensed under one of the explicitly compatible licenses, the combined work may be licensed under that other license.
It’s basically viral, but not that picky about what license it ends up under.
Copyleft != virality
The authors of the EUPL very much intended for there to be no virality. It certainly isn’t as loose as the MPLv2, but, it does contain a some language which should make you understand it differently from how you understand the GPL licenses.
The Copyleft clause says this:
If the Licensee distributes or communicates copies of the Original Works or Derivative Works, this Distribution or Communication will be done under the terms of this Licence or of a later version of this Licence [..]
So the question is, what is a derivative work? Well, that depends on local law. Here is a European legal expert arguing that EU law means that linking does not inherently produce derivative works. The official EUPL guide (authored by the same person) makes the same argument. So you can (probably) totally use an EUPL library without having to license your own code under the EUPL, even if you use static linking!
That’s EU law, but what if a licensor isn’t in the EU? There’s this funny bit at the bottom of the license:
Without prejudice to specific agreement between parties,
— this Licence shall be governed by the law of the European Union Member State where the Licensor has his seat, resides or has his registered office,
— this licence shall be governed by Belgian law if the Licensor has no seat, residence or registered office inside a European Union Member State.
Would an American judge respect this and apply Belgian and EU notions of copyright law if an American used the EUPL? I have no idea, but this does attempt to provide more clarity than the GPLv3, I think.
The compatibility clause is relevant when a derivative work is actually created, and I do think it’s quite cool that the EUPL tries to be compatible with essentially everything rather than just reinforcing the GPL monoculture.
I realized that I’d never actually read the EUPL, and on the whole it seems pretty good, though there are some parts that give me weird vibes, such as:
The Licensee must cause any Derivative Work to carry prominent notices stating that the Work has been modified and the date of modification.
Which gives me similar vibes as clause 13 of the AGPL. I wonder what a court would decide counts as prominent notices, especially if the original work didn’t have a copyright display of some kind. If taken strictly then this clause would seem to require these notices to be in place before I push any other changes to a public repository, so what would count as a derivative work feels pretty important. (At least it doesn’t try to talk about it at the moment of modification like AGPL does.) And what counts as “the date of modification”? Every modification? Or just the first one that turned it into a derivative work?
I like that it includes its own DCO though, and I think it’s funny that it lists itself as a compatible license.
GPL 2.0: “You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.”
GPL 3.0: “a) The work must carry prominent notices stating that you modified it, and giving a relevant date.”
Apache-2.0: “You must cause any modified files to carry prominent notices stating that You changed the files; and”
MPL-1.x: “You must cause all Covered Code to which you contribute to contain a file documenting the changes You made to create that Covered Code and the date of any change.”
Seems pretty standard for an open source license?
I don’t know, to me those feel qualitatively different because they mention the files rather than the work. Maybe there’s no difference in practice, but I wouldn’t feel comfortable assuming that without a court saying as such.
I’d actually forgotten that Apache 2.0 carried a similar clause, though thankfully it doesn’t mention dates. I wonder how many times I’ve violated the Apache 2.0 license this way though.
And I guess regarding the MPL that this is one of the ways v2 was made easier to apply.
CDDL was derived from MPL1.1 but dropped that clause. As such, the idea was already out there for MPL-2.0.
“Provide a changelog” (which is what this is about) must be the most-often violated provision in all open source licenses. The only space where I’ve seen some adherence to those rules was the GNU project. Back in the day, CVS, Subversion (to some degree, since $Log$ is missing) and GNU arch provided facilities to support that automatically, but SCM-level editing of source files is now frowned upon.
Some projects argue that the change history in their SCM satisfies that. Maybe. Maybe not. Since we’re in a thread spawned by a ticket on an issue tracker where they language lawyer about distribution requirements, maybe that’s only valid when shipping the repo with all history but not for release tarballs. Who knows? 🤷
Some projects argue that the change history in their SCM satisfies that. Maybe. Maybe not. Since we’re in a thread spawned by a ticket on an issue tracker where they language lawyer about distribution requirements, maybe that’s only valid when shipping the repo with all history but not for release tarballs. Who knows? 🤷
Yeah, I think in practice courts wouldn’t buy it for most projects because the covered work is too easily detached from the history, e.g. by using any of the auto-generated download links provided by GitHub.
I have kind of conflicting feelings here because while on the one hand I absolutely have no intention of doing that kind of busy-work, and I also kind of really hate seeing the noise of long lines of useless and not even necessarily correct metadata in all files, I can also understand why a copyright holder would want derived works to specify how they differ from what might be attributed to the original copyright holder. I don’t really know how to reconcile these two things, but my apprehension of doing it would at least be a very strong reason for me sticking with ISC instead of starting to use e.g. the EUPL for my work.
Though the date thing in particular seems rather superfluous to me, especially since the entire concept of copyright lines at all wholly unnecessary under the Berne Convention and at best just provide you with extra information, and at the worst will give you actively misleading indications since they don’t hold any legal significance and so there’s no strong reason to try to keep them correct. In theory they would at least tell you when the copyright for a given file might expire, but in a world where so, so many projects automatically bump the copyright year in all files at the start of every year, or at least when even the smallest non-copyrightable change is made to a file, that is an entirely unreliable metric.
in practice courts wouldn’t buy
In practice courts wouldn’t bother with that provision unless it’s a central argument in the case.
A lawsuit that only claims “They didn’t maintain the changelog!” would be laughed out of a court, since no harm has been demonstrated. Maybe with a nudge: “oh and buddy, for peace’s sake: maintain a changelog.”
Any more specific case likely has various laws at its disposal that will apply as well, depending on what exactly the case is about: defamation laws, competition laws, trade/import laws, maybe media/press laws, everything that’s concerned with attribution. The absence of such a clause in the license won’t protect from such lawsuits.
Sun dropped the provision from CDDL, their variant of MPL 1.1, without anybody forcing their hands. If there was any legal meat behind it, they wouldn’t have (being a corp, even if somewhat quirky), which makes me conclude that even if it’s annoying that the EUPL and others still have them, these clauses are basically dead weight.
I think most of that is very reasonable reasoning, unfortunately I wouldn’t feel comfortable using a license while explicitly disregarding parts of it based on what I and other people on the Internet consider reasonable.
Sun dropped the provision from CDDL, their variant of MPL 1.1, without anybody forcing their hands. If there was any legal meat behind it, they wouldn’t have (being a corp, even if somewhat quirky), which makes me conclude that even if it’s annoying that the EUPL and others still have them, these clauses are basically dead weight.
I don’t find this to be a convincing argument. They might have simply decided that they themselves fully complying with the clause would’ve been too much of a hassle and therefore dropped it. I think also it’s important to keep in mind that what Sun might or might not have done they presumably did with a mind towards US law and I’m mainly concerned with how this would work out under EU law.
Edit: And in fact this seems to be more or less what Sun themselves say:
3.3. Required Notices: This section is based on Sections 3.3 and 3.5 of the MPL, though the form by which a Contributor identifies Modifications is no longer specified. References to Exhibit A were also removed. This was done because the requirements of the MPL seemed overly specific and burdensome; even the Mozilla community doesn’t seem to consistently adhere to this practice. Since failure to follow requirements of the license can have significant legal repercussions, it seemed best to be pragmatic and leave the details of how notice is provided to the community and its developers. We note that our requirement is similar to that of other open source licenses (e.g., CPL, OSL).
— https://web.archive.org/web/20050206185953/http://www.sun.com/cddl/CDDL_why_details.html
Additionally, I would assume that the people drafting the EUPL, which happened soon after the CDDL was released, would have been aware of the other relevant licenses in the field and have looked at how newer licenses were changed from the ones they were based on and they still decided to include this clause in their own new license.
Anyway, most of my concern with all of this in the end has to do with how the EUPL uses the term “The Work.” The relevant MPL 1.1 clause only applies to the Covered Code, but the EUPL clause applies to the work as a whole, which means that if you distribute compiled versions they need to contain those prominent notices as well. This would mean that just as with the AGPL, if the software doesn’t actually have a way of even producing those “prominent notices” you would have to implement that before making any other changes to comply with the license. That’s pretty trash IMO.
I don’t know, to me those feel qualitatively different because they mention the files rather than the work
The quoted excerpt from the GPLv3 doesn’t:
“a) The work must carry prominent notices stating that you modified it, and giving a relevant date.”
Fair enough, but one example doesn’t exactly make it “pretty standard” if it is indeed qualitatively different.
The file is the licence boundary.
There’s an annoying loophole I’ve seen used, where you’d have a function in an MPL’d file just call a function in an added non-MPL file. Hard to fix though, without leaving the question if something is a derived work to the courts.
Sure, but by that interpretation, every package in Debian is distributed in a way such that OpenSSL “accompanies the executable”, effectively nullifying the exception entirely. So either the system library exception is valid, and applies to this case, or it is invalid, and there’s a whole bunch of other packages that need to be fixed to link against GnuTLS or whatever (including one of mine).
That’s what Andreas Metzler is arguing in the mailing list:
well, we have decided to use the system library exception because we thought we had the right to so, not because we hoped that no copyright holder would notice. Undoing this for specific packages where a copyright holders tells us he disagrees undermines this position. Imho we need to either with using the exception or somebody(TM) needs to do a license analysis of our packages and we then need to implement coding changes to weed out any and all GPL<->openssl linkage.
Am I reading this right? OpenSSL, the core cryptography library that ends up being a dependency or transient dependency of so many other libraries, cannot be linked against GPL software unless the distributor of the GPL software avoids also distributing OpenSSL? That’s hella weird.
I have occasionally licensed software under the GPL in the past. However if that makes the software impossible to package by distros because it probably depends (directly or indirectly) on OpenSSL, I guess I’ll have to stop licensing anything as GPL?
IANAL, but IIRC GPLv3 is compatible with OpenSSL licensed under Apache 2.0, but GPLv2 is not. You’re fine using GPLv3.
If you use GPLv2, and you are the developer, you should add an exception.
The source of the incompatibility is the patent grant clause that is present in Apache 2.0 and GPL v3 but not in GPL v2. So yes, simply licensing it under GPLv3 allows unrestricted linking with anything under the Apache license.
In the cases of Git (and Linux – which seems to use OpenSSL code near KTLS if I recall correctly?), it’s definitely not a “simpl[e]” matter :/
OpenSSL is licensed Apache 2.0. Apache 2.0 is compatible with GPLv3. It is not compatible with GPLv2, because Apache 2.0 imposes additional requirements (around patent rights) that GPLv2 does not, and GPLv2 does not allow imposing additional requirements.
And the git ecosystem is GPLv2-only, and so is incompatible with any Apache 2.0 licensed code.
And stating my own personal but somewhat-informed opinion: this seems to involve a dynamic linking situation, and I believe the FSF’s position on GPL and dynamic linking makes claims incompatible with (at least) US copyright law.
A problem is that if your interpret the GPL as a contract, then it can impose restrictions beyond what copyright law typically would. And despite the FSF loudly claiming for a long time that the GPL is not a contract, it seems to always be interpreted as such in Europe, and just recently in the US in the Software Freedom Conservancy, Inc. vs. Vizio, Inc. case, contract law was invoked, rather than copyright law.
A recipient doesn’t have to agree to/accept the GPL unless they do something that requires the rights granted by it. The FSF’s position is that dynamic linking requires one or more of those rights and so you must accept GPL to dynamically link. I do not believe their position is supported by (at least) US copyright law.
This has nothing to do with contract-versus-license arguments, because if you never accept the terms in the first place it doesn’t matter whether the thing you didn’t accept was a license or a contract. What matters is you didn’t accept.
Do you have a reference for the FSF saying that the end user is violating the GPL by dynamically linking stuff? My understanding is that they think that the distributor of the software is the one who violates the GPL, not the user.
Hence stuff like it supposedly not being legal to distribute zfs.ko, but apparently fine to ship the source code for the end user to compile.
Again I think you’re focused on the wrong place. It’s not about contract-versus-license. It’s not really about distributor-versus-end-user. Here’s the case, as simply as I can put it:
Suppose foolib is offered by its author under the GPL. I want to write a program which uses foolib. If I use a language or implementation which relies on static linking, then in doing so I necessarily make a full copy of foolib and embed it into my own program. If I distribute my program I am necessarily distributing copies of foolib. Both of these actions – making copies of foolib and distributing copies of foolib are things that, by default, I have no legal permission to do. The only way I can do those things legally is if I obtain permission, and the only permission on offer (regardless of whether you interpret it as a contract or a license) is the GPL, so in order to produce and distribute my program I must accept and obey the terms of the GPL.
But now suppose my program is written in a language or for an implementation which uses dynamic linking. Now, the creation of my program does not require the creation of additional copies of foolib, and the distribution of my program does not require the distribution of copies of foolib. The argument is, in essence, that since I am not doing anything which requires the permission the GPL would grant, I am not required to accept the GPL in order to do this.
The only real counter the FSF has to this, that I’m aware of, is to try to argue about whether my program is a derived work of its dependencies (and thus I would still have to accept and obey GPL and all other terms of all other dependencies), which is a far muddier argument to make (especially when taking into account the GPL’s own acknowledgment that multiple compatible implementations of a dependency, distributed under different terms, might be available and it might not be known in advance which one will actually be present on the target device and selected at runtime).
Ah, I see what you mean. Yes, that’s an interesting argument. If dynamic linking does not produce a derivative work, you don’t need to accept the GPL, and thus whatever its text says is utterly irrelevant.
I don’t control the dependencies of my dependencies. Instead of causing issues by choosing GPL and making myself incompatible with a ton of good FOSS libraries out there and setting myself up for what seems like a legal nightmare, I think I’ll just be a good FOSS citizen and not use the GPL.
https://digitalcommons.law.scu.edu/chtlj/vol40/iss3/2/ is an interesting article to read, though as long as the FSF has the position that they have and folks don’t want to be in a situation that the FSF says is not OK, non-FSF opinions don’t resolve the issue.
Note that brian closed the bug now.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1094969#134
The timing of this is unfortunate. Carlson is not new to git or to Debian. Perhaps they’ve only just noticed the transitive dependency. But Debian have just begun freezing for the next release.
The openssl inclusion happened in January: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1094969#39 This bug was filled Feb 1. Seems pretty on top of things…