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.
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?
Well, TBH it didn’t have the impact I thought it might (and that RMS feared — obviously I disagreed with him). Libraries qua libraries aren’t distributed / sold so much any more as standalone packages and now we mostly have no-cost binary blobs tied to hardware or a priced API or MIT-ish-licensed stuff (like boost or npm), sadly neither of which empower any right to repair.
That decade of Cygnus was a lot of hard yakka first to legitimize the idea of free software at all (in 1989 it was mostly both obscure and insane outside academia) and then popularize it. Obviously other people started working hard on this too later in the decade.
The thing that made probably the most significant difference was the process of forking gcc which was a lot of negotiation — at that time forking a code base was widely considered a tragedy, despite the whole structure of free software!). Making forking good rather than a tragedy, coming up with an independent steering committee, and in that case getting the FSF to stop complaining decide to try to run out in front of the parade* was really hard but in the long term it became an approach that most important open source projects have taken, providing stability and progress. That’s definitely been an opment!
And then within a few years…I was on to other, more important things. It felt like the free software / open source world was no longer an embryo so didn’t need me. Plenty of other people are doing great work, better than I would have the enthusiasm for these days.
* Yes yet another case where RMS was furious about something that in the long term was a big win for the FSF too.
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 :-))
> 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).
In the case of the App Store, Apple is the one doing distribution, so Apple must also comply with the terms of the license (in addition to the app developer). Apple has decided they will not do that (that is, people they distribute to will not have the ability to modify the LGPL code, relink the final executable, and run it on their devices), so Apple cannot legally distribute binaries that contain LGPL code.
It only makes sense, then, that Apple should preemptively reject apps that link in LGPL code, as they know that they will not abide by the licensing terms.
> 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.
That's not permitted by the license. The (L)GPL prohibits a third party from adding extra conditions to exercising the rights granted in the license. "Pay Apple for a developer account and get their permission" is an extra condition. Even if there is a jailbreak-y method of getting around the extra conditions, I don't think that would fly.
> 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.
Agreed, but I'm not convinced this is one of those cases.
Does LGPL require that you be able to do so on the same platform it's being distributed on? There's nothing stopping someone from downloading an LGPL binary from the app store and running it in an emulator or something, right?
> Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version.
And from GPLv2:
> For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable.
Perhaps this is splitting hairs (although that's necessary for licenses), but would it not be sufficient to be able to install the binary somewhere, but not on every machine? E.g., if I tell a customer the modified binary can be installed on some emulator, but not their phone, why is that prohibited?
In this case, I guess the installation information would have to be "use an emulator and do XYZ".
> It only makes sense, then, that Apple should preemptively reject apps that link in LGPL code, as they know that they will not abide by the licensing terms.
But that's not the case at all. Apple is accepting apps that include LGPL code.
Within limits, all it takes to get the OK from Tim Cook is $99/yr to the Apple Developer Program. Which isn't $0, but the LGPL doesn't say someone else can't charge money to press the button. You don't get arbitrary code execution for those $99, but you get enough access to playback video. You'd have to create your own app and get it blessed by Apple in order to distribute it to other people, but doesn't that satisfy the letter of the law here? As a 3rd party developer with my own developer account, I can get the source and the object code and run my own binary that links against it on the same platform, iOS.
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.
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:
6. As an exception to the Sections above, you may also combine or link a "work that
uses the Library" with the Library to produce a work containing portions of the
Library, and distribute that work under terms of your choice, provided that the
terms permit modification of the work for the customer's own use and reverse
engineering for debugging such modifications.
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.
You must give prominent notice with each copy of the work that the Library is used
in it and that the Library and its use are covered by this License. You must supply
a copy of this License. If the work during execution displays copyright notices, you
must include the copyright notice for the Library among them, as well as a reference
directing the user to the copy of this License.
Okay, no problem.
Also, you must do one of these things:
Oh boy.
a) Accompany the work with the complete corresponding machine-readable source code
for the Library including whatever changes were used in the work (which must be
distributed under Sections 1 and 2 above); and, if the work is an executable linked
with the Library, 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. (It is
understood that the user who changes the contents of definitions files in the
Library will not necessarily be able to recompile the application to use the
modified definitions.)
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.
> When the GPL 3 added the anti-TiVo clause, it really should have also added AGPL’s anti-google clauses at the same time.
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.
> 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
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).
RMS famously refers to the GPL as a hack on the copyright system. It comes from an axiomatic belief that restricting copying in the computer age is fraught. To put yourself in the headspace, imagine the ivory tower discussion: look at how stupid this law is… don’t the plebeians know that computers copy data around the system and the network all the time to even function, literally digital would be dead if we actually enforced the letter of copyright law, oh and data is context dependent anyway so the same underlying data could manifest two wildly different concepts so you have to bind data and context not just allow people to claim rights to arbitrary strings of bits etc. etc. So it follows that copyright is harmful because if enforced it would dismantle cyberspace. The hack is to use copyright law to enforce licenses that perpetually reject copyright to make sure users have custody of their hardware and can’t be inhibited from freely running whatever combination of instructions they can dream up. A better reality would be something more akin to the world running arch linux and compiling every software from source (but we can’t have that because evil wealth extracting corporate automatons will steal your source, license it and sue you, hence copyleft). And since chefs can’t copyright recipes programmers shant copyright programs, which are just instructions that tell your machine how to achieve some outcome. You are free to sell the best tasting implementations of your programs as packaged SaaS software, though. Your value as a software chef is in the quality of the meals you serve not the knowledge of the specific ingredients used to create them.
>You can defeat the Affero clause by putting the software behind a proxy, for example
Could someone elaborate on this? This is NOT my understanding of the license, and it seems absurd considering e.g. Mastodon is AGPL but the standard install requires a reverse proxy[1]. If using a proxy defeats Affero, why would the Mastodon team do this? Are they stupid?
It's never been tested in court, but the theory is you with company A run an Affero GPL (modified code) server. It's not accessible to anyone outside company A, except me, with a proxy-ish server in Company B (which may or may not be controlled/related).
Then I'm the only user of your software, and never request the code, even though ten billion users use it via my proxy.
I'm not so sure it's just being cute. Define a bright line difference between this API proxy and something like an IRC server. Fundamentally it's an RPC black box. Client sends a command and gets a response. How that response is generated the client has no way of knowing or differentiating. For the defense to fail, wouldn't you have to prove that end user C was a recipient of software from company A? How could this possibly be true when user C cannot observe even the existence of A?
Like, imagine this hypothetical.
Set up a server. For each unique client that exists, it proxies to one of two backends. One is wrapping an LGPL library. The other is wrapping a cleanroom non-CL implementation.
A given user will always get one or the other. Think of it as being assigned off the high bit of a user hash or something.
Which users have rights under the LGPL? Remember that half of them have never used the (wrapped) LGPL implementation, and NONE of them can tell which group they are in.
I don't actually see the difference as being that distinct from the long accepted fact that a program compiled by a copyleft compiler or running in a copyleft interpreter is not itself inherently copyleft.
The idea is that the proxy removes all the AGPL compliance features from the web application. So if your app has a View Source link that spits out all the *.php files on disk, your proxy blocks that link. AGPL prohibits you from removing parts of a program intended to implement a "View Source" link, but it doesn't put any specific limitations on the conduct of other, unrelated programs.
The only other thing I could think of to prevent this would be a DMCA 1201 claim - i.e. that the view source link is a DRM system, and that a proxy that removes those links is illegal. Except all v3 licenses explicitly foreclose the ability to make DMCA 1201 claims relating to features of the software.
My guess is, Mastodon used AGPLv3 primarily because the Affero clause scares off big tech companies, notably Google. I don't have access to any IRC logs or issue tracker comments to prove this is the case, though.
There's much that's untested about these licenses in practical terms. This scheme of producing the source but also blocking it... it's hard to see it standing up in court.
Let's assume you modify the AGPL program, so the remote interaction clause kicks in. If you have the software provide links to the source, but you yourself also strip those out before any of those remote-interacting users can ever see or use them, I don't think a court would have a problem saying that you're not actually "offering an opportunity" for the users to download the source and are therefore in violation.
"To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying."
"You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:"
I think you would have a very, very hard time arguing that you had conveyed the source under this definition.
This is like paying a parking ticket on a credit card, charging it back, and then arguing that it's paid because you sent the money.
> [so], these words in GPLv3: “The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.” mean that the proprietary software that is not a combined work with the GPLv3'd work must also function?
> Absolutely. And I wrote it specifically to do that!
[0] The anti-TiVo clause only applies to "User Product" defined in the GPL as a consumer device, i.e. not a device you sell to a business. The idea being business's can fend for themselves. Its perfectly valid to create say a medical device that is sold to hospitals and have it locked down and use LGPL code. The hospital actually wants it locked down.
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.
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.
Yeah, the embedded Linux context is messy. I don't know how the rules play out there (and I would be surprised if anyone truly knows). I thought we were talking about the general computing device use case.
Link-time optimization isn't really relevant from what I understand; it's about optimizing across different object files when linking them together, it shouldn't have any impact on dynamic linking.
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.
> 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.
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
Notice the lack of "GPL" in that list, and I'm partially in agreement.
The GPL is amazing and wonderful, but the various "attachments" of the GPL are more weaponized (and to the detriment of users!) than the GPL ever was.
I'm glad the kernel stuck with GPLv2, and I wish other things had, too. A GPLv3 Linux Kernel would likely have helped a BSD tremendously, though but I think having everyone work on the same kernel without reservations has been an unmitigated good.
It's different enough that Apple thinks it's only safe for them to ship GPLv2 software on MacOS devices, not GPLv3.
This might have something to do with the way they sign shipped versions and use TPM security to verify what's run, even though you can manually disable some of this if you want.
So all GPL the software shipped on MacOS devices is stuck at the last version which used GPLv2, and they rewrote Samba which they had previously shipped, whose last GPLv2 version is too out of date to keep using.
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.
> 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).
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.
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.
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?
> 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?
That's analysis is exactly backwards, and I cited the specific text in the license that calls it out. You can't distributed copyrighted works without permission, period.
Apple can't ship my code, whether it be directly or in a Play Store app, unless I let them. The LGPL specifies the terms of that permission. They're clearly in violation, since I can't download a Play Store app and modify it.
Again, we all agree to ignore this. But it's true nonetheless.
I'm sorry, but "issue-rule-application-conclusion" is the standard analytical framework for questions of this nature. You may feel that it's "backwards" but it is, objectively, simply how this works.
There is no text in the license that discusses the issue of app stores. You have every right to jump to the conclusion without any analysis of how the text of the license applies to these facts. However, you'll of course understand that—by doing so—you aren't likely to convince anyone who doesn't already agree with you.
> I'm sorry, but "issue-rule-application-conclusion" is the standard analytical framework for questions of this nature.
Do you, heh, have any case law to that effect? No, that's silly. "You're shipping my code and have to stop" is an open and shut case. That no one has bothered to prosecute such a case against an iOS app is notable, but not proof of anything but inertia.
See, e.g., Licea v. Caraway Home Inc., 655 F. Supp. 3d 954, 968 (C.D.Cal. 2023) ("Indeed, at no point does Plaintiff bother to explain why any of his cited authorities are relevant to the instant action or how they should apply. Every law student is taught a variation on the 'issue, rule, application, conclusion' (IRAC) method for legal analysis.").
HN is for intellectual curiosity. As a result, if you want to discuss legal analysis with a lawyer on an article about a legal topic, I suggest you listen and learn, rather than insisting that others meet you in the middle on fundamental tools of analysis. And in particular, criticizing those frameworks as "arbitrary" or "made up" is dishonest and completely inappropriate.
In this case, after several days of back and forth, nobody has offered any argument for why the terms of the LGPL are incompatible with iOS apps. At this point it's pretty obvious that all of you are just trolling.
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.
> 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.
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):
> 2. Protection in accordance with this Directive shall apply to
the expression in any form of a computer program. Ideas and
principles which underlie any element of a computer program,
including those which underlie its interfaces, are not protected
by copyright under this Directive.
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).
> An utterly irrelevant side point since the whole question is the use of the implementation not the API.
I find this interesting, and maybe I am just a bit confused. But here is what I am wondering now.
If it is not about the use of an API but about the use of the implementation, then that would mean that the end-user that is running the application which dynamically links to a proprietary library on the end-users pc the one violating the license terms, not the developer that distributed their code without distributing the proprietary library itself.
And if the developer has the rights to distribute the library, because it is under GPL, then they could do so, and would not violate the license terms, because they are not doing the dynamic linking and using of the implementation, that would happen only when the end-user starts the application.
I never heard about any case against end-users, that for instance used the proprietary Nvidia kernel module, compiled and linked on each end-user's PC.
I don't think that works that way, there has to be more to that than just the usage of the implementation that triggers the license violation.
> If it is not about the use of an API but about the use of the implementation, then that would mean that the end-user that is running the application which dynamically links to a proprietary library on the end-users pc the one violating the license terms, not the developer that distributed their code without distributing the proprietary library itself.
yes
> And if the developer has the rights to distribute the library, because it is under GPL, then they could do so, and would not violate the license terms, because they are not doing the dynamic linking and using of the implementation, that would happen only when the end-user starts the application.
If they distribute it together though then it becomes an aggregate work
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".
> 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
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).
> 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.
My point wasn't about copying into memory being a license violation, rather the fact that you're combining two works together into a single program that violates the license of one of the works. Who is liable for the violation in that case? The user who combined the works together or the developer who created a program that instructs the user to combine those works together?
Perhaps you're selling a book that's derivative of Stephen King's novels, but instead of actually including text from his novels you insert pages that just say "insert chapter 5 from the Shawshank Redemption here". Even though it contains instructions to create a derivative work, it is not in itself a derivative work.
However if the reader follows those instructions and creates a completed work by inserting those chapters as instructed. That completed work definitely is a derivative work of Stephen King's novels.
In the case of computer programs, but not Stephen King novels, in the US there is 17 USC 117 to consider which includes this:
> (a) Making of Additional Copy or Adaptation by Owner of Copy.—Notwithstanding the provisions of section 106, it is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided:
> (1)that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner, or
> (2)that such new copy or adaptation is for archival purposes only and that all archival copies are destroyed in the event that continued possession of the computer program should cease to be rightful.
That should cover most likely scenarios of someone combining programs and/or libraries from various sources on their own computer as long as they own the particular copies of those programs and/or libraries that they are combining.
As a general rule, anything you do with a copyrighted work in private quite possibly falls under fair use, as long as the copies you are using were obtained legally. If you want to write Shawshank Redemption fan-fiction and read it to your kids in bed, even if Stephen King found out and decided to sue you, you're probably covered under fair use. Creating a program just for yourself that uses two separate copyrighted programs (that you obtained legally!) is almost certainly legal - even if it would be completely illegal to distribute that program to others.
This gets murkier if you're using it in a commercial setting, though.
> I think even if it were established that program B is not a derived work of library A
I don't think it ever will be.
> program B designed to require library A
How do you design program B to require A, without inspiration from A?
I believe you can't. For a silly example, take a puzzle peice. To integrate support for your puzzle in my work, I'm gonna have to copy some of your edges.
Onerousness defence can be defeated by anti-severability clauses, if that clause is written to require full reversal of performance in case of termination.
> 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.
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.
> Have you never used third party code that you didn’t compile yourself?
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
>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?
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.
> If the program is closed source, then yes, you've broken copyright law.
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.
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?
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.
> 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.
> 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".
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.
> 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.
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.
> This conclusion is absurd: therefore, our premises are wrong.
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 know the industry behaves as if there were a difference, but legally, is there? Show me the case law.
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.
> 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
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.
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.
> 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 GPL is a distribution license, not a use license. Once they've received that source and/or binary, they can do whatever they want with it as long as they aren't distributing it. (Copying it to another machine under their control may or may not be distribution, depending on the circumstances.)
Yes, once they want to distribute their copy to others, they need to comply with the terms of the GPL. But not before then.
> 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.
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.
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.
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:
#include "y_speech_lib.h"
int main()
{
speak("Hello, World!");
return 0;
}
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.
> greet.c is not a derivative work of Y because I have not included any copyrightable elements of Y in greet.c.
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".
I don't know, no one really does as this has never been tested in courts as far as I know. I believe the FSF would say that it's not a derivative work, as it doesn't interact with the Alexa code through complex data types. However, this is their own legal theory, not directly a part of any law or jurisprudence (as far as I know - if there is some case law on this topic, I would be very curious to read it).
> If I compile greet.c and link it with Y the resulting a.out is a derivative work of Y.
Link it how, though? If you statically link it with Y, then I can see the argument that a.out is a derived work, because it literally contains all of Y in it.
But if you dynamically link it, a.out contains no more of Y than greet.c does. Are you asserting that a.out is still a derived work of Y in this case as well?
> Link it how, though? If you statically link it with Y, then I can see the argument that a.out is a derived work, because it literally contains all of Y in it.
That one.
> But if you dynamically link it, a.out contains no more of Y than greet.c does. Are you asserting that a.out is still a derived work of Y in this case as well?
No, I'm not asserting that that a.out would be a derivative work of Y.
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.
> 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.
The GPLv2 (for clarity: GPLv3 is more verbose but communicates the same idea) says:
> 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
> a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
> b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
> c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
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":
> If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library [emp. mine]. If this is what you want to do, use the GNU Lesser General Public License instead of this License.
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.
> Obviously, a zip archive containing A and B is a derived work of B.
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 thought that the license for B says you can't distribute it along side A.
Nope. The GPL explicitly says
> In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
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.
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.
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.
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?
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.
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.
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.
> The authors of the article claim that the Unity runtime uses (some of) those libraries...
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.
> distributing LGPL apps for iOS is not in contradiction with any of the terms of the LGPL
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.
> There's a phrase he uses that makes it clear to me what its intent is, "right to repair."
The intent of the (author of the) LGPL and the letter of the LGPL (+ applicable law) may well be different. That is, just because the LGPL itself was designed to help with right to repair, doesn't mean it is successful at that job. It's also not necessarily the intention of others who use the LGPL - just like Linus Torvalds' intentions for using the GPLv2 are different from RMS's intentions in writing the GPL (hence why Linux is not migrating to GPLv3).
My contention is that a license can't be invalidated by a 3rd party not giving you the technical means of exercising a right that you are granted. Similarly to how the GPLv2 couldn't stop TiVo from not allowing you to run their proprietary software if you modified the version of Linux they gave you, even if RMS intended it to.
> My contention is that a license can't be invalidated by a 3rd party not giving you the technical means of exercising a right that you are granted. Similarly to how the GPLv2 couldn't stop TiVo from not allowing you to run their proprietary software if you modified the version of Linux they gave you, even if RMS intended it to.
What a way to twist things around. Apple (or the app developer, who chooses Apple to distribute their software) doesn't have the right to distribute the code without abiding by the terms of the license. Copyright applies by default unless those terms are met.
TiVo's code wasn't subject to the GPL, so obviously they can have it do whatever they want, it's not remotely analogous to distributing copyrighted works outside the terms of the license that is the only thing allowing you to distribute them at all.
Cryptographic controls might be an end-run around this (as they are being abused for many other anti-consumer purposes today). The license tries to account for this, but it looks like it only applies if the code is included with the device. Unfortunately. The law really needs to catch up with this, it's clearly a hack and not respecting the intent of this or other areas of law such as first-sale doctrine.
Not to mention that in order to have that "development enrolled device", you need to first pay Apple a fee and get their permission. Seems to me that would count as an "extra restriction" added on top of the LGPL, which the license does not allow.
> 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.
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.
Cygwin switched to the LGPL back in 2016. That's very useful; it means there is a POSIX run-time on Windows that programs using a wide range of licensing schemes can use.
When I saw the announcement on the Cygwin mailing list, I immediately set off to make a fork of the main Cygwin DLL which brings Windows-like behaviors.
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.
> 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?
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.
> The definition of what is a derivative work is IMHO overreaching in GPL based licenses.
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.
> 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.
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.
>
You mean, instead of paying cash to use it, you pay with your property (your code). An old school barter exchange.
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.
That's fine, and isn't the responsibility of the author of the GPL code you want to use. If you can comply with the terms of the license, great, you can use it. If you can't, you need to find something else whose license terms you can comply with. And you might have to pay money for it, but that's life.
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.
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).
> If it is a derived work of your comment, then you are the copyright holder for this comment
Is that correct? I am also not a lawyer, but this seems wrong to me.
If I make something that is a derived work of some other copyrighted work, my understanding is that I still own the copyright on the parts of the final work that I made (assuming what I made meets the thresholds for being copyrightable). But I am not permitted to distribute that work unless I receive a license to do so from the owner of the work I've derived from.
My understanding seems to dovetail with how the GPL works. If I write a program that links to a GPL library, and that does indeed cause my program to become a derived work of the GPL library, I still own the copyright to my program. In order to distribute my program, I have to abide by the terms of the GPL. But even if I were to violate the terms of the GPL (thus terminating my rights under the GPL), I still would not lose my copyright interest in the program I wrote, only my right to distribute it.
Looking this up a little bit more, I think it's more complicated than I was saying but also than you're saying.
For the "normal" cases, you're right: you can have copyright on the original parts of a derived work. You are fully right though that the original work's author does not in any circumstance get the copyright for the derived work. That was a confusion on my part.
> But even if I were to violate the terms of the GPL (thus terminating my rights under the GPL), I still would not lose my copyright interest in the program I wrote, only my right to distribute it.
As far as I understand though, this is not true. If you were not authorized to use the original work, then even the original parts of your work are in fact not protected by copyright at all. So, if, say, I take a Spiderman comic and add an extra page of fanart at the end, without any authorization from Marvel/Disney, then my extra page of fanart is not protected by copyright at all, and anyone is free to copy it (unless it also infringes on Marvel/Disney's copyright of course) [0]:
> Only the owner of copyright in a work has the right to prepare, or to authorize someone else to create, an adaptation of that work. The owner of a copyright is generally the author or someone who has obtained the exclusive rights from the author. In any case where a copyrighted work is used without the permission of the copyright owner, copyright protection will not extend to any part of the work in which such material has been used unlawfully. The unauthorized adaptation of a work may constitute copyright infringement.
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.
> 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
No it's not. The GPL specifically says that mere aggregation of a GPL-licensed work with another work licensed under another license does not create any sort of GPL obligation on the other work:
> A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
Here I am deferring to my company's lawyer. I believe they are interpreting (very likely incorrectly, but then they are a lawyer and I am not) this part:
> You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged.
It might be time for a mutually-assured destruction lobby/guild.
In this case, when a company like Unity bans this VLC project for using LGPL software, the guild would open individual lawsuits against them to remove each of the other projects using LGPL code, based on various legal precedents around discrimination. Which would make it untenable to single out projects like this.
This is a negative or low-vibration idea, I realize. Which is actually my point. If a policy causes one to go down these anger/fear/ego-based rabbit holes, then something is suspect with it. This is the litmus test I use.
Somewhere along the way, we lost the wisdom or will to understand the difference between the letter of the law and the spirit of the law. And we sold our souls when we allowed wealth and power to override our discernment of right and wrong.
If Unity wants to step into its power, it can start by abandoning knee-jerk policies designed to protect itself from liability against stupid laws. It can start saving a war chest to go to bat against patent/copyright/trademark trolls for the rest of us and protect the projects within its ecosystem instead of throwing its contributors under the bus. It can set an example for other large companies to follow so that we can eventually reform the system.
But whatever all this malarky is has got to stop.
I really want to like Unity for how it aligns with my goals as a shareware game developer in my formative years and a lot of other reasons, but they make it very hard to do so.
> This is a negative or low-vibration idea, I realize. Which is actually my point. If a policy causes one to go down these anger/fear/ego-based rabbit holes, then something is suspect with it. This is the litmus test I use.
IANAL but you identified the core issue. I'm having trouble finding precedent for this, mainly because private businesses are legally allowed to choose who they do business with, which can be a form of legally protected discrimination.
The closest thing I found is the 2023 Students for Fair Admissions v. Harvard Supreme Court decision which effectively ended affirmative action in the US, since Harvard is a private college "doing business with" its students (customers):
SCOTUS said that race/ethnicity and gender identity are protected classes, so discriminating by them is illegal, meaning that affirmative action can't legally be imposed on universities anymore.
Now, there are extenuating circumstances with that due to the US's civil rights battles and entrenched practices in other areas like policing and access to capital which impose additional struggle on individuals, depending on which protected classes apply to them. So throwing out affirmative action may give individuals unaffected by those practices an additional advantage (privilage). Meaning that the court's decision may have an effect opposite to the one intended, as stated by the dissenting justices. I'm providing this for context, because it's an example of how the letter of the law can be in conflict with the spirit of the law.
As a private entity, Unity must still follow federal antidiscrimination laws. It's not allowed to remove an app from its store based on the race/ethnicity/gender of its author(s) for example.
But prominance/budget and potential liabilities from lawsuits by intellectual property trolls are not protected classes. Currently Unity appears to be free to de-list any app for any reason outside protected classes.
But that discriminitory freedom is also being challenged for antitrust reasons. If a store is dominant to the point that competitors are not widely known by the mainstream, then any type of discrimination could potentially become collusion. For example if Apple delisted an app that competed with its own in order to noncompetitively boost its own sales, then that can be challenged in court. And two or more companies collaborating to remove competing apps in each other's stores can also be challenged in court.
The realities of software development are daunting. It often takes many years of work by countless individuals and budgets in the multiple thousands or even millions of dollars to ship an app. The libraries which the app relies upon are also unique in that an alternative may not be available, either for budgetary reasons around refactoring or for compliance with controversial laws like the DMCA. So an app's dependencies and licenses could be thought of as an ethnic identity for software because they can't be changed in practice. It's what they are.
Main takeaways:
1. A unilateral ban of an app by a company can represent a power imbalance resulting in injustice because the guidelines the app must follow to regain entry are not tenable. In other words dependencies, licences and other nonfungible aspects of software may need to become protected classes.
2. Is the law being applied unequaly between VLC and other apps with LGPL dependencies, or with preferential treatment?
3. What recourse do developers have other than to sue? Will their case have merit? Are there financial barriers and opportunity costs to such actions? The realities of such recourse can impose such hardship on injured parties that their involuntary surrender represents a kind of injustice that favors moneyed parties.
Keywords and avenues to pursue:
unequal application
preferential treatment
protected class
Would lawsuits against other companies along these lines reduce productivity in the tech sector by making it more difficult to do business, highlighting a need to reform legislation around this issue?
Wouldn't be surprised if Unity is developing their own multimedia engine they want to sell. Shitty practices like this is what makes me want to get into politics.
This was my first thought. They can then sell some poorly-executed knockoff, ignoring that a partnership with actual experts would have been the best for their customers.
What's the rational for not allowing LGPL code on the unity store? It makes no sense for the ban imho (tho i m not very familiar with unity store's model so i might just be missing something).
My guess; Unity doesn't want LGPL code in component they re-distribute, because the responsibility to comply with the license requirements falls on them, since they are the ones redistributing. It's not that they can't, but they wont take that responsibility, which is understandable. They would basically need to audit every component to ensure that the end user can build and replace LGPL parts with their own.
Not really. They could just distribute things anyway, and simply invoke the license-termination clauses as soon as any infringement is detected by claimants - similarly to how (I expect) they would treat claims of copyright infringements on game assets.
They are just being obtuse - which looks fishy when coupled with VLC's claims that they wouldn't allow them back in even if all LGPL code was removed. They probably don't want competition for some component.
I'd say it is even debatable whether Unity is really re-distributing in the sense of the LGPL or merely hosting. Redistribution is something between licensor and licensee, your web hoster or your telecom is not involved.
But I guess that's another thing they don't want to test in court and it's easier to say they don't want it.
The LGPL license doesn't work that way. The rights that it establishes follows every time you transfer the work between legal entities. If I transfer the work to you, I need to extend the rights granted in the license to you. I can't expect others to do it for me.
I think your guess is correct. GPL/LGPL is a contract that puts certain obligations on all parties; just by being a redistributor, Unity now becomes a party to a contract they never signed or even intended to sign.
It's easier for them to refuse to be a party to that contract by not allowing any software under that license on their property to begin with.
My guess is that they want packages on the Unity store to be usable on all platforms they support.
For example, if you build an app for iOS or visionOS, you have to distribute it via Apple’s stores, and there are technical barriers (code signing, DRM) that get in the way of an end user being able to exercise their right to replace LGPL components with modified versions. I mention this example because there was a big tie up for Unity and visionOS announced with the Apple Vision Pro last summer, but presumably the same applies to Unity games on consoles etc as well.
I can see why from Unity’s perspective it is cleaner to just forbid LGPL entirely, that way it is harder for their customers to mistakenly violate licenses.
> there are technical barriers (code signing, DRM) that get in the way of an end user being able to exercise their right to replace LGPL components with modified versions
I wonder if that is an issue for LGPLv2. Pretty sure that for LGPLv3, the distributor would have to give instructions explaining how to do it (which they could not do), but LGPLv2 does not require that, right?
As in, wouldn't code signing and DRM count as some kind of tivoization?
Would it worth a try reporting other LGPL violations to Unity - as drawing attention to violations of their own 5.10.4 of Provider agreement - in a documented manner? Just to see how they proceed.
intredasting, they rather explicitly appear to be tilting against viral licensing:
> 5.10.4 Provider represents and warrants that its Assets shall not contain (a) any software licensed under the GNU General Public License or GNU Library or Lesser General Public License, or any other license with terms that include a requirement to extend such license to any modification or combined work and provide for the distribution of the combined or modified product’s source code upon demand so that Customer content becomes subject to the terms of such license; or (b) any software that is a modification or derivative of any software licensed under the GNU General Public License or Library or Lesser Public License, or any other license with terms similar thereto so that Customer content become subject to the terms of such license.
LGPL doesn't impose combined redistribution requirements, does it? They're just tilting against that whole ecosystem specially. And if you apply the same standard as LGPL, MIT/BSD are basically the same right? Probably CDDL falls in too? that's absolutely a crazy thing but it's pretty straightforward in the licensing agreement.
LGPL is a regular license, it is not a viral license.
GPL is a viral license.
The GNU glibc uses LGPL and almost any program run on a Linux system uses glibc, regardless in what programming language it has been written, at least for the system calls. If LGPL had been a viral license too, all programs would have been affected.
> LGPL is a regular license, it is not a viral license.
> GPL is a viral license.
The LGPL's level of "virality" is small, but nonzero - it imposes requirements on a larger program of which you use LGPL code as a part. Those requirements are much smaller than the requirements imposed by GPL code in the same circumstances, but they are real, and much more substantial than e.g. including a copyright notice.
> The GNU glibc uses LGPL and almost any program run on a Linux system uses glibc, regardless in what programming language it has been written, at least for the system calls.
glibc has an explicit linking exception for programs using its public interface.
Doesn't the LGPL give users the right to replace the LGPL part with a modified library of their choice? It seems doubtful that users can modify downloaded Unity apps at their leisure, so that would mean that LGPL cannot be supported on Unity, wouldn't it?
Though then it would seem that LGPL libraries on almost any app store are being used against their license terms, so I must be wrong.
The obvious way to comply with LGPL is to link dynamically the LGPL libraries, even if everything else is linked statically.
I am pretty sure that the Unity executables link dynamically glibc anyway.
The alternative is to do the static linking in 2 steps. First link everything else into a big ELF object file, then do the final linking of the LGPL libraries.
For compliance with the LGPL, it is enough to provide access to the big binary object file, so that a user may relink the possibly modified LGPL libraries, if desired.
A dynamically-linked executable and an object file that needs a final static linking step with additional libraries have almost identical content and they provide equivalent information.
Sometimes even dynamic linking might be not enough - on iOS you can build dynamic frameworks that are dynamically linked but they are signed with developer provisioning key when distributed via App Store. AFAIK there is not other way for end user to swap such dynamic framework/library unless developer will provide source code or object files or compiled code (e.g. in other dynamic framework that links dynamically to such LGPL code). Not sure about jailbroken iPhones.
Also for more complicated iOS projects (that require iOS capabilities e.g. in-app-purchase, push notifications, app pay, icloud etc.) end user would need to have a paid apple developer account to create and sign build.
That is irrelevant, look at the way the clauses are structured:
> (b) any software that is a modification or derivative of any software licensed under the GNU General Public License or Library or Lesser Public License,
> or any other license with terms similar thereto so that Customer content become subject to the terms of such license.
it's not a question of terms similarity in that clause, it literally forbids any usage of GPL or LGPL by name. These licenses are "name banned", not just by "features". You can't have GPL or LGPL, nor can you require clients to sublicense you to GPL/LGPL for your program to operate, or any other license that has similar propagating terms to sub-licensed entities.
Obviously you can turn the world on "terms similar", h265 user/device licensing or whatever isn't terms similar here. But just by the plain text it's very obviously a direct swipe at GPL and viral licensing, they're banned by name, at minimum they probably want to see BSD/MIT I guess.
> Though then it would seem that LGPL libraries on almost any app store are being used against their license terms, so I must be wrong.
You are not wrong. LGPL does require that you provide users the ability to link against a modified version of the LGPL library. It is a requirement that has been rather honoured in the breach in this age of appstores
> LGPL does require that you provide users the ability to link against a modified version of the LGPL library.
That's correct for LGPLv3, but I believe LGPLv2 is more nuanced.
With LGPLv2, I don't think it requires that you provide the ability. It has to be possible if you get access to the executable (which may require that you jailbreak your device, for instance). For instance, it is my opinion (not legal advice) that it is fine to use an LGPLv2 Java library in a proprietary Android app, because you can technically go replace the class files corresponding to the LGPLv2 library in your apk. It's not easy to do (unlike swapping a dynamic library), but it is possible.
On iOS things are even shadier, since iOS didn't allow apps to use the dynamic linker until iOS 8(?), and you have to pay Apple $100 for the priviledge of deploying the resulting app on your own device...
But you don't have to publish that modified apk to Play Store. You can just sign it with your own key and install the apk manually, no root needed.
I know there are some apps that do its own cryptographic signature verification on their own, but most apps don't do that, so replacing a LGPL library in an APK is actually feasible in most cases. It is not hard to do so either.
They must be signed to be on the store, but I don't think it's impossible to run unsigned apks on the device (maybe you need the developer mode, though).
But even then, wouldn't that count like tivoization? LGPLv3 says you need to provide instructions to replace the lib, but LGPLv2 does not. Couldn't I say "I honor the LGPLv2, because it would be technically possible to update the library, but unfortunately for you it is behind some tivoization that you would need to break first"?
This isn't a linguistic disagreement, LGPL and similar licenses are literally forbidden by the direct plain text of the agreement.
> (b) any software that is a modification or derivative of any software licensed under the GNU General Public License or Library or Lesser Public License, or any other license with terms similar thereto so that Customer content become subject to the terms of such license.
The complaint was not that it is not true that they have not complied with the agreement, but that this rule is only selectively enforced and that nobody truly complies with it.
Moreover, the rule has no rational reason, because unlike with GPL, compliance with LGPL is very easy to achieve, even for proprietary programs.
The rule is completely rational. It is impossible to use LGPL-licensed components on the Android app store or Apple app store without becoming infected with the full GPL. (As extensively discussed throughout this thread).
At the risk of seeming pedantic, the proper term is copyleft, not viral licensing. If memory serves, viral licensing has its origins in Microsoft fear-mongering (predating the modern positive use of viral, as in go viral).
> LGPL doesn't impose combined redistribution requirements, does it?
It does, in that if you modify the source-code of an LGPL-licensed library and distribute the binary, you are required to also distribute the source (i.e. the source of your modified version). Your modified source must also use the LGPL licence.
If you distribute an unmodified binary for an LGPL-licensed library, you must also provide access to the unmodified source. (This isn't to say you need to bundle it into the same archive file.)
It differs from the vanilla GPL in that an LGPL-licensed library permits you to dynamically link to it from application code that doesn't need to use any particular licence.
(This is at least the gist of the matter as it applies to application code. This isn't legal advice, I'm not a lawyer, etc.)
It's not just my preference, anyone familiar with this area of copyright law recognises copyleft as its standard name. Viral licensing is, as I said, a snarky pejorative. [0][1]
It's also less precise. Proprietary licenses can be 'viral' too. DRM libraries, for instance, may require that application source code not be made publicly available.
> At the risk of seeming pedantic
Parroting others in this way comes across as juvenile and antagonistic.
The rational is that you should be able to just install any asset from the store in your game and be good to go. With an LGPL asset now you have to let customers be able to edit that addon and rebuild your game with it which would be a pain, and most developers do not want to give out the unity project files.
Having a simple licensing story for assets on the store lets users have trust in whatever they see they can use in their game worry free.
Edit: Removed bit about LGPL applying to the original code because of static linkage because it was incorrect and distracting from my point
Only linking with a GPL library makes GPL applicable to the whole program.
This is the difference between LGPL and GPL. LGPL is a normal license that applies only to the library.
Since glibc uses LGPL, if your theory had been true than almost all programs run on a Linux system, regardless of their origin, would have been covered by LGPL.
The LGPL code gets statically linked with the rest of your code which means that you have to provide the project files in order to be able to change the LGPL code.
No, you do not have to provide any project files, even when everything is linked statically.
Static linking can be split into two linking steps, first everything except the LGPL libraries can be linked into a big ELF object file, which no longer contains any information about the internal structure and the internal symbols, exactly like an executable file. The only difference between such an object file and an executable is that it contains unresolved external references, like a dynamically-linked executable.
Then in the second and final linking step, the big binary object file is linked with the LGPL libraries.
For compliance with LGPL it is enough to offer access to the big binary object file for the users who would want to replace the LGPL libraries.
Please do not forget that we are talking about Unity. Unity doesn't let you split up linking like that. All the game and asset codes gets mixed together in a single step. Needing to split out and rig together some hacky solution is the reason why they don't want it in the assert store. As I said in my original comment Unity wants assets to be low friction to add to your project.
As a side note, I believe that LGLv3 says that you have to provide instructions about how to do it, but with LGPLv2 is just has to be technically possible if you have access to the binary.
Just a few remarks: VLC-Unity plugin is fully open source, and anyone skilled enough can build it themself.
We've tried for months to discuss with Unity and it was a nightmare. We've had discussions for years with Apple AppStore, Google Play store, and Windows Stores (including Windows Mobile + UWP). It's always challenging, but Unity was a headache an order of magnitude bigger: no answers, 3 different answers contradicting each other, and plain bad faith.
De facto, they use LGPL and open source to build their platform, but we're not allowed to have open source on the store? Not even LGPL with a layer of a different license? Why us? Why not the other people doing it?
Very frustrating.
So, yes, because some people need to buy support or licenses, even if everything is open source (don't want to build themselves, purchase department that needs a support contract, etc...), they need to have a small store. This is different from what we see usually, but there is a need, so this is a small store for that.
For most of HN users, you should just build it yourself. You should be skilled enough for that :)
The only way to get a consistent response from Unity is paying support.
Their store review queue takes months, now with the layoffs it will only get worse.
They are hurting themselves by not having your plugin. Feels like they are building their own solution but I bet it will take years to release and will be broken.
Unless you are selling the plugin, you shouldn't care. You can host it anywhere and the community will find it.
The LGPL gives end users the right to replace the LGPLed part with a modified version, and users presumably cannot alter parts of a downloaded Unity app. So it does seem that software using an LGPL library cannot be distributed on Unity or most any modern app store and still be in compliance with the LGPL.
It's not viral, but it does give users rights that aren't natural under the app store distribution model.
I can give you a right, but that doesn't mean you're neccessary able to excercise that right. I can allow you to drive a tank on my property, but you probably can't afford one, and it would be banned by laws.
I'm curious, does the LGPL state explicitly that the licensor guarantees that the licensee can excercise their granted rights in practice? There can always be external circumstances restricting what I can do.
Or is it more like: The licensee (the unity package developer) can only use the code (VLC) if they guarantee that the sub-licensee (the package user or the end user) can excercise all their rights with no external conditions?
Edit: I think LGPL 3 actually does demand this, in the context of preventing "tivoisation". However, libvlc is licensed under LGPL 2.1 as far as I can see.
> I'm curious, does the LGPL state explicitly that the licensor guarantees that the licensee can excercise their granted rights in practice?
It feels like such a requirement would mean you would have to test each potential user for technical skills to determine if they are capable of doing the things that you are giving them the right to do.
I think you are looking at it the wrong way. The licensor doesn't guarantee that the licensee can exercise the granted rights. But the license requires that the distributor can guarantee that the recipient can exercise those rights.
If I write up a license that says anyone distributing my software must give the recipient the right to drive a tank on their property, I can distribute it, because I am the copyright holder and can do whatever I want. But in practice that software cannot be redistributed, because those license terms probably cannot be fulfilled by any redistributors.
If VLC wants to put something on the Unity Store that includes LGPL code, then their responsibility (and the Unity Store's responsibility, as they are now distributors as well) is that people downloading that Unity VLC bundle in order to use it in their game must be able to replace the LGPL code in it with modified versions. And that part may actually be possible, so this may be ok.
But then the game developer that uses the Unity VLC bundle must also pass along the ability to their end users (that is, the people that buy and play their game, for example) to replace the LGPL code with modified versions. I think that's just not possible with the Unity Store model[0], so the terms of the LGPL cannot be fulfilled.
If this is the case, it's not unreasonable for Unity to ban LGPL code in bundles, because they know that their customers (game developers) will not be able to abide by the terms of the license.
[0] Similarly to how an end-user wouldn't be able to replace LGPL code in an iOS app with a modified version and then run that on their iPhone, at least not without paying Apple for the privilege, which is an added restriction that violates the terms of the LGPL.
IANAL, but when it comes to contracts/licences, intent, good faith and fair dealing are important. Allowing someone a right that you know cannot be exercised would likely fail under all three of those. Your intent is not for them to have that right, you're not acting in good faith in claiming they have the right and you're misrepresenting the possibility.
The law is not as prescriptive on the exact text as many programmers think. What typically matters in court is what people mutually understand/understood terms to mean, and clear attempts to mislead are typically judged against the one doing the misleading.
So, yes, if it went to a court that was otherwise supportive of (L)GPL, providing (L)GPL code on a platform on which users certainly cannot exercise their rights would likely be a failure to provide and hence abide by the licence.
It's not impossible to comply with LGPL under the app store model, but the responsibility falls on the distributor, which is Unity in this case. I can understand that that is something they are not able or willing to do. This doesn't mean that they can't comply with LGPL for components included in Unity itself. I don't see any double standard here.
I don't have experience with tinkering with typical Unity apps. But we have one at work and on Linux it literally has the `.so` files for native libraries in a standalone directory (including one LGPL library that we use) which you can easily replace with a differently compiled version if you so desired.
> The LGPL gives end users the right to replace the LGPLed part with a modified version, and users presumably cannot alter parts of a downloaded Unity app.
You can use LGPL software on a multitenant mainframe system, where you don't have access to modify installed software. This was a well known use case in the 80s and 90s, so this doesn't seem appreciably different. The LGPL doesn't seem to require you as a software developer to ensure that the user can run the modified software on the same system on which the App Store version is run, mainly it's to make the source code available so they can, in principle, create a modified version that they can run somewhere.
LGPL leverages copyright and is triggered under distribution/copying. Users of a multitenant system are not receiving a copy of anything. At least this is how GPL2 worked. I don't know if 3 substantially changed that.
What you're describing sounds more like the AGPL to me.
If that were true, then if Unity decided to ban MIT and Apache licensed software from the store, that would mean that MIT and Apache are actually kinda shit. Seems there's a pretty clear error in your logic.
Also, your appraisal seems to be assuming that the only goal of the GPL/LGPL is to release software through Unity, which is not correct.
Not a video game developer - but I wonder if it'd be a good call for videolan to make a vlc plugin for godot? It's still gaining momentum and (afaik, could be wrong) have the same thing as unity with a inbuilt media stack but it's fairly limited.
Note that 1. this is mostly regarding the Steamworks SDK that you link to; sufficient care may be taken to try to make this linkage to Steamworks "compliant" as noted in the article, and 2. this is about GPL, not LGPL. Distributing LGPL code via Steam may introduce some potential murkiness, but it should be mostly kosher since I think Steam doesn't, in and of itself, impede on the user's ability to exercise the rights granted by LGPL.
Games and applications distributed on Steam don't have to integrate with Steamworks SDK at all, and when they don't this licensing issue doesn't apply.
They still can publish their assets outside of the Unity store. Users can download them and install them in Unity. But I agree it's not a nice move from behalf of Unity.
App stores (or generally moderation) is a complex thing to get right.
Once you have humans in the loop, you have bias. Not even humans can follow the set ambiguous guidelines and the appeals process is mostly broken.
AI can somewhat help but language models are just that - language models - they don't have any deep understanding.
Fundamentally I believe moderation will always be broken until we get algorithms capable of understanding the deeper meaning of things and apply them uniformly.
Most of the good people have left Unity or have been laid off. Whoever remain are likely ill equipped to deal with anything. So I see these kinds of decisions as the death throes of the company.
Contextual note on VLC (and Videolan) their stance on software patents is well known[1] and not something people who either want software patents or are attacked by software patents will take on.
LGPL is specific to the library. A proprietary application can ship with an LGPL library, as long as the library hasn't shipped with proprietary modifications.
But Unity can’t do that because it transpiles code on build… simply linking using LD wouldn’t make you have to adopt. Any modifications would, and would have to be published in source code form.
unity only does transpiling for C# to native code if you enable it in your project. it cannot transpile the (presumably) linked native library so this shouldnt be an issue here
“Generally, dynamic linking of LGPL code is considered best practice, as static linking makes meeting the license requirements more complicated. While it is possible to comply with LGPL code that is integrated into proprietary code as a statically linked library, it requires more effort. There is a kind of safe harbor for using LGPL code as a dynamically linked library; for statically linked libraries, a distributor must offer access to not only the library’s source code, but other information or materials necessary to rebuild the program.”
This makes IL2CPP kinda hairy in Unity-land. Since it’s being modified to static-link, it must be released as source. So no, I don’t think I’m confused at all.
IL2CPP should affect only .NET libraries, it won't do anything to included native code .dll,.so libraries. I would expect that in 80% of cases the LGPL librararies you might want to use are actually written in C or C++ so they would still be dynamically linked even with IL2CPP.
LGPL has nothing to do with IL2CPP, even when the library is statically linked.
Regardless how Unity might transpile their applications, they must be combined with a LGPL library only after everything has been converted into binary object files, by the linker.
In order to comply with the LGPL requirement that the user must be able to rebuild the application after possibly modifying the LGPL library, the only thing that must be provided is the linker command line that creates the final static executable.
No other information about the proprietary source files or about how they are compiled needs to be provided.
If it is desired that no function names should be leaked from the proprietary code, everything except the LGPL libraries can be pre-linked into a big binary object file without information about the internal symbols, which can be linked with the LGPL libraries only as a final step for generating the statically-linked executable.
In this way, there is absolutely no difference in the information provided when static linking is used and when dynamic linking is used.
The claim that dynamic linking is necessary with LGPL libraries is completely wrong, because linking them statically, but only after linking the other libraries, is completely equivalent.
>In order to comply with the LGPL requirement that the user must be able to rebuild the application after possibly modifying the LGPL library, the only thing that must be provided is the linker command line that creates the final static executable.
It's not an MBA jerk, it's just party grows in size and becomes visible to the judicial system, therefore susceptible to adult problems such as lawsuits from FSF.
That doesn't make it a hit piece. A hit piece is when you are slandering someone unfairly, not publishing something un-noteworthy.
I suppose I don't know whether TFA is being unfair, but I have no reason to doubt what they say, and calling this a hit piece is a bit of a leap for me.
I find the negative reception here confusing. Seems to me they got removed from a marketplace, so they launched their own. They put the announcement into an article about the thing that motivated what's being announced. That is generally what you do, because otherwise the article would leave you with the impression that you have no option going forward, and a follow-up would reach fewer people. Just doesn't make sense.
Also, I'm no Unity expert, but C# integrations generally use PInvoke right? It's the most dynamic of linking, there's really no inherent reason LGPL libs can't be used in Unity games. At worst, Unity should make sure you know your obligations, but I don't understand the necessity of a blanket ban. I'd be very surprised if VideoLAN, a well-respected organization that has been doing open source work for a very long time, had such a fundamental misunderstanding of the software licenses they use.
Either way, a request: please stop using "clickbait" to describe literally anything you don't like. The article is chiefly about their ban, even the announcement is. By all means, critique whatever you want, but that's simply not what clickbait is. Clickbait is more like "actually we didn't get banned, But..."
> Seems to me they got removed from a marketplace, so they launched their own.
not only removed, but removed with no hope of reconciliation (if the author is to be believed). They offered to remove all LGPL code to comply and were refused. Their entire publisher account was banned over what I assume is one infraction. They made it pretty clear that Unity just didn't want VLC on their store.
This whole system of arbitrary enforcement on an "app store" seems weird to me. Real question: Would our economies be better off with stronger regulation around app stores? In the last one year, I am leaning more towards yes. My thinking: Many small companies are completely beholden to a single app store. If any small thing goes wrong, the business get the middle finder and suffers greatly. It seems like a David and Goliath situation, but Goliath drives a Leopard 2 tank and David still has a sling shot.
Idea: What if there were some minimum, legal requirements for app stores? Example: If the app store owner enforces a rule, it must be enforced equally on all apps. (Obviously, that did not happen in this case.) If complaining / escalating due to unfair treatment is not remedied, there is a neutral gov't board that can make a ruling. This is not unlike labour union relations in countries with strong labour laws.
We're hearing one side of the story here, so who knows, but looking at it from Unity's perspective...
Unity doesn't want to have be the "cops" and "prosecutors" who have to go around to find, investigate, adjudicate and enforce violations in the store agreements. They want partners who, having agreed to the store terms, will make reasonable efforts to adhere to them.
E.g., Unity may have come to the conclusion that VLC violated the terms of the store agreement not by simple mistake or a reasonable different interpretation of the agreement, but on-purpose or through negligence. In that case, the reasonable thing to do is to simply stop doing business with VLC (if it's not too costly to do so), because of the relatively high likelihood it will happen again.
Don't forget that Unity could be sued for violating the terms of LGPL'd software. If they "have received a report" of an LGPL violation, they have to take it seriously. Any future lawsuit would likely be more successful if they had previously received a report of a violation and did not resolve it..
Except that's not what happened at all, at least per the article they use LGPL and have LGPL code all over their store, and refuse to work with the OP at all over the issue.
Unity are absolutely to blaim here, this is indefensible.
If a license violation is reported and Unity ignores it their legal risk is higher than for violations no one has reported. The report forces their hand, to a degree.
From the post: "Enforcement is seemingly totally random, unless you get reported by someone, apparently." ... which is another way of acknowledging enforcement isn't random. The report matters. That's what moves the responsibility for adhering to the license from the asset provider (VLC in this case) to Unity.
BTW, "other people are doing it too" isn't a great excuse for violating license terms. If that was OK, then licenses would be generally be almost meaningless.
Regarding Unity's direct usage of LGPL code, that's on them. They need to make sure to honor the LGPL license. Nobody made the claim they weren't, so I'm not sure it's relevant.
Here's another bit from the post that I thought was telling: "After months of slow back-and-forth over email trying to find a compromise..." What compromise? If you find out you're violating an open source license you stop as promptly as you reasonably can. It's not a matter of negotiating with Unity -- that's a separate agreement. It sounds like they eventually came to the right conclusion re the LGPL components, but why was honoring the LGPL license even in doubt? It makes me think they aren't really sincere about open source licenses (and maybe other licenses or any kind of agreement). Note, this point is entirely independent of Unity and whether or not they are screwing VLC. When distributing binaries built with LGPL code, they have a responsibility to honor the license, but only seemed willing to do so reluctantly and belatedly, after pressure from a business partner.
You can't simultaneously claim ignorance and the moral upper hand. Unity knows they are generally in violation/does nothing, then refuses to work with folk?
No.
The OP could have been in the wrong, yet they are willing and capable to make change. Unity has no such defense, merely a combination of laziness/ignorance. Neither of which are a starting place for anything approaching a reasonable defense.
> ...if they had previously received a report of a violation and did not resolve it..
"Resolve it" would include working with the offender to remove the LGPL violation. They could easily document the process and demonstrate a good-faith effort to comply.
Sure, Unity is well within their rights to kick Videolan off their store. It's the cheapest way to comply: no need to collaborate with store vendors and put any hours into that sort of thing.
But that's all it is, a cheap way to comply. It's the laziest form of compliance at the expense of their own customer experience.
>Either way, a request: please stop using "clickbait" to describe literally anything you don't like.
Preach on. This is one of the most annoying things, to me at least, here. If there is a post with more than 10 comments, there's a very good chance one of those comments contains "clickbait".
The word has lost all meaning to me at this point.
I disagree in general (although I agree this article isn't clickbait).
the internet runs on clickbait and HN's insistence on reflecting the title of the content itself means a lot of things that are posted are legitimately clickbait.
In your opinion, what makes your example article title clickbait? Is it using the word "shatters" as opposed to "more than doubles"?
Maybe I'm just stuck on an old definition or something, but in my mind, clickbait refers to a headline that is purposfully dishonest about the content of the article. Having an eye-catching title doesn't mean it's clickbait if the article delivers on what the title says.
I guess I would also classify any title that doesn't give any representation of the article content as clickbait as well. "Airbus shatters records", as an example, wouldn't give any indication of what records were shattered, thus baiting clicks.
But, maybe the word has evolved to refer to any non-boring title and I just haven't caught up to the times.
"doubles" is accurate but not as strong in the mind of the reader.
it's like seeing an entry in youtube titled "person x DESTROYS person y" and it turns out it's just your normal, everyday, point/counter-point discussion.
It's meant to increase the odds that you click, and that's literally what clickbait is.
In Unity games on platforms like Windows, Linux, macOS sure - but one of the advantages of their toolkit is supporting porting to many platforms, like PlayStation, iOS, etc where the platform vendor store model’s DRM & code-signing gets in the way of end users swapping out dynamic link libraries.
I find the negative reception here confusing. [...] Either way, a request: please stop using "clickbait"
You're better off directing this stuff to whatever negative reaction or word usage you're referring to otherwise you get a subthread of meta/ants. Or for even less effort required, just skip it. Almost all comments are greatly improved by meta-elision.
The LGPL includes the entire text of the GPL license, with an additional exemption for linking.
If you are unable to meet the conditions attached to the exemption, you are then governed by the terms of the GPL without the linking exemption.
The specific topic at hand is that Google and Apple app store applications cannot meet the conditions attached to the LGPL linking exception, which requires that LGPL components must be user-replaceable. So they are therefore governed by the terms of the GPL without linking exemptions.
The sudden disjoint between story, and selling you a thing does seem very click baity.
I think it's because they didn't stay in story mode. "So we decided to set up X..."
To me it reads as if the company has been around for a while and this story has been dug/made up purely to sell a product. And we should expect 15 more of these.
I suspect it's just bad/honest (?) Writing though.
The article said they got banned from the Unity store several months ago and tried for months to reconcile the issue, and now they have come up with a solution for their customers in the wake of the banning. They even included the correspondence from Unity in their article, so barring Unity coming forward with evidence of double dealing on the part of VideoLAN I struggle to see how "this story has been dug/made up purely to sell a product".
Without some evidence your conclusion seems to be a hand wave.
>"this story has been dug/made up purely to sell a product"
No I said that's how it reads, Its why i suspect that people are saying it's click bait.
My actual conclusion comes in the following paragraph.
This is actually interesting from a marketing perspective.
We all understand that marketing is there to sell us stuff. This is making us aware of a product, so it is in that sense at least, marketing. But then people don't like being 'sold to', at least they don't like noticing.
This takes the form of 'marketing' that we don't recognise as such, but the disjoint puts it into an uncanny valley where it annoys people more than it objectively should.
If you actually read the very long ad, you’ll realize they’re promoting all the unrelated stuff, mainly their consulting packages. The only thing not mentioned is VLC for Unity, you wouldn’t even know it’s in the Store without clicking though. Nobody gets roasted for saying “by the way, you can get this banned product from <place> now”, this is some next level shit that makes people question your integrity and your one-sided story.
Edit: Apparently some people can’t understand what I mean by “the very long ad”. It’s everything starting from “Introducing the Videolabs Store”, not the whole article.
To be completely fair, their plug-in is still freely available. After being kicked off by unfair and unreasonable (uncompetitive?) practices, it's not unreasonable to say "hey they suck so we are doing our own thing over here". If someone robs you it's not unethical to set up shop elsewhere.
Asking for money for support is entirely reasonable as well.
What you call "the ad" follows naturally from several paragraphs explaining the circumstances motivating the creation of their own store; unity banning them. Whining about this is totally bizarre.
It was sarcasm, the article is basically "we got removed from the Unity store, so we made our own store, where were selling consulting! Consulting consulting consulting, for you and your company, so many consulting packages for all your consulting needs! Also VLC is there."
They outlined the issue and even included correspondence from Unity. The first half is a story, the second half is an advert related to that story.
Frankly, I have much more of an issue with all the paywalled stories being posted here than a small company plugging its own products after a relevant post.
I don't have much of an issue either, I was just explaining the sarcasm in the parent comment. I would have liked a format of "We launched a store and put VLC on it, and also you can get consulting there", though.
This comment section is so interesting. It's a great example of the value of PR; that it's not what you do that's important, but how you frame it.
How VLC should have framed this post:
1. Our plug-in got banned from the Unity Store for what we believe are bad reasons. Other high-profile plug-ins with LGPL code are still there.
2. To ensure that our users can still get our plug-in, we set up our own store which sells the plug-in.
3. Also the store has all these other services you can buy.
But they omitted the second part. And the simple act of not explicitly connecting the store to the plug-in ban through enough PR speak seems to have been enough to make people here characterize this blog post as simply an ad for their store.
After months of slow back-and-forth over email trying to find a compromise, including offering to exclude LGPL code from the assets, Unity basically told us we were not welcome back to their Store, ever. Even if we were to remove all LGPL code from the Unity package.
Where it gets fun is that there are currently hundreds if not thousands of Unity assets that include LGPL dependencies (such as FFmpeg) in the Store right now. Enforcement is seemingly totally random, unless you get reported by someone, apparently.
Non profit doesn't mean all the employees work for free. Your statement is the equivalent of saying "The Red Cross don't need money, they're a non profit!"
Equally one possible line of reply you could have offered is some evidence that they were dependent. When neither side can produce evidence it seems fair to me to fall back on some clear deductions, which I won't repeat.
Honestly this debate seems like a waste of time for both of us. I'll leave it here, and I hope you have a good day.
You claimed they weren't dependent, not me. My comment, paraphrased, was "How can you be sure without evidence?"; I don't know if they are dependent, not enough information.
How so? Their statement was that not that VideoLAN does not need money, the statement was they do not depend on the Unity store to get enough money.
Nobody claimed non profit means working for free or even went into that direction.
The statement "They did not _depend_ on Unity." is not equivalent of saying "The Red Cross don't need money, they're a non profit!". Or which statement did you refer to?
Please be less enraged and try to understand the arguments of others in discussions.
I'm not enraged, my point was simple; without knowing what VideoLAN's revenue looks like you can't say for certain that VideoLAN don't actually depend on it. Say for example VideoLAN got 75% of their revenue from the Unity Store and then they got banned; I would say that is a case of dependence. Without such knowledge it is very difficult to say with certainty whether VideoLAN is dependent on their products being available on the Unity Store.
Nothing to do with being "enraged"; in discussions it generally doesn't help to attribute motivation without evidence.
Sorry for attributing motivation without evidence, I regret that and think you are right on this point.
Now I got your point concerning the dependence. That was not clear to me before you elaborated and I don't see how I could have inferred that.
It is highly unlikely though that this integration into a game engine made any significant revenue in its 3 years of existence if you ask me. The integration is also still available, just not distributed via Unity store.
As VideoLan is a non-profit I tried to find info on their income to get a bigger picture, but failed to find that.
> without knowing what VideoLAN's revenue looks like you can't say for certain that VideoLAN don't actually depend on it.
This is a matter of how someone might interpret "depends".
If you meant "effectively will cease to exist", that is incorrect.
If you meant that VideoLAN depends on Unity the same way I depend on the 5 dollars in my pocket to be fungible...VideoLAN still exists without Unity, same as I exist without the 5 dollars in my pocket.
Right, I think this is a nothingburger - they 'depend' in the sense of leaving it up to Unity to honor a defined set of responsibilities on their side of a relationship. I think there was no need to get into whether this posed any sort of existential threat to VLC.
Just as strong as "dependency" is usually used in software engineering, not? They swapped out a dependency, so now they don't depend on the unity store any longer.
I agree that it came off as a bait and switch. Having looked a bit deeper, the plugin is open source and you can download, compile and distribute it for free. They charge for the precompiled binaries that you can get in the Unity Store (now videolabs store).
If we were already aware of all this then this wouldn't have come off in the same way. The problem is that due to the way it was written I think most people expected the plugin to be free on the store. Personally I think it just could have noted that the general interest section of the article was finished when they segued into the store announcement.
Anyway, assuming everything is as they say then it seems pretty clear that Unity have some other reason for banning it, most likely commercial.
I get how that can seem very jarring. On the other hand, VLC has single handedly solved the "how do I play all the world's weird ass video/audio files" for free with no gotcha's for years now.
I think they're more than entitled to try and advertise a little bit. It's not like they're doing anything evil asking for some money. You can still go download all the code yourself and build it manually for free if you want.
Literally what about the title is click bait? They got banned from the Unity store and they expose a clear double standard in Unity's enforcement. Exactly as the title suggests.
The negative reception here is absolutely incoherent.
3. "We explain why this seems like a double standard"
4. "We made our own store where people can get our plug-in now that it's not in the Unity store"
IMO the only thing wrong with the blog post is that it's missing a paragraph after the "Introducing the Videolabs Store" heading. There should be a sentence or two there about how people can now get the Unity plug-in through the Videolabs Store before they go on to talk about everything else people can get there.
You left out half of the article (I’m definitely not exaggerating here) about consulting packages and other products in your “essentially”. Yes, the article would be a lot better without the half you also seem to believe doesn’t belong.
When the store is introduced, listing the services which can be bought through it is only natural.
I am 100% convinced that neither you nor all the other people would have such a negative reaction if there was a simple connecting paragraph which explicitly connects the plug-in to the store in some PR-y "we care about our users" kind of way.
It is not at all natural to dedicate half of the text to unrelated promotions in a negative piece about another company. When you do that, some people assume you’re taking the free publicity to promote unrelated stuff. As I said in another comment, it’s totally natural to mention <banned thing> is now available at your own store. It’s okay to briefly call attention to other products as well. But a long piece filled with marketing speak is not the way to do it.
Anyway, I’ve wasted enough time on the marketing BS, I’m not going to respond further.
Are you suggesting that VLC is lying about the communication from Unity, including faking the screenshot (or lying by omitting other e-mail)? Or are you suggesting that Unity is lying to VLC about the reason for the ban?
I'm not a moderator so you have no obligation to listen to me, but I'll make a request none the less: please consider only commenting when you've something to say that adds to the conversation in some way. The HN guidelines are pretty good at steering people towards contributing in positive rather than negative ways: https://news.ycombinator.com/newsguidelines.html
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?