When I originally wrote the LGPL (v1, back around 1991) we could not imagine anything like an App Store or signed binaries. Dynamic linking provided an easy way for users to upgrade the library code.
Since the user doesn’t have the freedom to update the libs on ios etc I don’t see how you could deploy LGPL code on those platforms; since one of the points of using unity is its cross-platform support, that suggests you’d have to find another library unless you were only deploying on real OSes.
But is that Unity’s problem?
The tech industry runs on myth and superstition more than most people will admit. One persistent myth is the special role of "linking" in propagating "derived work" copyright status. Are we really supposed to believe that if non-copyleft code A is tightly coupled with copyleft code B, then the copyleft does propagate to A if we summon the ld-linux.so.2 demon for dynamic linking and doesn't propagate if A uses B via system(2) and a pipe? Ridiculous. Whether A is a derivative work of B has to do with the extent to which A is coupled to B in particular, not the mechanism of this coupling.
Personally, I've always found it hard to believe that merely using, e.g. libreadline (or Linux EXPORT_SYMBOL_GPL) really makes one program a derivative work of another. Is there any actual legal precedent for mere dynamic linking propagating copyleft? Common sense suggests that, no, linking to libreadline or libmysql or whatever doesn't make a program that does something totally different a derivative work.
Has the linking-propagates-copyleft theory ever actually been tested? Might we have been making life hard for ourselves for decades for no actual reason?
The issue ‘One persistent myth is the special role of "linking" in propagating "derived work" copyright status’ has nothing to do with GPL.
If you use any 3P library it’s a derived dependency by law. Is that what you are arguing? It’s settled law at this point.
MS lets you link against their DLLs but only on their platform. You might pay for a special library, but you have to pay them money for programs that link against it (actually does anybody do that any more?). GPL code is no different in any way except instead of paying the FSF cash or buying a Windows OS you agree to provide the user the freedom to change the code.
Is it? So if I, the author of non-copyleft A, want to use copyleft library B, it's illegal if I use `dlopen` but legal if I use a socket or a pipe? That's absurd. Either both are illegal or both are legal, and I've yet to see evidence that it's the former.
IOW, I've yet to see evidence that licenses apply across dlopen bounds. It's a meme in our industry that it does, but does it really? Where's the data?
“Where is the data?” Have you never used third party code that you didn’t compile yourself?
Hell, Unity itself (the topic of this article) is an example. Labview. Some code for talking to a spectrometer we bought for our lab last month. It’s extremely common. People used to sell libraries to do various computations and charge royalties for their use. Probably they still do but I don’t work in that kind of world any more.
You may call it absurd if you like but that’s how the system works. The GPL and LGPL deliberately do not break new ground in that regard. What was/is novel about them is not using an exchange of money, but rather other value instead. No more, no less.
Free software is different.
Consider the GPLed libmysql. I can already freely copy libmysql from system to system in either source or binary form. The GPL grants me permission to do that. Fine. Now I copy libmysql.so to /usr/lib and my non-copyleft libproprietary.so to /usr/lib alongside it. Also allowed. But magically, the moment the dynamic linker loads libproprietary.so into the same address space as libmysql.so, I've broken copyright law?
Yeah, I know that's the FSF's interpretation. I don't buy it, and here's why: this interpretation followed to its logical conclusion makes huge swaths of the free software ecosystem illegal. See, the FSF theory is that libproprietary.so becomes a derivative work of libmysql.so because it calls APIs provided by libmysql.so. Maybe the FSF is right. Maybe they're wrong. If they're right, though, why should it matter how I use libmysql.so's APIs? Do socket() and connect() make libproprietary.so not a derivative work? Why? I can use an API over a socket too --- and if using an API makes my program a derivative work, then every proprietary program that talks to MySQL is in trouble. This conclusion is absurd: therefore, our premises are wrong.
You might say, "well, MySQL's socket API is obviously for general purpose use". So is libreadline's. So what? Either calling a public API propagates copyleft or it doesn't. Differentiating between calling APIs via dlopen() and via socket() makes no sense. I know the industry behaves as if there were a difference, but legally, is there? Show me the case law.
The reason I can't just download LabVIEW and run it isn't that it's a library: it's proprietary software! I don't have permission to have it on my machine except by following the rules of the LabVIEW license. I don't need permission to have libmysql.so
Mmh... The GPL and copyright are about information distribution. You, as someone who owns their copy of libmysql.so and libproprietary.so, can do whatever you want with them. They're on your hardware and no one can tell you what you can order your hardware to do with the information that's on it. The question is, if you write a program that uses them both and you share that program with the world, how are you supposed to license that program? I.e. What rights are you supposed to give the users of that program?
So the question of whether you've broken copyright law depends on how you've licensed the program that links to both libmysql.so and libproprietary.so. If the program is closed source, then yes, you've broken copyright law. If the program is GPL'd then, I don't know. Maybe you have, but I don't know who could sue you for making a GPL'd program that depends on a closed source library that you don't have the source for.
My point is that although many believe that linking proprietary code and GPL code into the same process breaks copyright law, it's not clear that the law actually forbids it. https://tech.popdata.org/the-gpl-license-and-linking-still-u... is one analysis by someone else skeptical of the FSF's position.
I would argue that the act that makes a piece of software "derivative" of another is not loading them both onto the same address space (since that's a symmetric relation anyway), but whether making one depend on the other having a specific behavior. If A.so provides foo(int) with some contract C and B.so depends on an implementation of foo(int) that matches the contract C, then arguably B.so is derivative of A.so, and the more facilities A.so provides and B.so assumes are available, the stronger that argument becomes. Whether the way A.so and B.so communicate is through a calling convention, a pipe, or a network connection, is largely an implementation detail.
I have two points:
1) it's not clear your interpretation of what makes software "derivative" is correct. One interesting analysis is https://studylib.net/doc/18120956/triggering-infection--dist......
2) if you are correct, then isn't it a violation of copyright law to use a socket or a pipe to talk to a GPL program? For example, if I execute popen("parallel ..."), I'm using a pipe to talk to a GPLed program (assuming "parallel" is GNU parallel). I expect this program to adhere to a specific command line interface. My program won't work with anything else. Is my program violating the GPL by running GNU parallel as a subprocess? Most people would say "no". This position seems incoherent to me.
One of two conditions must then hold: either a) dlopen has legal significance, or b) much of the Linux ecosystem is out of compliance with the GPL because it attempts to use pipe() to circumvent the GPL and this approach doesn't actually work. Which is it?
Afaik the FSF agrees with your dichotomy and expresses the latter opinion. Take for instance their faq "You cannot incorporate GPL-covered software in a proprietary system. ... However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program. The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing."
In another question, they address the notion of what might be considered a single combined porogram. "It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program.
"If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins. If the main program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.
"Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking."
So I don't think that the FSF intends that you can use a technical means to escape linking. You cannot take a GPL library and write a pair of libraries which expose its functions via a socket because the result would almost certainly involve "function calls to each other and share[d] data structures".
https://www.gnu.org/licenses/gpl-faq.html
As to whether this puts into jeopardy anyone in particular who uses Linux or libmysql in proprietary systems without additional licences, well, that is a different matter. The FSF's interpretation of the GPL tells you something about when the FSF might sue you and about what revisions might be made to the GPL in the future. But it doesn't tell you about when the copyright holders of Linux or libmysql might sue you, or what they will do if there's a GPL v5.2 released tomorrow.
I would argue that yes, you're not working around the GPL by going through a pipe. Your program still doesn't work if the remote process gets killed, so it's dependent on it.
What do you have in mind in particular?
> I don't need permission to have libmysql.so
Er, dude, you do. A Free license doesn't mean there is no license. If you obtain libmysql.so and use it in any way, you have to respect the license or you're in breach of copyright law.
The fact that free (re)distribution is allowed by the license does not mean that the use of it in any way is not restricted.
> this interpretation followed to its logical conclusion makes huge swaths of the free software ecosystem illegal
That might well be. Free licenses are abused every day, as people don't really know what this or that license requires. They even routinely strip copyright statements on MIT/BSD code, which is literally the only thing one is not supposed to do. But just because people get away with speeding over the limit on most days, it doesn't mean that the speed limit is not legally enforceable.
We're talking about following the GPL to the letter with respect to libmysql.so. The GPL says nothing about what I can do with a program on my system not covered by the GPL.
As far as I know, the FSF takes the view that linking is a logical concept not a technical one, and so communicating via IPC is just as much of a problem as loading a program into your own addressable memory.
I don't think you've demonstrated that it's absurd. For instance, it could be that MySQL does not believe it is a problem, and does not intend for it to be a problem, and will never sue for it - but that MySQL is wrong as a matter of law, and one day the FSF will sue someone in court and win and the Oracle lawyers will realise they have new opportunities for financial gain. Personally, I think that reality is more like this - the FSF and Oracle have different ideas about what it means to release code under the GPL and so the freedoms you get from the FSF are different from the freedoms you get from Oracle, and it's unclear to me what will hold up in a court of law. I certainly don't think there's anything absurd about the notion that different agents have different intents and conflicting understandings. (Note that I take the notion of freedom to include the confidence that I won't be sued by a rational agent for doing something, regardless of whether I could plausibly win the case or not.)
I don't think it makes a difference whether the case law is there. The difference is made by whether you're willing to go to court over it. If there is a chance that you will win a case, and there is a chance that you will loose a case, and that if you lose the case you will have to spend the next six months on full time development just to get back where you were before hand, then you might say "even though my lawyers say there is an 80% chance that we will win, I would rather use this BSD alternative, because the risk of that 20% are existential".
So, fundamentally, this is a case of put your money where your mouth is. If you think the GPL does something different than what "industry" thinks it does, then make your business, make your millions, and dare someone to sue you. No one else has an obligation to do that just because you haven't seen the case law.
Btw, here you have a false premises. You don't have permission to copy libmysql.so except by the terms of the licence. I think you've made a mistake. Let's go back. You said "I can already freely copy libmysql from system to system in either source or binary form. The GPL grants me permission to do that." But now you're claiming that the GPL's grant of permission is so absolute that you don't need the permission that it grants. In fact, the terms of the licence are limited, and the question is only to what extent they are limited.
In any case, there is one important consideration. And that is the intent of the FSF. If the terms of the GPL fail to have the legal consequence they intend, and they can modify the GPL to have the legal consequence they intended, then you can be sure they will. And if Oracle has a different intent, and likes the legal consequences that the GPL has, then they might continue to use the unchanged licence. But arguing about whether the GPL does to the FSF's code what the FSF wants the GPL to do is more about arguing about whether it is buggy, then arguing about the feature set. You are well advised to listen to the FSF's interpretation if you want to rely, indefinitely into the future, on an up-to-date version of the FSF's code. But the FSF's interpretation might not really be as important when it comes to Linux or MySQL or any of the other GPLed code bases out there.
I'm having a hard time figuring out what either of you are actually talking about.
He's talking about various ways code written by one party may invoke code on the same computer written by someone else but not saying exactly how those two chunks of code came to be on the same computer running at the same time. Without knowing all the people involved in that it is not possible to say what copyright law says about who needs to get permission from whom.
You've talked about "derived dependencies by law" but "derived dependencies" is not a term I've come across in US copyright law.
A lot of free/open source discussion (and sometimes the licenses themselves) tends to use terms that have "derived" in them but mean some sort of vague superset of what copyright law means by "derivative work".
In particular, if work X depends on work Y, even to the point that X is not really useful unless used with Y, that does not necessarily make X a derivative work of Y. That's why game console makers had to use DRM to stop other companies from making cartridges for they game consoles. Even though the software in the cartridges was utterly dependent on the code in the console to do anything the cartridges were not derivative works.
To be a derivative work of Y, X must incorporate some or all of Y. Suppose for example Y is a text to speech library which exports a function "int speak(char * text)". If I write a file, greet.c, that contains this:
greet.c is not a derivative work of Y because I have not included any copyrightable elements of Y in greet.c. If I compile greet.c and link it with Y the resulting a.out is a derivative work of Y.I can license greet.c under any license I want and distribute it under any terms I want without having to worry about Y's license as far as possible liability to me for direct copyright infringement goes. I'll cover indirect infringement later.
If I want to distribute a.out then I do need to worry about Y's license, because a.out is a derivative work of Y.
If someone else makes an a.out from my greet.c and Y they are making a derivative work, and need permission (maybe [1]) from me and from Y's copyright owner.
It is possible to be an indirect copyright infringer. There are a few different kinds of indirect infringement, such as vicarious infringement and contributory infringement. What they all have in common is for someone to be liable as an indirect infringer there must be a direct infringement for them to be indirectly liable for. If there is no direct infringer there cannot be an indirect infringer.
Since most open source licenses only impose requirements when you distribute code, doing stuff with it on your own computer just for you own use will usually not be a direct infringement, and hence no possibility of indirect infringement for those who supplied you with other code that you used with the open source code code.
Even if you combine my greet.c with someone else's code on your computer and distribute the resulting binary in violation of that other code's license (making you a direct infringer) I'd be OK unless (1) I had the right and ability to control you and received a direct financial benefit from your infringement, (2) I distributed greet.c with the object of promoting its use for such infringement and clearly expressed that or took affirmative steps to encourage it, or (3) greet.c has no other substantial uses that are not infringing.
[1] I say maybe because if they are just compiling and linking copies of greet.c and Y that they legally own in order to use them on their machine they might not need permission. US copyright law contains an exception for things that are an essential step to utilize a program on a machine (17 USC 117) and they don't do anything else with it like distribute it.
I think this is very much debatable, and I believe the FSF at least takes the position that greet.c is a derived work of Y since it is designed to depend on Y. Even more, their position is that a program like this:
Is quite possibly a derived work of GCC, since it depends critically on communicating with GCC using a very complex and specific data interchange format (the GCC-specific C source code). Note that this is not including any portion of GCC itself, even after compilation.Now, this type of thing has never been tested in a court of law as far as I know, so it's difficult to say whose interpretation of copyright and its implications is actually correct. But this is similar to the idea that if you were to write an original novel that uses characters or very recognizable aspects of, say, The Lord of the Rings, you'd be creating a derived work (and thus permission from the Tolkien estate), even if you didn't include any part of the original longer than "Galadriel".
What is the point you are trying to make here? You can't use a proprietary library without a license because you can't distribute it. Whether you can have code linking to the proprietary library without distributing the proprietary library has been largely irrelevant to the makers of those libraries since you wouldn't be allowed to use that functionality without either the distributor or the user paying for a license anyways.
Distribution is not required for copyright infringement. The creation of a derivative work is a separate right in copyright.
Copyright law has however implemented exceptions in the form of interoperability. The distinction between creating a derivative work, or having two works communicating with each other, is a relative fuzzy one.
This is a question of law, not math - the property doesn't have to be commutative or even consistent.
Licenses apply across certain kinds of linking and not others because that's what was in the document you agreed to when you installed the copyleft code. In order to run the code, you have to accept the terms of the contract. Those terms can require almost anything the author wants. In this case, the terms specify propagation over dlopen and not over a socket or pipe. They could just as easily specify the opposite! It would be less sensible, but perfectly possible.
The GPLv2 (for clarity: GPLv3 is more verbose but communicates the same idea) says:
Where does this license talk about linking? Why should the GPL apply to my program that calls libreadline when I'm distributing the two separately and combining them at runtime? And more importantly, why does a combination involving dlopen() summon the copyright demons but socket() not? The distinction makes no sense.
I'd like to see actual case law showing that if I dlopen() libreadline from a proprietary program, dlsym() a function, and call it, then I've violated copyright law. Show me one example of the legal system adopting this interpretation.
Because if you don't agree to the GPL's interpretation of it, then you haven't agreed to the license for the library and you don't have permission to distribute it?
(edited)
I think this is the magic legal judo of the (L)GPL that makes it work. Regardless of your feelings about the license, it's extraordinarily clever!
Note that if the license said you had to, for instance, share x% of your revenue with the licensor, that's not part of copyright law either, but it's still probably a legal license.
Neither the GPLv2 nor the GPLv3 define what constitutes a derivative work or make any claims about linking in the normative parts of the license.
Let's assume that tomorrow some courts were to find that two separate works can link to each other without being considered derived works of one another, and without the whole being considered a derived work of either part. Nothing in the text of the GPLv2/3 would then prevent you from writing a program which links to GCC, and distributing it under a fully proprietary license (as long as you distribute the sources of the version of GCC you're using, of course).
There is one tiny reference to linking in the non-normative parts of the GPL, the "How To Apply These Terms To Your New Programs" section after the explicit "END OF TERMS AND CONDITIONS":
This may suggest that the writers of the GPL believe this would not be allowed under copyright law, but being outside the normative area of the license, seems unlikely to be an impediment in court.
it doesn't, full stop, but the FSF has been pushing its maximalist theories which would not survive a second in court for decades now.
what may be more relevant is that the use of the GPL is evidence that the author (possibly) believes in maximalist FSF theories. and therefore might not be someone whose libraries you want anywhere near your work, for avoidance of potential disputes.
Not it's definitely not. For B to be a derivative work of A it needs to include copyrightable elements of A. But if B merely dynamically links to A then it only contains knowledge of the API surface of A. And SCOTUS refused to rule on the copyrightability of APIs in Google LLC v. Oracle America, Inc. In the EU APIs seems to be explicitly called out as non-copyrightable by Directive 2009/24/EC Article 1(2):
No, you are wrong. Libraries have an usage license on linking. Don't comply it, then reimplement your own readline and ship that instead of GNU readline. Period. Motif and Lesstif was an infamous case back in the day. Heck, or using Wine DLL's under Windows instead of the ones bundled from Microsoft.
A third party library can claim whatever it wants in its license, that doesn't make it enforceable. There needs to be some mechanism that causes the terms of the license to apply to you. If you don't distribute any copyrightable parts of a third party library then you (may?) not be under any obligation to adhere to its license.
Even if you don't personally violate the license, the license may still be enforceable against the users of your program. When the user executes your program and it loads other libraries into its memory space, then it definitely has become a derivative work and the terms of the libraries will apply to the program as a whole.
At least in the USA, the copying of a program you legally received into working memory doesn't require a license of any kind, it is a type of fair use. I believe the EU has an explicit exception to copyright for the same reason. So I don't think any problem would arise when running the programs.
The only pertinent question is whether a program B designed to require library A is a derived work of library A or not - and this is a question for the copyright courts, the license of library A has nothing to say about this.
Now, I think even if it were established that program B is not a derived work of library A, it could be possible for library A to have a license that says "you're not allowed to distribute this library to others unless both you and they agree to never link program B or works derived from it with library A". The GPL could be modified to say something like this, and it may still match its original goals - though it may be more difficult to litigate this type of license term (in many countries, license or contract terms can be declared too onerous and be ignored).
An utterly irrelevant side point since the whole question is the use of the implementation not the API.
If you call write() in Microsoft’s libc you must follow Microsoft’s license terms or you don’t have the right to use it. If you call glibc’s write() the same applies. And if you don’t like glibc’s terms you are free to, say, install bsd’s libc or write your own write() implementation (which probably just does a system call anyway).
I don't agree with you but I appreciate you providing me with comments like this to cite when I try to convince people "yes, FSF are really that maximalist; no, that's not a 90s relic they moved on from".
unless you make sure that gumby is speaking for the FSF, then that comment does not provide evidence that the FSF believe that. It's merely evidence that gumby does.
I don't understand why people are so quick to take somebody's personal opinion and ascribe it to whatever organization(s) they happen to belong to. This sort of fallacy is why we constantly have to suffer through the "I speak only for myself, not my organization" disclaimers
I thought that the license for B says you can't distribute it along side A.
Not that copyright propagates.
Obviously, a zip archive containing A and B is a derived work of B. Hence, license of B can say you can't distribute such works.
Does distributing A without B make any sense?
I have seen stuff like this. Audio programs asking you to specify the location of lame_enc.dll. Emulators asking you to specify location of some bios.
The BIOS it's a different case. That's left to the user. Also, the usage of the BIOS happens under emulation, not the main machine. For instance, FUSE with the Sinclair ZX ROM's instead of OpenSE. or Vice with the Commodore BIOSes instead of shipping C64 OpenBIOSes.
Nope. The GPL explicitly says
It’s not obvious that any copyright attaches to a zip archive at all, any more than hanging two paintings on a wall makes a derived work copyrightable wall.
To be a derived work something still has to be a ‘work’.
A distribution license can restrict how you are allowed to distribute a work because it can directly restrict your behavior not because it propagates and applies to the container you distribute it in.
That is it can just say ‘you can’t distribute this bundled up with other things’, in much the same way as it can say ‘you can’t distribute this without the copyright notice’, or ‘you can’t distribute this on Wednesdays’.
I've never understood the problem with (L)GPL code on iOS devices. Sure, users don't have the possibility to replace the code on that platform. But the restriction is not imposed by the people distributing the code, but by external circumstances (Apple).
I can distribute LGPL licensed code to people no problem even if they are then, additionally, forbidden to actually excercise their freedoms by laws, think for example about radio code. I might have to get a special permission to run the code if I make changes and compile it, but that's no concern of the person licensing their source code to me.
Same if, say, the code runs on a box in an inaccessible space, and in order to install their own binaries somebody would have to press a button that they can't reach. That's not a GPL violation.
If I have the OK from Tim Cook and all the secret signing keys, I can compile and run anything I want on my iOS device. And even without that, if somebody provides all the object files of non-LGPL code and build instructions, I can replace the LGPL code and run my own version outside of the app store. Often when people ban (L)GPL code, its just a pretext, because they don't want to deal with the complexities or for other reasons.
Edit: I've been thinking about LGPL 2.1. I think LGPL 3 does explicitly forbid the above mentioned situations?
(And of course this is just my reading as an interested layperson, you're the expert obviously :-))
Let's imagine I'm making MortPlayer, a video player for iOS which uses a version of the VLC libraries which are licensed under LGPL 2.1 (since that's what you're focusing on). Let's say I want MortPlayer to be closed source.
In other words, VLC owns the libraries, and I want to license them under the LGPL 2.1.
The LGPL 2.1 says:
Okay, so I must distribute MortPlayer under terms which permit modification and reverse engineering. I can do that. Maybe Apple's terms conflict, but let's assume that's not an issue, let's read on. Okay, no problem. Oh boy. Okay. I can accompany the work (MortPlayer) with the source code for VLC's libraries, no problem. MortPlayer is executed and linked with VLC's libraries, so I need to 'accompany the work with ... the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library".I think that's doable with app stores? I can certainly distribute a zip file with the object files for MortPlayer so that the user can link them against their own version of VLC. The user wouldn't be able to then run the recompiled application, on their device, but that's not specified in the terms...
Honestly I'm a bit surprised, I fully expected to find that this section a) included wording which requires the user to be able to run the resulting linked application, which Apple forbids (asterisk), and then go through b) and conclude that iOS doesn't have a "suitable shared library mechanism" due to its restrictions etc. But I'm instead forced to conclude that you're probably right, at least by the letter of the license.
I read the corresponding parts of LGPL 3 as well, and I can't find anything which requires the re-linked application to be immediately executable on the user's machine there either.
I think my conclusion is that LGPL, both 2.1 and 3.0, is fully compatible with app stores so long as you distribute your application as object code which can be linked against the LGPL licensed libraries? I would be very interested to hear from someone with opposing views about why I may be wrong. I, as they say, ANAL.
Are these new changes with LGPL 2.1? I don’t remember it containing the modification and relinking restrictions in the past. It kind of defeats the purpose of the LGPL IMO.
As an aside, it really bugs me that the GPL morphed into this thing that gives developers the freedom to run privacy violating and user-abusing cloud services, but doesn’t allow manufacturers to ship the same stuff on physical (and perhaps offline) hardware the end users have physical control over.
When the GPL 3 added the anti-TiVo clause, it really should have also added AGPL’s anti-google clauses at the same time.
Anyway, I guess the above restriction means I won’t be using LGPL for stuff I write at work, even though most of what we do gets open sourced anyway.
Huh? The whole point of the LGPL is to say, "you can use the LGPL'd code in your closed-source product, but the user must be able to replace the LGPL part of your product with their own version". The way to achieve that is to either use some kind of dynamic linking where the user can provide their own .so/.dll/.dylib of the LGPL'd library, or to provide the object files so that the user can statically re-link the application with their own version of the LGPL'd library.
This is different from GPL, since you can't use GPL'd code in your closed-source product at all, not even if you let the user replace the GPL'd portion with their own version.
What purpose of the LGPL is defeated?
I thought the purpose of the LGPL was that it could be used for libraries without tainting the stuff the library is linked against with viral GPL restrictions.
Concretely, using gcc with default settings will bring in glibc and compiler intrinsic code snippets which were both LGPL last time I checked. If I use GCC to compile and statically link closed source code that I have a redistribution without modification license for, then I can’t redistribute my binary without violating my license for the closed source code.
Ouch! MUSL + clang it is, I guess. (I value my users’ right to own and operate computers even higher than their right to recompile code, so I’d rather not restrict my lgpl tainted binaries so they can only run in the cloud).
glibc's LGPL is generally no problem because you honor that simply by dynamically linking against it. Normal desktop Linux distributions do have a "suitable shared library mechanism" as the LGPL calls it, so if your binary is dynamically linked against glibc, your users are free to link against the user's modified libc. The "Distribute object files to allow re-linking" thing only becomes relevant if you don't use a "suitable shared library mechanism" to dynamcially link against the LGPL-licensed library.
However, if you do choose to statically link against glibc (which is highly discouraged, for technical reasons) then yeah, you have to give your users access to object files or some other mechanism to statically link against a different version of glibc than the one in the executables you ship. And yeah, this might potentially be incompatible with the licenses for certain proprietary libraries, which simply means that you can't statically link against those binaries and LGPL-licensed libraries at the same time.
The stuff in GCC which gets includes into your binary (such as crt0.o, and whatever code it generates) is except from the GPL.
I have no idea what you're talking about wrt restricting your users to only run your binaries in the cloud.
If you sell a device with Linux and a proprietary blob on it, then you’re arguably doing the linking, not the user. On top of that, if you enable link time optimization, then you have to link at build.
All of this would be allowed if you put the same device in a data center, and then had the user connect to it remotely.
IIRC, GCC specifically uses GPL + runtime license exception to avoid this scenario
The purpose of /which/ LGPL? And that's the thing. After GPL demonstrated that it had teeth and got some case law underneath it, the "family" of derivatives exploded, each one of them identifying as "open source" but each with their own additions, removals, modifications or other opinions on what "freedoms" they convey (mostly removals).
There are those of us out here who believe that the core purpose of all of these licenses were defeated a long time ago when all of this legal swizzling first began. I personally hate GPLv3, AGPL, LGPLv3, etc. with a fiery burning passion; thank god we were able to see some transformative projects emerge under actually free licenses before everything got ruined.
Either 2.1 or 3.0 I guess, the difference between the versions isn't that relevant to hedora's question.
The GPL exists to protect users against companies which develop proprietary software. If you prioritize the freedom of companies to restrict users over the freedom of those users, it makes sense that you'd dislike the GPL style licenses.
Why do you hate them so much? Is it strictly as a developer, or as a user?
As a developer I've certainly felt constrained and annoyed by them at times, and I'm very glad there are alternative open source licenses available, but as a user I can't imagine a scenario where you would hate them. After all, the freedom they guarantee is to the user, not the developer.
Even as a developer though, the family has it's place. I don't think Linux would be a thing had it had a more "permissive" license. That GPL is what forces the big corps to contribute their improvements back. If not for the GPL, I think it would be in a position similar to that of BSD, and the majority of users would have no choice but to use a proprietary OS
They tried that, everyone balked. You know how Linus Torvalds rejected GPLv3 for Linux specifically because anti-TiVo[0] would be "changing the deal"? Imagine that times a thousand.
Furthermore, AGPL is only an anti-Google license specifically because Google is as internally afraid of it as Microsoft is of GPL. You can defeat the Affero clause by putting the software behind a proxy, for example. Furthermore, the Affero clause is only appropriate for web applications - ideally ones in dynamic languages that execute from source that remains on disk. Slapping it on all GPL software would be really, really dangerous. I've heard of people using AGPL on Ethernet PHYs - how the fuck do you offer source code to every packet that crosses an Ethernet switch?
If you really want a license clause that would absolutely decimate any corporate freeloading behavior, you want OpenWatcom's anti-private-forks clause[1]. It does everything AGPL tries to do, with fewer legal loopholes. But good luck getting that past RMS. The problem with supra-GPL copylefts is that anything that is legally watertight to a corporation is also going to impinge on a lot of freedoms we enjoy. Remember: the whole point of the GPL is to reject copyright, and that specifically means lots of corporate freeloading, because the whole point of copyright is to stop corporate freeloading.
[0] From what I've heard, the anti-TiVo clause in GPLv3 is actually less strict than the FSF advertised, at least relative to how TiVo used Linux. I can't find the original article I heard this in, though!
[1] Specifically, the OpenWatcom license requires distribution of source code whenever you use a modified version of the software.
I mostly agree with you, with one exception:
I don't think this is true. My understanding (which could be flawed) is that the whole point of the GPL is to weaponize copyright in order to guarantee freedoms, not to reject it (a subtle but important distinction).
Also the whole point of copyright doesn't seem to be to stop corporate freeloading, though that is of course part of it. It's point is to ensure that the original creator has rights to benefit from the work, whether that means getting stolen from by a huge corporation or stolen from by teenagers passing memes over the internet, or adapted by an individual/sole proprietor as part of some larger work, etc. My guess is we probably agree on this part and the debate is probably over semantics (i.e. you might have meant "business in general" by "corporate" rather than specific corporations).
It should be compatible with app stores. How would the inability to swap out the VLC library be any different from a program that you can't change because it's on a system managed by a sysadmin? Of course you, as a user, can run LGPL programs on mainframes or other third-party managed systems, this was a well known use case when the LGPL was written.
It's all about the distribution of copyrighted material. The "user" then is the admin which received the program. The other used without admin, is just using some remote service. (With telnet/ssh. No distribution of copyrighted material is going on there, just input/output from a remote service, like a web site running LGPL code.)
This is where things start being human and not only technocratic. If I, the user, have (only) an iOS device - how can I do this re-linking? I can't. I must get permission from (Apple Developer Account), buy a Mac, and re-sign binary blobs.
"The user wouldn't be able to then run the recompiled application, on their device" - I think that's where we get into the spirit of the license. It's pretty clear the license was not written to mean "here's some bytes, we write a lot about the freedom of the user" all for it to end with "can't run it though".
I can't understand someone carefully reading the LGPL license and then thinking, "great fit for a locked down app store distribution!"
I rather think that because LGPL historically saw a lot of use for platforms where this is not a problem, like Windows, where all this relinking is pretty doable, people just assume its fine on iOS.
AFAIK Apple just doesn’t allow apps which don’t that on the app store regardless of how the developer would chose to interpret the license
that's outdated info
Your face is on backwards if you think it's acceptable to tell someone that their information is outdated without also providing the new and up to date information.
the updated info is: it is now permitted
It's Apple's App Store. Being vague and non committal is how they roll.
That seems very forest-for-the-trees. It's true, but it mistakes a micro-statement of a problem (the app vendor isn't "at fault" for the LGPL violation) with the actual problem (copyleft code of any kind is effectively impossible on the most popular mobile platform in the industrial world).
The bottom line is that it's not possible to distribute a binary containing *GPL code on iOS in any way remotely in keeping with the letter of the license. People do it anyway because this code is important and useful. But Apple has effectively banned the license and that's always going to lead to friction like this.
That is quite audacious to claim.
Do you have a citation to any case law supporting your position?
If not, what would be your argument?
It's in the text of the license? See section 6. a)
https://www.gnu.org/licenses/old-licenses/lgpl-2.0.en.html
Also of course section 9: "You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License."
You can't legally put copyleft stuff on the App store, because the recipient can't modify the results. That we've all as a society decided to look the other way doesn't change the requirements of the license.
So no case law.
You've pointed me to two sections of the license, but neither directly says what you're claiming. Why don't you help us understand what your argument would be? I.e., explain how you would apply the rules in the license to the facts of iOS distribution to reach the conclusion that distribution on iOS is a per se violation?
Tangent, but out of curiosity, what was the more important goal in your mind/whoever else was involved? The ability to relink with newer/patched libraries, or simply the ability to inspect/modify the LGPLed code?
I have a love-hate with the ultra-permissive licenses; on the one-hand, philosophically, I think I prefer the idea of trusting the recipient to just not be an asshole, but at the same time, I recognize [1] that corporations [which tend to prefer permissive licenses] don't always have the best interests of everyone in mind.
Even in ideal cases, like how the LLVM community tends to at least see LLVM most of the LLVM forks patches--even if they are not accepted--simply because it's effort to maintain a downstream fork of something so fast moving, community-wise, I feel like Apache 2.0 and friends end up very different, perhaps corporate, in a way that I don't love.
For example, I used to wonder how GCC still had so much backing since LLVM is generally easier to work with, from my experience, no wild autotools insanity, etc. But after doing the full UEFI -> modern Linux + GCC/LLVM bootstrap, I really appreciate the care taken to avoid constant churn to minimum C++ versions, support for obscure platforms, etc; it feels like LLVM sort of disregards anything that doesn't make a ton of visible economic sense [2], which makes the bootstrapping process so much more awful by limiting the number of potential platforms plus requiring even more steps than GCC, which is brutal on its own.
Anyway, I guess I was wondering, if you were doing it all over again, would something like the MPL 2.0 perhaps have fit the bill better? One benefit of the LGPL, to me, of course, is that you should, in theory, be able to link against a different copy. But at the same time, I guess I am more concerned about the ability to allow useful libraries to remain in the hands of the users to modify than I am about them to be able to fix a bug whatever random proprietary program--worst case, if it's something entirely unmaintained, I can often binary patch whatever bug or similar.
I feel like the LGPL, while nice in theory, probably causes more harm [for me] relative to the MPL simply because people are [unnecessarily] afraid of potential implications with static linking, or perhaps cannot be bothered distributing individual object files alongside the static binary to allow relinking. So, we end up with people choosing non-copyleft alternatives or reinventing the wheel as proprietary software.
I have similar feelings with the less-selective GPL; we've ended up with the horrible situation of people distributing images that pull the entirety of the Ubuntu userspace just to emulate static binaries via containers.
Anyway, tangent over. Also, I wish there was a well-accepted CDDL/MPL 2.0-style license with a network distribution clause; I think I've become a fan of file-based copyleft as a good middleground, but it's annoying that there isn't a popular file-based copyleft license that takes into account AWS and similar.
EDIT: Also, I guess similar to what you already touched on RE: iOS. I feel like GPL 3.0 was probably a mistake. Presumably good intentions, but I feel like the hand was overplayed; it simultaneously went too far for companies like Apple to touch it, so we ended up with ancient Bash and GNU Make with gradual replacement of anything GPL, and yet also simultaneously not far enough to deal with cloud services, containerized RPC-style not-technically-linking-but-basically-linking distribution, etc.
[1]: Personal opinion -- I know this is a VC website at the end of the day and people will disagree with me. I don't really care to argue about it.
[2]: Not meant to be an attack against LLVM. And I know there are loads of independent developers and researchers working on it too. I hope my feelings don't get totally misunderstood.
To me, CDDL/MPL 2.0-style licenses are much more sane than GPL based ones.
The definition of what is a derivative work is IMHO overreaching in GPL based licenses.
The GPL can't really overwrite the legal definition of derivative work, even if it wanted to. Of course, there is little case law actually going into the weeds, so it's hard to say for sure. However, the GPL's definition seems pretty reasonable to me as to what would constitute a derived work (anything linking with the GPL work OR anything passing very very complex structures between itself and the GPL work).
In fact, I suspect that a legal definition of exactly what constitutes a derived work of a program may be more broad than the GPL's definition. For example, it's plausible to me that a program which calls `sh` as a fundamental part of its functioning could be found to represent a derivative work of `sh` per copyright laws.
Hmm, maybe didn't use the correct term when I said "derivative work".
What term defines the scope to which copyleft applies to?
I think derived work or derivative work are the right terms. However, "copyleft" is not a legal term, and it is copyright law (and associated jurisprudence) that defines what constitutes a derived work of some original. Licenses then control what the copyright holder allows you to do with their works or derivatives.
So, only copyright law itself can say whether, for example, this comment I'm making is a derived work of your own comment, or if it is an original work of my own. If it is a derived work of your comment, then you are the copyright holder for this comment I'm making and you can choose to write a license that allows me to distribute it or nor or whatever else. If it is not a derived work, then I am the copyright holder, and I don't require any license from you to distribute this comment.
So, if copyright law were to say "a computer program A is a derived work of program B if and only if it is produced from the same source code of A or textual modifications of the code of A" (very implausible, but just for the sake of argument), then there would be no difference between the GPL and the LGPL, and you could freely link to a GPL program and distribute the result under a proprietary license (you'd still have to distribute the source code of the original GPL program, of course).
So, derivative work term in copyright law defines the scope only as binary all or nothing? It's always a whole product that is considered derived, never just part of a product.
And license itself can then limit the scope of copyleft, so that it applies it to only a specific part of a work.
Note that I am not by any means a lawyer, so please don't take my understanding as authoritative.
My understanding is that "a work" and "a product" are different things. If I sell you a bundle of three books, the bundle is a product, but each book is an individual work and caries its own copyright. Even a single book may contain 5 short stories, each with a different copyright holder and license.
Similarly, I can sell you one CD that contains three different works with different licenses. Now, it is true that the GPL license does seem to say that you can't distribute a modified GPL work on the same CD as a non-GPL work, which would not fall under copyright law, it would just be an arbitrary requirement of the license that you have to accept if you want to be able to distribute the GPL work at all (by default, you're not allowed to distribute copyrighted work at all - it's only the terms of the license that allow you to).
However, the derived work problem comes more into question when you write a program that only works if it is linked with, say, glibc. The question becomes: is your program a separate work from glibc, or is it a derived work of glibc? If it is a derived work, then the GNU project is the copyright holder of the program you wrote, and you're not allowed to distribute it at all unless you get some license from them. If it is NOT a derived work, then you are at least free to distribute your program however you want, and tell your customers "just download glibc from gnu.org, put it at this path, then start my program", and the glibc license could do nothing to stop you since it doesn't apply in any way.
An analogy with books would be you writing a book that's meant as a sequel to Harry Potter. It is quite well established that even if your book is fully original, if it uses characters from Harry Potter by name, or locations or other key concepts, then your book is a derived work of the Harry Potter franchise and you're not allowed to sell it even if you're not directly using any piece of the originals.
Either way though, if you're creating a derived work, the license of the original can allow you to distribute your derived work under any terms they want. A license could say "you can distribute derived works for free on Wednesdays, but you have to pay a royalty if it's any other day of the week". Or, more interestingly, the license could say "you can distribute derived works without any conditions if they only access our original work through DLOPEN, but if they are accessing it through static linking, you must release the code and build instructions for your derived work" - this is what the LGPL does.
GPL doesn’t use the word “derive” and specifies modified work in a way that is consistent with the customary legal definition.
People twist things around because they want to use GPLed code without “paying” for it, but really at the end of the day it’s just an ordinary license agreement but instead of paying cash to use it you agree to give users the freedom to modify and/or redistribute the code.
Just like any other licensed code you can agree to the terms and use the code or disagree with the terms and use something else.
It doesn't really matter where exactly it is defined. There's effective definition of derivative works in place for GPL, even though it's definition is inherited.
You mean, instead of paying cash to use it, you pay with your property (your code). An old school barter exchange.
Source of confusion probably comes from overuse of the word "free" by people promoting GPL, which is like you said, just an ordinary license agreement.
It's not that simple. If it was just about "my" code, this would indeed your claimed barter exchange. But often, say in industry, the code that you develop is combined with a lot of third party code and libraries for which you simply do not have the permission to put them under GPL.
IIUC, GPL based licensed do not define what what derivative work it, but leaves it to the law.
The freedom of the user to modify the library and use it was the most important part. It’s a fundamental “right to repair”.
FWIW the people involved were just me, plus John Gilmore who said “why not explicitly make dynamic linking automatically qualify?” which was obviously a good idea, and RMS who was bitterly opposed.
I wonder how many times that has happened? Specifically someone intentionally modifying the behaviour of a closed source program by changing an LGPL library that it depends on.
I personally know of that happening twice. In both cases it was used to patch a bug in the super old Qt version that was being shipped.
I'm sure it doesn't happen often, but IMHO that doesn't really matter. It's preserving the freedom to do it that is important. I rarely use my right to free speech (that is, saying something that somebody in power would find offensive and want to jail me for), but it's a right I would fight to the bitter end to preserve.
I mean, it's like telling the pope that Jesus is the son of god only on Mondays and Tuesdays, eh...
For clarity, I presume you're talking about L(ibrary)GPLv2.0 published[0] in June of '91, since afaik there was never an LGPLv1.
Anyway, do you think it's good or bad if Unity is stopping people from potentially deploying to e.g. iOS when this would violate the LGPL, even if the responsibility for the violation would not lie with Unity?
[0] https://www.gnu.org/licenses/old-licenses/lgpl-2.0.html
Given that Unity itself also uses LGPLv2.0 dependencies in its own iOS version, it seems clear that at least Unity believes that there is no issue deploying LGPLv2.0 code to iOS.
Or they’ve dual licensed the libraries in question.
You're suggesting they have obtained permission from the copyright holders of, say, libiconv, to distribute their code under a non-LGPL license?
I don't think there are any LGPL licensed libraries linked or distributed by a Unity iOS build. Neither you nor I have looked carefully, but it's almost certainly not the case.
With regards to libiconv, which I don't know if Unity iOS builds use it, there is a BSD implementation of it, which is almost certainly the case also with what iOS uses.
I can't speak to the work the author of this blogpost did with regards to investigating the usage of the specific LGPL libraries. The specific examples specified would all make sense as strictly used by the Editor.
My opinion is that if you are looking for wholesale license violations by giant corporations like Unity, libraries are the wrong place. Huge corporations launder license violations by line-by-line rewriting the code and pretending their implementation is original.
The authors of the article claim that the Unity runtime uses (some of) those libraries, and that it is being used on iOS as well. You're right of course that I have not done any independent research on it, and so they may be lying or wrong for all I know.
However, even if Unity is not using those libraries in the iOS runtime but does use them somewhere else, that still seems that they were arbitrary in their enforcement of the rules, since the VLC packages mentioned here were not being distributed for iOS at all. So they were certainly not using LGPL on iOS either.
I'd also mention that I'm not claiming that Unity is breaking the LGPL. I'm rather more of the opinion that distributing LGPL apps for iOS is not in contradiction with any of the terms of the LGPL, and that Unity thinks so as well.
Ultimately I sympathize with the author, and this is not meant to pass a subjectively negative judgement, I know the author didn't unpack a Unity iOS IPA and carefully check if any of the libraries are definitively LGPL and if they were definitively not cross licensed, that would be a waste of his time.
I don't want to make the author of the LGPL, who is commenting in this thread, regret commenting. There's a phrase he uses that makes it clear to me what its intent is, "right to repair." It comes down to whether or not you think it's impracticable to replace a library in an iOS app. For the average user it obviously is.
Is it practicable for sophisticated users? You can probably get the app bundle, replace a .dylib in an embedded Framework, resign it, and use the app bundle on your development enrolled device. But then you will lose a lot of functionality, like push notifications and IAP. And ad serving will also probably stop working. So my opinion is: no. You can't distribute LGPL libraries in iOS apps.
The article doesn't mention iOS or Apple even once, they in fact mention they only had assets for Windows, UWP and Android as three different packages, so everyone here thinking Unity is blocking the packages because of iOS has completely missed the context.
The original was used, IIRC to license glibc when Steve Chamberlain and I (mainly him I’m pretty sure) were starting out on it — I think that was the motivation. You’re right: I’m not sure we actually shipped a glibc with that version.
This was long before we hired Drepper.
Apparently not. "Unity itself, both the Editor and the runtime (which means your shipped game) is already using LGPL dependencies"
So I could be missing something, but the editor itself is not getting shipped to iOS devices, only the resulting binaries are.
That sounds like the "and the runtime (which means your shipped game)" part?
Nobody in this thread has firmly pointed to LGPL code being linked or used in the iOS runtime in a Unity 2021 or later built game. Having not looked at this myself, I can't say either way, but it is almost certainly wrong to say that the runtime contains otherwise LGPL code that was not expressly licensed or permitted for the purpose by its authors.
The resulting binaries depend on the unity runtime which itself depends on these LGPL components.
Well:
1. Unity itself is using plenty of LGPL libraries itself so the same concerns apply.
2. If this is not an issue on desktop platforms where you can comply with LGPL there is nothing wrong with allowing such packages on the Asset Store. Certainly not all developers ship their Unity games on most platforms so it should be up to them to figure whether the specific package they decide to include can be used for a given platform.
Using open source development tools is fine. What matters is what you distribute to end users (i.e. the output of those tools). I think the issue with unity is that VLC ends up being distributed as part of unity applications.
I'm not a lawyer but this might indeed have some valid issues associated with it depending on how this is done. So, I can see an argument for Unity simply not wanting to put their customers in a situation where they have to worry about these issues. It seems a bit drastic though given how useful it is.
Banning companies/accounts seems like it's simply unprofessional/rude and unnecessary. Sounds like they need to have a conversation with whomever thought that was a good idea about professional conduct.
This might be the best opening line of a HN comment I've ever seen :-D
Don't feel obligated to respond, but how do you feel about the LGPL now? How do you feel about it's evolution given the way the world has changed? Would you do anything differently now?