Clearly, the legal team got bad information and made it part of their agreement. Like the article says, not only do tons of Unity assets use LGPL dependencies, but Unity uses LGPL assets themselves. Even shipped games created using Unity use LGPL assets. The intent was probably only to screen out GPL dependencies. For those who don't know, there's a huge difference between the GPL and LGPL. The LGPL is specifically designed to allow proprietary applications to link to open-source libraries without requiring the proprietary application’s source code to be released, provided certain conditions are met. This is particularly true when the LGPL-licensed library is used in a way that allows users to modify or replace it independently of the proprietary application.
In contrast, the GNU General Public License (GPL) has stricter requirements. If your software incorporates GPL-licensed code, the entire derivative work must also be licensed under the GPL, which includes releasing the source code.
I don't know much about the way unity apps are distributed, but I'd be a little surprised if they are only intended to be distributed in a way that satisfies LGPL.
I would have thought, e.g., that apps distributed only through stores to platforms that require apps to be signed could not contain LGPL components, since you would not be able to modify the LGPL components. (Maybe it would be OK if the software was available for download freely and side loading wasn't too difficult??? IDK.)
Legal specifics aside (IANAL after all), my general point is that despite being more flexible than full GPL, LGPL is still pretty restrictive. Proprietary software generally may need to keep things simple or be careful (probably including consulting an attorney with the relevant expertise) to ensure they are compliant.
In that light, I can see why Unity would disallow LGPL software. It's not that it couldn't be done properly, but that it's probably not feasible to do a proper legal review of every asset added to the sure (not for Unity and not for the asset providers).
> require apps to be signed could not contain LGPL components, since you would not be able to modify the LGPL components.
You COULD make the changes, but you MUST keep the changes to the LGPL'd software made available in some way. This is not going to affect the rest of your project, only the LGPL'd library. I think not including any private keys or signed files will still satisfy the LGPL as long as any code changes you made are included. I don't think configuration that compromises your security is within scope, and I'd feel like RMS would agree there.
Its really interesting the goal of the LGPL is to allow for LIBRE libraries to exist where there's proprietary components that already do a solid job, so in order to convince people to use GPL / LGPL tools / libraries it was thrown in that umbrella.
The FAQ is worth a read every now and then, you get a feel for what is intended in plain English.
I believe the GP is referring to the LGPL requirement that users be able to replace LGPL components with modified versions.
Being able to replace subsystems of a signed application with arbitrary third party code adds complexity and is a security risk, but is a requirement of the LGPL.
I think modernity has complicated things. The proprietary vendor signing all the binary components to prevent tampering is different from the platform package manager and kernel requiring signed packages/pages. If you have the proprietary blob and a bunch of modified third party dynamically loaded components, you (or the platform) can re-generate your own signature over the modified composition to execute it in {context that requires signed code execution for security/integrity}. The LGPL is addressing the former. I don’t see a spirited problem with the latter.
I’m trying to work out if an app was distributed with a service that ran in a separate process, e.g via XPC service on Apple platforms, could LGPL libs be legally statically linked only to the service code, which would be open sourced. The service and main app would not be linked at compile time so LGPL wouldn’t apply to the main app, which could remain closed.
> I would have thought, e.g., that apps distributed only through stores to platforms that require apps to be signed could not contain LGPL components, since you would not be able to modify the LGPL components. (Maybe it would be OK if the software was available for download freely and side loading wasn't too difficult??? IDK.)
IIRC, That's a difference between LGPLv2 and LGPLv3 - LGPLv3 has the same anti-tivoization clauses that GPLv3 has - while LGPLv2 does not. So afaict, it's totally OK to distribute software in ways that does not allow the user to modify the library when that library is licensed LGPLv2.
VLC is licensed under LGPLv2.1, which is not subject to the tivoization clause.
> So afaict, it's totally OK to distribute software in ways that does not allow the user to modify the library when that library is licensed LGPLv2.
Legally that might be true, but that interpretation stands directly opposed to the intention of the license. In that light, it is unambiguously unethical to use that loophole.
Many, many people license under gpl2 only to avoid that tivoization clause. So unless there’s a clear indication on the library’s author wishes wrt tivoization, I don’t think it’s fair to make any ethical assumptions here.
Every thread about software licenses always devolves into a firehose of debate and conflicting beliefs. How, in 2025, are we still in a state where, on HN of all places, nobody has any idea what the specifics of LGPL really means or how it has to be implemented? How is it so convoluted, confusing, and up to interpretation?
There's demonstrably room for innovation here - coming up with some new system that actually makes sense, that people can actually understand. I suppose there's licenses like MIT that fall in that bucket. Everyone is pretty clear about something like the MIT license. But the various GPL licenses and other, more custom/convoluted licenses ideally need to be replaced by something much better.
> Everyone is pretty clear about something like the MIT license
I don't think this is really true. I think people are often upset or surprised when their MIT-licensed programs are used in ways they don't agree with, or they reuse MIT-licensed programs in ways that violate their license terms (e.g. it takes many companies many, many years to realize they have to actually include a way for users to view copyright notices).
Open source software is built on many different fuzzy notions of community and collaboration, encoded into an imperfect-but-legally-robust set of protocols that try to establish common language for people to build on. These protocols have proven very, very successful in encouraging collaboration and minimizing exploitation, but there's still a regularization/compromise process that's necessary so that everybody has a common ground to work from.
For another perspective, think about them like security software—I personally might not know why TLS uses DH key exchange, or how it works, but if I threw it out in hopes of making thing simpler, things would probably go pretty badly for me when someone else notices.
> But the various GPL licenses and other, more custom/convoluted licenses ideally need to be replaced by something much better.
What, though? I expect that people with a greater understanding of copyright law and how to write legal documents, have tried and failed. The GPL, LGPL, the Affero variants have specific goals around keeping software open. I don't think writing a license to achieve those goals can be simple or straightforward.
That is legaleze for you, and it not at all surprising that we are still discussing how such a text should be interpreted. Its mostly impossible to create a legal text that has unchanged interpretation for several decades, or centuries for that matter. Just look how courts often discussion the interpretation and enforcement of specific laws, even laws that are older than the judges themselves.
It’s because the genesis of these convoluted license terms is rooted deeply in the archaic copyright law in the US. Until that is fixed, these legal hacks will be necessary.
If you’re not pushing an agenda, you have the public domain or the unlicense as options completely simple understandable options.
Arguably, I do not think that everyone is clear on how MIT works. Huge amounts of software, dare I say most, don't even include a way to view the license, which is a requirement to use MIT.
That Unity itself or Unity-based games use LGPL components doesn't matter. What matters here is what is allowed on the Unity Asset Store. There is nothing requiring Unity to allow everything on their Asset Store that could be linked into a Unity game, and apparently at the time, the Provider agreement simply said: you can't sell LGPL assets on the store.
It isn't surprising or unreasonable that the Store might have additional requirements, and there are plenty of reasons to do so. One is Unity limiting their risks as a distributor of third-party content. Another is that the Unity Asset Store does not require assets sold to be used with Unity, and for some assets it can be allowed depending on the specific asset's license:
On the other hand, not enforcing the LGPL rule evenly against other assets also currently being distributed with LGPL components, on the other hand, is more problematic.
> The LGPL is specifically designed to allow proprietary applications to link to open-source libraries without requiring the proprietary application’s source code to be released, provided certain conditions are met.
It's not that simple. The LGPL says that one must basically be able to make modifications to the opensource library, rebuild the library and be able to reintegrate this new library in the existing application. And you, as a developer using an LGPL library, need to make this "possible". What this practically means, is open to interpretation. This is also why lawyers (and companies) don't like the LGPL, because it contains even more of this "open to interpenetration" text than the GPL.
> What this practically means, is open to interpretation.
Is it? It seems very straightforward to me—just use a DLL. The LGPL even says explicitly that it's fine as long as you use a shared library.
The situation gets trickier for Android or Xbox games I guess. I'm curious how Unity complies with the LGPL provisions there. But for any normal desktop platform this should be trivial to comply with.
EDIT: ah, upthread they mention this is only a provision for the LGPLv3. I would expect that the LGPLv3 is pretty rarely used for this reason.
Afaik not necessarily. You migh make modifications to the LGPL library (such as changing the API) and then use that in your proprietary app.
Although the modified library would still be LGPL, it would be both practically useless to everyone on the street, and unfortunately the (L)GPL doesn't even specify how you must share the source. It's perfectly legal to say 'send us a request and we email you the modified sources'
You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:
- d) Do one of the following:
-- 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
-- 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version."
if your application contains LGPL code then as a user of your application i must be able to make changes to that LGPL code. that means i need either the code of the whole application or at least object files and infrastructure so that i can relink my changed LGPL code to your application.
>at least object files and infrastructure so that i can relink my changed LGPL code to your application.
This part is true but I'd like to emphasize that the infrastructure is on the user to acquire. The distributor of the application is not required to make that infrastructure available.
no, it is. it's explicitly mentioned that the distributor has to provide for instance build instructions.
> The “Corresponding Application Code” for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work.
> If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
The only thing you don't have to provide is e.g. the platform toolchain, headers, etc. e.g. you don't have to ship Windows.h and cl.exe if you are making a windows app that comes with an LGPL library.
i am not sure about that. isn't it required that i get everything needed to rebuild the application? if it's a standard compiler, sure. but any config files, nonstandard tools to link, say if the non-LGPL part is written in an inhouse language with a non-public compiler and linker, you still need to give me the tools to relink the objects. i mean that's very unlikely to happen, but if it does, those tools need to be shared.
are you sure? how is that supposed to work if i build an application with a compiler that i don't have the source for? even for a pure GPL program that can't be a requirement. LGPL requires object files for the non-LGPL parts to allow relinking, but it requires the source for the tool that does the relinking? that doesn't make much sense to me.
"The 'Corresponding Source' for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work."
The LGPL refers to the GPL by reference. I don't think the intent is to recursively require the source code of the entire universe. But the definition of "System Libraries" is somewhat vague, and the undefined term "general-purpose tools" is even vaguer. Would, say, MSVC be a "general-purpose tool", even though it arguably isn't a "generally-available free program"? (And which "free" are they using here?) I can see why many legal teams would be wary, at least.
>> The LGPL is specifically designed to allow proprietary applications to link to open-source libraries without requiring the proprietary application’s source code to be released, provided certain conditions are met. This is particularly true when the LGPL-licensed library is used in a way that allows users to modify or replace it independently of the proprietary application.
That requires the library to be dynamically linked. Not sure if that's in play here.
It doesn't strictly require it to be dynamically linked but does place additional requirements on applications which are statically linked to LGPLed libraries.
> If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
this is not an additional requirement, this is another way to apply the core requirement of the LGPL to the static linking case in C, which is: the end-user must be able to patch / replace the LGPL parts of the app.
>If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
And is this easy? I don't know much about how this works, but would it be trivial for unity to distribute a version of unity with statically linked LGPL libraries where you can also easily relink?
It's as easy as building the project in the first place. Anytime you build your application you also build the object files for it as well.
As an end user having to take those object files and relink them can be difficult for sure, but that's not something the distributor has to do. The distributor simply has to provide some additional files that their build process will already produce.
Of course, those build files won't be stripped, meaning that it would be easier to reverse-engineer them - which might not be something the distributor wants.
As the devil's advocate I'd like to argue that legal is probably more comfortable with Unity's own use of LGPL libraries, because they can ensure that Unity only links dynamically to those libraries. And given how critical these dependencies are to the engine, legal is willing to take the "risk" of allowing LGPL dependencies.
The ban of LGPL in assets on the asset store is probably due to legal being concerned that someone would publish an asset that statically links to an LGPL library and that it would allow anyone to demand the source/object code of any Unity game that uses that asset.
Legal probably sees it as too much effort to vet every asset to see if it links correctly to LGPL libraries and simply instituted a blanket ban to simplify enforcement.
Edit: nevermind, they are in fact affiliated, and most of the core VLC devs work at VideoLabs. I've kept the original comment below.
This blog post links to the "VideoLab Store", hosted at https://videolabs.io, which prominently uses a logo extremely similar but not identical to the VLC (which stands for VideoLAN, not VideoLab) logo. Their homepage even goes as far as displaying "Hire the VLC team" as its headline.
As far as I'm aware, VideoLab has nothing to do with the VideoLAN non-profit, and it very much seems like they are intentionally trying to mislead people into thinking that they are the developers of VLC.
So far, VideoLabs is hiring most of the VLC core developers and those people are the main force of development of VLC. It's setup this way so that if the Videolabs company does not live forever, VLC stays forever free, and the non-profit lives.
This is quite classic of open source projects, and in the case of VideoLAN, there are 3 or 4 companies doing consulting.
Very cool, that definitely makes sense! I've edited my comment, apologies for that. Hopefully bringing attention to the fact that you guys are easily available for hire ends up doing more good than harm.
The harm I imagine would be the reputation damage from people believing that "they are intentionally trying to mislead people into thinking that they are the developers of VLC." NoahKAndrews, having been informed that these really are the devs of VLC, is hoping his earlier, uninformed statement did not cause too many people to think poorly of VideoLabs.
> As far as I'm aware, VideoLab has nothing to do with the VideoLAN non-profit
VideoLabs is a company which has been founded by one of the creators of VLC/VideoLAN and president of the VideoLAN non-profit.
It's basically a for-profit that hired/employs most of the VLC main contributors and pay them a salary to work on that ecosystem while providing consulting and other services to finance all that.
They are significant contributors to the VLC codebase.
After having worked with them in the context of a partnership, I can add that "for-profit" is mostly the legal form but not the mindset.
Well, the author does have a link to the git forge of the VideoLAN project prominently displayed on the blog and also contributes to projects there: https://code.videolan.org/videolan/LibVLCSharp
Videolabs was born from the VideoLAN community and started by maintaining the VLC ports on mobile. It is now the main contributor to VLC, hiring its historical developers, and building custom solutions around the VLC and FFmpeg ecosystems.
From my understanding, using LGPL v2 code in console releases is fine since v2 does not have a tivoization clause (i.e. even if the end-user cannot re-link the program because the platform is locked down, that's still ok).
However, websockify.js (and perhaps other dependencies) are LGPL v3, which means they cannot be included on a platform like the Nintendo Switch as the end-user cannot replace that component.
Is Unity excluding such components on locked down platforms, or are they simply in violation of LGPL v3?
Will do! :-) The good news is that what you got wrong is something that probably 99% of people get wrong about *GPLv3: the scope of the Tivoization clause.
The Tivoization clause was written quite narrowly to stop what Tivo was doing, which was selling a device with a locked down OS that includes *GPLv3 software. It applies if and only if:
1. the software is conveyed in a "User Product", and
2. that conveyance occurs as part of a transaction in which the right of possession and use of that product is transferred to the recipient.
A "User Product" is defined as 'either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling'.
For the Nintendo Switch it means that Nintendo cannot include any *GPLv3 software in the Switch itself or in anything that comes with the Switch when you buy it.
Add on software that you obtain and install later, including software sold by Nintendo through their online store or on physical media, is not covered by the Tivoization clause. As far as the Tivoization clauses goes there is no problem with Unity including *GPLv3 code for any locked down platforms they use and for any developers who use Unity to write games for those platforms.
Where there might be a problem is with other parts of *GPLv3. For example when software is distributed through app stores such as Apple's or Nintendo's and you buy that software it is Apple or Nintendo that is making and distributing the copy that you download. That's fine because they have permission from the copyright owner.
But to use that app store you usually have to agree to a TOS that prohibits things like redistributing and reverse engineering. That violates *GPLv3. If the owner of the copyright owns the copyright on all the code they used they can grant Apple or Nintendo a license that allows the distribution.
If they have included some third party *GPL library in the app or game and the third party has not granted such a license to the store owner then that app or game cannot be distributed on that store.
> But to use that app store you usually have to agree to a TOS that prohibits things like redistributing and reverse engineering.
LGPL has it a requirement that the application needs to be distributed in a form where you can replace and modify the LGPL bits. Either via dynamic linking or separately-distributed object files. I'm not sure how you could be considered in compliance with this when the development environment for consoles is an expensive devkit you have to sign an agreement for and the SDK/APIs etc are trade secret. At the very least, I imagine a court would take a very dim view of "well we technically shipped object files in this encrypted container that you can't read or Nintendo will sue you up the ass".
If Unity didn't get an exception license for their LGPL bits, then them and pretty much every indie dev that has shipped on console is violating the license. Bonus points for the fact that the termination clause on *GPLv2 is basically one-strike-and-your-out, so they would have to individually go to each LGPL library Unity touched and beg for forgiveness before ever using those libraries ever again.
On iOS, any iCloud account can get a development profile set up to build and run code signed for your device. And on the App Store you can write custom EULA language that says "any activity required to exercise your rights under LGPL is explicitly allowed, App Store TOS not-withstanding." The biggest problem is just getting access to the object files and assets in order to relink the app. iOS application binaries are encrypted, and app bundles, while not encrypted, are a pain in the ass to get a copy of on a real desktop OS where the developer tools can run. For a fully FOSS app, you can just link to a Git repository to satisfy the GPL copyleft, but I doubt proprietary developers want to distribute a whole unlinked copy of their code just so you can link it in.
There was a problem with VLC on iOS a decade ago, but it mainly has to do with the fact that Apple wants team accounts to be verified with DUNS numbers. VLC is a nonprofit, which apparently made it a pain in the ass to get a DUNS number; but that was fixed a long time ago and VLC is on the iOS App Store.
Apple has the same problem as unity. Try this on a mac:
% bash --version
GNU bash, version 3.2.57...
Copyright (C) 2007 Free Software Foundation, Inc.
They can't upgrade bash past 3.2 (which is the last GPLv.2 release), so they're maintaining an ancient version themselves (it's old enough to smoke + vote + go to war in the US!), and they're trying to get users to switch to zsh.
I looked at the LGPL 2.1, and the "or later" bit of the license is weird. Users can convert it to any version of GPL >= 2.1 at their discretion. However, the author of the library needs to specify LGPL (= any version), LGPL 2.1 (= exactly 2.1), or (recommended) "LGPL 2.1 or later" in a COPYING file.
Unity says they "deprecated" LGPL code. That makes sense unless the code pins the LGPL version. Upstream LGPL vendors could rug-pull them, bash-style, at any moment.
However, VLC's libraries are listed as "LGPL 2.1 only" here, so they explicitly claim they cannot rug pull (unless they jump to GPL3 -- that wouldn't be too surprising, since most of their stuff is AGPL, though it'd probably cause a fork):
Except VLC didn't incorporate the license properly (COPYING and COPYING.lib don't say if they pin LGPL versions), and their README.md says:
> libVLC, the engine is released under the LGPLv2 (or later) license.
This allows embedding the engine in 3rd party applications, while letting them to be licensed under other licenses.
So, Unity's probably right to be worried. "or later" includes v3, which is specifically incompatible with stuff like anti-cheat technology and consoles.
However, my best guess is that Unity's worried about pissing off third parties that have patents on the algorithms VLC implements, and they use the LGPL thing as an excuse to avoid revealing the details of those private deals.
Unity is a bad business decision nowadays. If I had to pick something commercial I'd rather pick Epic Games who at least uses lawyers to fight Apple instead of f*ing with open source devs.
> 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.
However this was removed sometime between December 3rd and December 12th according to the Wayback Machine.
I really would like to use Unity for projects. I actually really like the editor, the API and the ability for me to set up a lot of tooling quite easily for people who are not tech-savvy in-editor. Unity just makes it so difficult for me every step of the way with hostile behaviour towards its users, the twenty different beta packages they are Totally Making Stable Next Year, I Swear, the _harshly_ degrading performance on even just empty projects..
I'm mainly using Godot now and it's nice but it just doesn't quite compare.
Yeah, it feels to me like there's some other reason they dislike VLC that they're not telling. Does it compete with their own media player or something? Did the creator of VLC date a Unity exec's ex?
VLC violates the DMCA, as well as includes patented MPEG style codecs, the end users of which (under a mostly USA-enforced legal framework ?) are supposed to pay royalties to patent owners, which I presume they almost never do (?) :
> ...for uploading a package that they decree has now been deprecated?
Unity appears to be using the term "deprecated" to mean "removed" or "deleted". This is a fucking stupid trend that I wish we would collectively push through, but we're not quite there yet.
My interpretation of the memo from Unity is that they have deleted the VLC library from the Unity Store and have permanently banned the VLC group's Unity Store account for violation of the terms of the contract with Unity.
Corpo jargon can be difficult to understand. (This might be the primary purpose of corpo jargon.)
We moved away from Unity a few years ago when they introduced their updated licensing plan. I believe they backtracked on it almost immediately but we are still happy with our decision.
> 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.
It's high time the EU clamps down on Unity as well and classifies them as a gatekeeper. This behavior is absolutely unhinged.
Not just Unity, it's well past time the EU started enforcing the bans on US infocoms dating to a decade ago (Patriot Act => Snowden scandal => Schrems 2), since with it not being possible to presume any more that the USA is an ally, there's no reason to look away when they violate the fundamental rights of EU residents.
> games built with Unity depend on LGPL code by default (hello glibc!)
So I'm being needlessly pedantic here and this doesn't necessarily go against the OP's point, but since I find this sort of stuff interesting I'd like to point out that glibc is actually GPL not LGPL. There is however an alternate license that applies to programs which link against glibc, with the intention being that the GPL prevents you from distributing glibc as part of a non-Free compiler. I'm not sure of how exactly this is expressed in the legalese but that was my understanding of it.
> 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.
Not sure if I'd be petty enough to try, but reporting every other offender is likely to get some attention and (hopefully) a change in policy.
I thought most dev stores have prohibitions against GPL and LGPL code like this? Epic's Fab distribution agreement says you can't use LGPL "unless you are merely dynamically linking a shared library" which is obviously impossible for them to enforce and not technically feasible on some gaming platforms.
The Godot store seems to allow LGPLv3 licensed code which is interesting.
Unity themselves using LGPL code isn't related because presumably they can control the way in which it is used, unlike a third party plug-in.
I’ve read a bit this post and the gitlab repo link but I still have no idea if it’s about having a VLC desktop player playing Unity assets / games, or a plugin for Unity to have a little VLC player inside the games.. or something else ?
It's more like allowing VLC media player inside the games, maybe as a cutscene player, or playing media via a control which players can interact with inside the game.
I believe the gem lies in this sentence: "allowing (you) to build your own media-player based on VLC technology in Unity-based games".
> The integration essentially was a bridge between the Unity game engine and the VLC multimedia engine, allowing to build your own media-player based on VLC technology in Unity-based games.
Unfortunately for these guys, even if they have come up with the right solution - their own store - it doesn’t matter from the POV of commercial success. Right solutions are often NOT financially successful.
I remember that VLC could not get into iOS App Store for the same reason, and the story about it was spun by everyone and their dog. Ffmpeg is there because it doesn’t have this kind of PR, and that’s it.
Different issue. The App Store controversy was because VLC was, back in 2011, licensed under the GPL. One of the VLC developers complained to Apple that the GPL license was incompatible with the App Store distribution model, so it was pulled.
The engine parts of VLC were subsequently relicensed under LGPL-2.1, and the rest of the app under MPL.
But they still use libraries under GPL themselves:
> It gets better… Unity itself, both the Editor and the runtime (which means your shipped game) is already using LGPL dependencies! Unity is built on libraries such as Lame, libiconv, libwebsockets and websockify.js (at least). Full list of open-source Unity dependencies here.
So what they hate seem to be "publishers and Unity users using GPL libraries", not using it themselves.
They are very different licenses, so their comment has nothing to do with the article, which is what I was pointing out. Including the LGPL in a comment about the GPL makes as much sense as including Switzerland in a comment about Sweden. It's an easy mistake to make if you aren't very familiar with them, but it's still a mistake, and one which leads you to nonsensical conclusions if you don't correct it.
libVLC the library is LGPL licensed, VLC the application is GPL licensed. This plugin was of course just using libVLC so it being GPL was not the issue. As you said several other libraries unity uses are also LGPL licensed.
Open source is just the transfer of property and capital from well meaning developers straight into the pockets of corporations and billionaires. Developers are well advised to always apply the AGPLv3 to everything they make. It's either AGPLv3 or all rights reserved, everything in between makes no sense.
Your comment makes no sense: first it attacks “open source” with derogatory language, then it strongly recommends using a certain open-source license, and then it returns to attacking “open source” with derogatory language pasted from a clueless blog post by a plonker renowned for his clueless rants.
If there's something wrong with open source software as a class, that thing would almost certainly have to be wrong with the AGPL as well, since it's a central example of the class of open source licenses, and, contrary to your comment, one of the most popular ones. If it's an exception to the generalization, you need to explain why.
So it isn't "slight hyperbole". It's utter incoherence.
If everyone in a classroom but one makes the same mistake, it's not incoherent to say the class screwed up.
And they half explained why AGPL is different, with the other half not being hard to infer. It's the only one that isn't donating code to huge companies, because they can't use it on their servers without sharing back.
Give a tiny bit of benefit of the doubt that they were saying something coherent. Please.
(Their other later comment says they considers AGPL to be in a different category from "open source", and even if that's wrong it actually makes the argument more coherent. They're explicitly criticizing open source licenses other than AGPL.)
Free software and open source software are not the same. AGPLv3 is not an open source license, it is the strongest copyleft free software license available at this point in time.
> certified as an official open source license by the OSI
That just means open source sees itself as a superset of free software. The reality is they have completely different and incompatible values. They are not the same.
> you're saying that "open source is just the transfer of property and capital" and it isn't
Open source licenses are essentially payment in exposure. Well meaning developers are literally giving away their intellectual property in exchange for a copyright notice with their name on it being included in a billion dollar corporation's product. To me that makes no sense whatsoever. The results are predictable and I've seen plenty of people get disillusioned when the reality of it sinks in.
Free software licenses at least attempt to maximize the public good of the software being given away. This actually generates some leverage for the developer.
Not at all. AGPLv3 is a copyleft viral counter-SaaS anti-tivoization license. Licenses like BSD and MIT are basically "just include this copyright notice and disclaimer".
It is true that the two licenses differ significantly, but not in the way you are asserting, namely, that one is an open-source license and the other is not, or that one is a free-software license and the other is not.
The so-called "MIT license" (one of many licenses that have been used by MIT at different times) is also both a free-software license and an open-source license.
> “Open source” is something different: it has a very different philosophy based on different values.
> Its practical definition is different too, but nearly all open source programs are in fact free.
> We explain the difference in Why “Open Source” misses the point of Free Software.
Which is the article I cited in a previous comment. It contains:
> a part of the free software community splintered off and began campaigning in the name of “open source”
> it soon became associated with philosophical views quite different from those of the free software movement
> The two now describe almost the same category of software, but they stand for views based on fundamentally different values
> We in the free software movement don't think of the open source camp as an enemy
> we want people to know we stand for freedom, so we do not accept being mislabeled as open source supporters
> What we advocate is not “open source,” and what we oppose is not “closed source.”
They are not the same.
In any case, this disagreement has nothing to do with the point I'm trying to make. I'm simply comparing the amount of leverage provided by different categories of licenses.
Viral copyleft licenses ensure the free software values are propagated. Corporations want to avoid that and this gives developers leverage. Companies must either publish code or negotiate a deal with the copyright holders.
Permissive licenses give developers no advantage. They don't get paid. Freedoms aren't guaranteed. Corporations can take the code and run. They could wake up on day and realize they dedicated parts of their lives to enriching billionaires for free.
The AGPLv3 is pretty easy for the corporations to comply with, they just have to either use the unmodified code, or give their users access to the modified code. The money will still go to them even with AGPLv3.
You have to go to non-FOSS licenses if you want to change where the money goes, but even that won't help, because if you get popular enough they will just use their giant amount of devs to re-implement your stuff and then beat you at marketing.
> The AGPLv3 is pretty easy for the corporations to comply with
> they just have to either use the unmodified code, or give their users access to the modified code
If it's so easy, then why don't they? Why do they treat it as legal kryptonite?
> You have to go to non-FOSS licenses if you want to change where the money goes
I agree with you. That's why I said "AGPLv3 or all rights reserved".
I don't necessarily want to change where the money goes though. It's about having the power to do whatever you want as the user of the software and especially as the owner of the computer that's running it.
AGPLv3 is simply the license that allows us to give away software while retaining the most possible leverage. Open source licenses just give it all away for literally nothing.
> but even that won't help, because if you get popular enough they will just use their giant amount of devs to re-implement your stuff and then beat you at marketing
That's okay. Spending one's own time and money on something is not exploitative in any way. They could also negotiate exceptions to the GPL with the copyright holders.
FTR, AGPLv3 is considered an Open Source license, perhaps you meant permissive/pushover licenses when you said "Open source licenses just give it all away for literally nothing". Also, permissive licenses have conditions too, although they are easy to comply with, violations of them are still quite common, as they are for GPL-family licenses.
Deliberately going out of your way to put a smaller company out of business seems like shitty behavior to me. I also wonder about the anti-trust angle; Big Tech using their oligopoly in the developer labour market to kill startups that could become competitors.
I never really bought the idea that selling exceptions is ethical, probably better to downgrade to LGPL instead.
> FTR, AGPLv3 is considered an Open Source license
I distinguish free software and open source software due to their different historical roots and values.
I also distinguish licenses based on user/developer centrality. Free software licenses are primarily about users. Permissive licenses are all about developer convenience.
> permissive licenses have conditions too, although they are easy to comply with
It's easy to comply with the AGPLv3 as well. They just have to share source code under the same license and make sure we can use it.
They don't want to comply. They want to keep their code secret. They want to find little loopholes to get out of the contract. They want to create controlled "platforms", corporate digital fiefdoms where only their software can run. They want to limit our freedom and impose their will on us.
Competitors launching a service based on free software isn't the real issue. The problem is being unable to self-host this stuff on our own computers because they control the software and the hardware. It's all about us, the users of the software. Developers don't really matter.
> violations of them are still quite common, as they are for GPL-family licenses
People infringe copyright on a daily basis. It's completely normal. They often do not even realize they're doing it. Happens to proprietary software too.
Copyright is a lost cause. I advocate for its abolition.
Only reason copyleft licenses exist at all is to try to twist copyright into a fake public domain. Still much better than permissive licenses that just pretend copyright doesn't exist without actually abolishing it. Others are only too happy to take advantage of their generosity by going all rights reserved.
> distinguish free software and open source software
The movements are different sure, but when it comes to acceptable licenses, they are pretty much equivalent. Sounds like you are talking about licenses people common associate with each movement though. I agree there is somewhat of a dichotomy, although I feel like at the beginning open source was a bit more of a copyleft thing, and became more associated with permissive/pushover licenses later when GitHub became popular and Big Tech steered folks towards those licenses.
> Competitors launching a service based on free software isn't the real issue.
It is for the companies who are adopting the AGPLv3 in an attempt to be seen as "real open source" again. They don't actually care about users, except to the extent they can get cash from them, to pay back their vulture capitalist funders.
> It's all about us, the users of the software. Developers don't really matter.
Sure, as far as licenses etc go, but developers have to matter to some extent, otherwise you get unmaintained/buggy/nonexistent software.
In a world without copyright law, there would still be proprietary trade secret software, and Free Software. I see the Free Software movement as aspiring to providing a high level of equality of access to a work between both the original author and far downstream recipients. The license is only one aspect of that, the other is the source code, without which you can't have equivalent access to the author. The form that source comes in also matters, since there are forms that can only be modified with proprietary software, and forms that discard information (like machine code exectuables, or lossy video encoding).
That would remove the one possibility of GPL enforcement that we have, since I assume we aren't going to resort to kneecapping violators when copyright goes away :)
Perhaps there would be other non-violent tactics like boycott campaigns or trademarks to mark ethical software that could be effective. We should be doing those now too though, and are to some extent.
> It is for the companies who are adopting the AGPLv3 in an attempt to be seen as "real open source" again.
If it's a problem for them, then they're not really committed to free and open source software. That's how we test them.
> They don't actually care about users, except to the extent they can get cash from them, to pay back their vulture capitalist funders.
Exactly. This is why we cannot fooled by their attempts to open wash their reputation. They're still looking to control and monetize and exploit users at every turn.
> developers have to matter to some extent
Developers are users too.
Users can also hire developers to work on what they need. I've been hired to customize open source software. I even upstreamed the work. Pretty great as far as jobs go. I think this is how professional programming should be like.
> That would remove the one possibility of GPL enforcement that we have
It would also get rid of "anti-circumvention" nonsense and allow
us to copy and distribute software much more freely regardless of attempts to lock things down.
It'd fix many more problems than it'd cause. No need to enforce anything if everything is already free by default. Only one copy is needed for infinite replication.
> Perhaps there would be other non-violent tactics like boycott campaigns or trademarks to mark ethical software that could be effective.
The Open Source Hardware Association has a trademark that projects can use to advertise. It can be revoked if they're not compliant.
This is about the LGPL, which is a very different licence. I’ve not heard of it causing any problems. Glibc is licensed in this way, everything uses that.
I appreciate the correction. It looks like specifically the long double libm functions (things like extended precision square root and logarithm) and the DES implementation from SSLeay are licensed under the LGPL? That seems to conflict with badgersnake's link https://www.gnu.org/software/libc/#license
It is amazing to me the commentary confusing GPL and LGPL on this site. The misinformation being spread about the LGPL, or just assuming the LGPL is the same as the GPL is mind boggling. I can't be to surprised, I guess. GPL happens after the L, and of course, we know GPL "doesn't allow commercial applications" right? So that's all we need to discuss.
Seriously, it's just four characters, and doesn't take long to look up without just assuming it's the same as the GPL.
The argument "the lawyers saw GPL in LGPL and just made an assumption" is all the more plausible when you have people in the field who make the same mistake.
The GPLs don't concern themselves with commercial use. You can use GPL-licensed software for any application you wish, that is what software freedom means. It's just that if you do use copylefted free software, you must provide, free of charge, the source code of the software using it and any modifications made.
If this weren't the case, then every web server running linux would have to offer their users the source code to linux. Seems pretty silly, probably most software shouldn't be AGPL.
AGPL is best used by projects that want to offer dual licensing for a fee, so they can get corporations to fund their development.
Most software probably should be AGPL licensed and its use is best for projects who want to protect what ought to be basic human rights which unfortunately aren't enshrined in law.
Oh give me a break. What basic human rights are being violated by Linux being licensed with the GPL? GPLv3 would be a nice improvement, but human rights violations for it not being AGPL??
I'm not a huge fan of AGPL but I think being "silly" is the least of my worries. A few redundant github links on the about page is a small cost for getting open source to stay actually open in the era of cloud services.
I do agree that it's "best" used in that kind of dual licensing, but I wish companies were less allergic to it so it could be used in general purpose ways. (It or a lawyer-friendly alternative.)
The FSF has a whole article on why you'd choose GPL or LGPL [0]. In general they agree with you that LGPL is overused, but they do identify a few reasons why you might choose LGPL.
That said, if the other option is something like MPL then I can think of a number of reasons why LGPL is better. At least LGPL ensures that modifications to your library itself remain free, whereas a more permissive license allows changes to be locked up entirely in a proprietary fork.
It's still more permissive than LGPL in that it isn't 'infectious' even when statically linked, the license only applies to the source file, not to any derived work. That makes the requirements more straightforward but does limit the freedom of the user to dynamically swap the library out for one that they'd prefer.
You're confusing "commercial" and "proprietary".
Also LGPL doesn't block static linking with proprietary software, it just want that you allow the end user to replace the library with a modified version, and there are several ways to allow it.
LGPL is pretty much the license for "if you use my code, you must also provide your customers a source copy of the same license, but if you ship a binary just let people know so they can ask me for the source".
Users get the benefit of not having to keep a source code archive for compiled libraries every release, but still apply GPL restrictions and rights if you decide to copy code from within the library.
If your customer is internal, that's not a problem. But realistically, internal tooling may as well be based on pirated and stolen code. How would anyone even find out?
I think it has its charms. You can use the library as-is and everyone who cares can find the source code elsewhere (it's probably on github somewhere anyway), but you can't take it as a basis and alter it to make your own project out of it without keeping the product open.
In the modern "everything requires HTTP calls to the network" era of software, AGPL may be a better solution for making sure the source code remains open, but for old-fashioned on-device apps there's a nice balance between freedom and obligations.
The freedom it was intended to preserve was the ability to modify the library and replace it, having your changes reflected in the application. Static linking breaks that freedom.
Not trying to play devils advocate, but it goes both ways. There are proprietary libraries in a lot of solutions too. The LGPL is under many distributed closed solutions that are sold for profit, so I think its WEEE bit of the kettle calling .. ya you get it. I don't want to turf war, but its more systemic than you probably think. In this case, its just the pry-bar used that the risk to blow up the entire community of developed software with open libraries.
Clearly, the legal team got bad information and made it part of their agreement. Like the article says, not only do tons of Unity assets use LGPL dependencies, but Unity uses LGPL assets themselves. Even shipped games created using Unity use LGPL assets. The intent was probably only to screen out GPL dependencies. For those who don't know, there's a huge difference between the GPL and LGPL. The LGPL is specifically designed to allow proprietary applications to link to open-source libraries without requiring the proprietary application’s source code to be released, provided certain conditions are met. This is particularly true when the LGPL-licensed library is used in a way that allows users to modify or replace it independently of the proprietary application.
In contrast, the GNU General Public License (GPL) has stricter requirements. If your software incorporates GPL-licensed code, the entire derivative work must also be licensed under the GPL, which includes releasing the source code.
I don't know much about the way unity apps are distributed, but I'd be a little surprised if they are only intended to be distributed in a way that satisfies LGPL.
I would have thought, e.g., that apps distributed only through stores to platforms that require apps to be signed could not contain LGPL components, since you would not be able to modify the LGPL components. (Maybe it would be OK if the software was available for download freely and side loading wasn't too difficult??? IDK.)
Legal specifics aside (IANAL after all), my general point is that despite being more flexible than full GPL, LGPL is still pretty restrictive. Proprietary software generally may need to keep things simple or be careful (probably including consulting an attorney with the relevant expertise) to ensure they are compliant.
In that light, I can see why Unity would disallow LGPL software. It's not that it couldn't be done properly, but that it's probably not feasible to do a proper legal review of every asset added to the sure (not for Unity and not for the asset providers).
> require apps to be signed could not contain LGPL components, since you would not be able to modify the LGPL components.
You COULD make the changes, but you MUST keep the changes to the LGPL'd software made available in some way. This is not going to affect the rest of your project, only the LGPL'd library. I think not including any private keys or signed files will still satisfy the LGPL as long as any code changes you made are included. I don't think configuration that compromises your security is within scope, and I'd feel like RMS would agree there.
Its really interesting the goal of the LGPL is to allow for LIBRE libraries to exist where there's proprietary components that already do a solid job, so in order to convince people to use GPL / LGPL tools / libraries it was thrown in that umbrella.
The FAQ is worth a read every now and then, you get a feel for what is intended in plain English.
https://www.gnu.org/licenses/gpl-faq.html
I believe the GP is referring to the LGPL requirement that users be able to replace LGPL components with modified versions.
Being able to replace subsystems of a signed application with arbitrary third party code adds complexity and is a security risk, but is a requirement of the LGPL.
I think modernity has complicated things. The proprietary vendor signing all the binary components to prevent tampering is different from the platform package manager and kernel requiring signed packages/pages. If you have the proprietary blob and a bunch of modified third party dynamically loaded components, you (or the platform) can re-generate your own signature over the modified composition to execute it in {context that requires signed code execution for security/integrity}. The LGPL is addressing the former. I don’t see a spirited problem with the latter.
I’m trying to work out if an app was distributed with a service that ran in a separate process, e.g via XPC service on Apple platforms, could LGPL libs be legally statically linked only to the service code, which would be open sourced. The service and main app would not be linked at compile time so LGPL wouldn’t apply to the main app, which could remain closed.
> I would have thought, e.g., that apps distributed only through stores to platforms that require apps to be signed could not contain LGPL components, since you would not be able to modify the LGPL components. (Maybe it would be OK if the software was available for download freely and side loading wasn't too difficult??? IDK.)
IIRC, That's a difference between LGPLv2 and LGPLv3 - LGPLv3 has the same anti-tivoization clauses that GPLv3 has - while LGPLv2 does not. So afaict, it's totally OK to distribute software in ways that does not allow the user to modify the library when that library is licensed LGPLv2.
VLC is licensed under LGPLv2.1, which is not subject to the tivoization clause.
Doesn't that mean the anti-tivoization clause makes LGPL3 software unusable on most mobile platforms since they're all fixated on signing libraries?
I don’t think so, at least on Android. If you replace a library in an app, you just sign it with your own keys.
> So afaict, it's totally OK to distribute software in ways that does not allow the user to modify the library when that library is licensed LGPLv2.
Legally that might be true, but that interpretation stands directly opposed to the intention of the license. In that light, it is unambiguously unethical to use that loophole.
Plenty of projects intentionally stay on older GPL licenses because they want that permissiveness.
Many, many people license under gpl2 only to avoid that tivoization clause. So unless there’s a clear indication on the library’s author wishes wrt tivoization, I don’t think it’s fair to make any ethical assumptions here.
Every thread about software licenses always devolves into a firehose of debate and conflicting beliefs. How, in 2025, are we still in a state where, on HN of all places, nobody has any idea what the specifics of LGPL really means or how it has to be implemented? How is it so convoluted, confusing, and up to interpretation?
There's demonstrably room for innovation here - coming up with some new system that actually makes sense, that people can actually understand. I suppose there's licenses like MIT that fall in that bucket. Everyone is pretty clear about something like the MIT license. But the various GPL licenses and other, more custom/convoluted licenses ideally need to be replaced by something much better.
> Everyone is pretty clear about something like the MIT license
I don't think this is really true. I think people are often upset or surprised when their MIT-licensed programs are used in ways they don't agree with, or they reuse MIT-licensed programs in ways that violate their license terms (e.g. it takes many companies many, many years to realize they have to actually include a way for users to view copyright notices).
Open source software is built on many different fuzzy notions of community and collaboration, encoded into an imperfect-but-legally-robust set of protocols that try to establish common language for people to build on. These protocols have proven very, very successful in encouraging collaboration and minimizing exploitation, but there's still a regularization/compromise process that's necessary so that everybody has a common ground to work from.
For another perspective, think about them like security software—I personally might not know why TLS uses DH key exchange, or how it works, but if I threw it out in hopes of making thing simpler, things would probably go pretty badly for me when someone else notices.
> But the various GPL licenses and other, more custom/convoluted licenses ideally need to be replaced by something much better.
What, though? I expect that people with a greater understanding of copyright law and how to write legal documents, have tried and failed. The GPL, LGPL, the Affero variants have specific goals around keeping software open. I don't think writing a license to achieve those goals can be simple or straightforward.
That is legaleze for you, and it not at all surprising that we are still discussing how such a text should be interpreted. Its mostly impossible to create a legal text that has unchanged interpretation for several decades, or centuries for that matter. Just look how courts often discussion the interpretation and enforcement of specific laws, even laws that are older than the judges themselves.
It’s because the genesis of these convoluted license terms is rooted deeply in the archaic copyright law in the US. Until that is fixed, these legal hacks will be necessary.
If you’re not pushing an agenda, you have the public domain or the unlicense as options completely simple understandable options.
Arguably, I do not think that everyone is clear on how MIT works. Huge amounts of software, dare I say most, don't even include a way to view the license, which is a requirement to use MIT.
> How is it so convoluted, confusing, and up to interpretation?
I don't think it is so much as many people mistaking their beliefs for facts.
That Unity itself or Unity-based games use LGPL components doesn't matter. What matters here is what is allowed on the Unity Asset Store. There is nothing requiring Unity to allow everything on their Asset Store that could be linked into a Unity game, and apparently at the time, the Provider agreement simply said: you can't sell LGPL assets on the store.
It isn't surprising or unreasonable that the Store might have additional requirements, and there are plenty of reasons to do so. One is Unity limiting their risks as a distributor of third-party content. Another is that the Unity Asset Store does not require assets sold to be used with Unity, and for some assets it can be allowed depending on the specific asset's license:
https://support.unity.com/hc/en-us/articles/34387186019988-C...
On the other hand, not enforcing the LGPL rule evenly against other assets also currently being distributed with LGPL components, on the other hand, is more problematic.
> The LGPL is specifically designed to allow proprietary applications to link to open-source libraries without requiring the proprietary application’s source code to be released, provided certain conditions are met.
It's not that simple. The LGPL says that one must basically be able to make modifications to the opensource library, rebuild the library and be able to reintegrate this new library in the existing application. And you, as a developer using an LGPL library, need to make this "possible". What this practically means, is open to interpretation. This is also why lawyers (and companies) don't like the LGPL, because it contains even more of this "open to interpenetration" text than the GPL.
> What this practically means, is open to interpretation.
Is it? It seems very straightforward to me—just use a DLL. The LGPL even says explicitly that it's fine as long as you use a shared library.
The situation gets trickier for Android or Xbox games I guess. I'm curious how Unity complies with the LGPL provisions there. But for any normal desktop platform this should be trivial to comply with.
EDIT: ah, upthread they mention this is only a provision for the LGPLv3. I would expect that the LGPLv3 is pretty rarely used for this reason.
"Just use a DLL"
Like you say, it gets trickier for Android, or Xbox games, or...
iOS, which requires each library binary to be signed by the publisher, or...
Rust or Go, which encourage static linking of all dependencies...
These days a "normal desktop platform" is really a minority of software.
Afaik not necessarily. You migh make modifications to the LGPL library (such as changing the API) and then use that in your proprietary app.
Although the modified library would still be LGPL, it would be both practically useless to everyone on the street, and unfortunately the (L)GPL doesn't even specify how you must share the source. It's perfectly legal to say 'send us a request and we email you the modified sources'
No. Read the license. https://www.gnu.org/licenses/lgpl-3.0.en.html
"4. Combined Works.
You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:
- d) Do one of the following:
-- 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
-- 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version."
if your application contains LGPL code then as a user of your application i must be able to make changes to that LGPL code. that means i need either the code of the whole application or at least object files and infrastructure so that i can relink my changed LGPL code to your application.
>at least object files and infrastructure so that i can relink my changed LGPL code to your application.
This part is true but I'd like to emphasize that the infrastructure is on the user to acquire. The distributor of the application is not required to make that infrastructure available.
no, it is. it's explicitly mentioned that the distributor has to provide for instance build instructions.
> The “Corresponding Application Code” for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work.
> If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
The only thing you don't have to provide is e.g. the platform toolchain, headers, etc. e.g. you don't have to ship Windows.h and cl.exe if you are making a windows app that comes with an LGPL library.
i am not sure about that. isn't it required that i get everything needed to rebuild the application? if it's a standard compiler, sure. but any config files, nonstandard tools to link, say if the non-LGPL part is written in an inhouse language with a non-public compiler and linker, you still need to give me the tools to relink the objects. i mean that's very unlikely to happen, but if it does, those tools need to be shared.
Yes that's true, if it's a non-public compiler, linker, operating system, or whatever... then the source code for all of those need to be provided.
not the source code, but binaries that can run on the same target machine.
The license specifies that it must be the source code. Binaries are not sufficient.
are you sure? how is that supposed to work if i build an application with a compiler that i don't have the source for? even for a pure GPL program that can't be a requirement. LGPL requires object files for the non-LGPL parts to allow relinking, but it requires the source for the tool that does the relinking? that doesn't make much sense to me.
From section 1 of the GPLv3:
"The 'Corresponding Source' for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work."
The LGPL refers to the GPL by reference. I don't think the intent is to recursively require the source code of the entire universe. But the definition of "System Libraries" is somewhat vague, and the undefined term "general-purpose tools" is even vaguer. Would, say, MSVC be a "general-purpose tool", even though it arguably isn't a "generally-available free program"? (And which "free" are they using here?) I can see why many legal teams would be wary, at least.
>> The LGPL is specifically designed to allow proprietary applications to link to open-source libraries without requiring the proprietary application’s source code to be released, provided certain conditions are met. This is particularly true when the LGPL-licensed library is used in a way that allows users to modify or replace it independently of the proprietary application.
That requires the library to be dynamically linked. Not sure if that's in play here.
It does not. https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...
It doesn't strictly require it to be dynamically linked but does place additional requirements on applications which are statically linked to LGPLed libraries.
> If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
this is not an additional requirement, this is another way to apply the core requirement of the LGPL to the static linking case in C, which is: the end-user must be able to patch / replace the LGPL parts of the app.
This is the relevant part:
And is this easy? I don't know much about how this works, but would it be trivial for unity to distribute a version of unity with statically linked LGPL libraries where you can also easily relink?It's as easy as building the project in the first place. Anytime you build your application you also build the object files for it as well.
As an end user having to take those object files and relink them can be difficult for sure, but that's not something the distributor has to do. The distributor simply has to provide some additional files that their build process will already produce.
Of course, those build files won't be stripped, meaning that it would be easier to reverse-engineer them - which might not be something the distributor wants.
? there's nothing that prevents to call strip on .o files
I wouldn't call it completely trivial at the scale and complexity of something like unity, but its certainly possible.
In practice it's probably easier to dynamically link the library.
I think you would find it very difficult to find even a single game which has done this.
"but Unity uses LGPL assets themselves."
So Unity will ban itself?
As the devil's advocate I'd like to argue that legal is probably more comfortable with Unity's own use of LGPL libraries, because they can ensure that Unity only links dynamically to those libraries. And given how critical these dependencies are to the engine, legal is willing to take the "risk" of allowing LGPL dependencies.
The ban of LGPL in assets on the asset store is probably due to legal being concerned that someone would publish an asset that statically links to an LGPL library and that it would allow anyone to demand the source/object code of any Unity game that uses that asset.
Legal probably sees it as too much effort to vet every asset to see if it links correctly to LGPL libraries and simply instituted a blanket ban to simplify enforcement.
Unity's lawyers continue killing the company, not a big surprise there.
I used to work there, proud of their technical accomplishments, ashamed of pretty much everything else.
[dead]
Edit: nevermind, they are in fact affiliated, and most of the core VLC devs work at VideoLabs. I've kept the original comment below.
This blog post links to the "VideoLab Store", hosted at https://videolabs.io, which prominently uses a logo extremely similar but not identical to the VLC (which stands for VideoLAN, not VideoLab) logo. Their homepage even goes as far as displaying "Hire the VLC team" as its headline.
As far as I'm aware, VideoLab has nothing to do with the VideoLAN non-profit, and it very much seems like they are intentionally trying to mislead people into thinking that they are the developers of VLC.
(President of VideoLAN here).
So far, VideoLabs is hiring most of the VLC core developers and those people are the main force of development of VLC. It's setup this way so that if the Videolabs company does not live forever, VLC stays forever free, and the non-profit lives.
This is quite classic of open source projects, and in the case of VideoLAN, there are 3 or 4 companies doing consulting.
Very cool, that definitely makes sense! I've edited my comment, apologies for that. Hopefully bringing attention to the fact that you guys are easily available for hire ends up doing more good than harm.
What does this mean? What harm does it do?
The harm I imagine would be the reputation damage from people believing that "they are intentionally trying to mislead people into thinking that they are the developers of VLC." NoahKAndrews, having been informed that these really are the devs of VLC, is hoping his earlier, uninformed statement did not cause too many people to think poorly of VideoLabs.
I love this model! Love what you guys do, and please keep up the good work.
> As far as I'm aware, VideoLab has nothing to do with the VideoLAN non-profit
VideoLabs is a company which has been founded by one of the creators of VLC/VideoLAN and president of the VideoLAN non-profit.
It's basically a for-profit that hired/employs most of the VLC main contributors and pay them a salary to work on that ecosystem while providing consulting and other services to finance all that.
They are significant contributors to the VLC codebase.
After having worked with them in the context of a partnership, I can add that "for-profit" is mostly the legal form but not the mindset.
Well, the author does have a link to the git forge of the VideoLAN project prominently displayed on the blog and also contributes to projects there: https://code.videolan.org/videolan/LibVLCSharp
Additionally, Videolabs is listed at https://www.videolan.org/videolan/partners.html
I guess the project is well-aware of the corporation.
Just discovered some of that myself, I'm glad everything's on the up-and-up.
From their about page:
Videolabs was born from the VideoLAN community and started by maintaining the VLC ports on mobile. It is now the main contributor to VLC, hiring its historical developers, and building custom solutions around the VLC and FFmpeg ecosystems.
The CTO is the president of the VideoLAN non-profit, so it seems accurate. Supposedly from their about page they’re the primary maintainers of vlc.
Please correct me if I am wrong here.
From my understanding, using LGPL v2 code in console releases is fine since v2 does not have a tivoization clause (i.e. even if the end-user cannot re-link the program because the platform is locked down, that's still ok).
However, websockify.js (and perhaps other dependencies) are LGPL v3, which means they cannot be included on a platform like the Nintendo Switch as the end-user cannot replace that component.
Is Unity excluding such components on locked down platforms, or are they simply in violation of LGPL v3?
> Please correct me if I am wrong here
Will do! :-) The good news is that what you got wrong is something that probably 99% of people get wrong about *GPLv3: the scope of the Tivoization clause.
The Tivoization clause was written quite narrowly to stop what Tivo was doing, which was selling a device with a locked down OS that includes *GPLv3 software. It applies if and only if:
1. the software is conveyed in a "User Product", and
2. that conveyance occurs as part of a transaction in which the right of possession and use of that product is transferred to the recipient.
A "User Product" is defined as 'either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling'.
For the Nintendo Switch it means that Nintendo cannot include any *GPLv3 software in the Switch itself or in anything that comes with the Switch when you buy it.
Add on software that you obtain and install later, including software sold by Nintendo through their online store or on physical media, is not covered by the Tivoization clause. As far as the Tivoization clauses goes there is no problem with Unity including *GPLv3 code for any locked down platforms they use and for any developers who use Unity to write games for those platforms.
Where there might be a problem is with other parts of *GPLv3. For example when software is distributed through app stores such as Apple's or Nintendo's and you buy that software it is Apple or Nintendo that is making and distributing the copy that you download. That's fine because they have permission from the copyright owner.
But to use that app store you usually have to agree to a TOS that prohibits things like redistributing and reverse engineering. That violates *GPLv3. If the owner of the copyright owns the copyright on all the code they used they can grant Apple or Nintendo a license that allows the distribution.
If they have included some third party *GPL library in the app or game and the third party has not granted such a license to the store owner then that app or game cannot be distributed on that store.
The GPLv3 does not stop what Tivo actually did, and both GPLv2 and GPLv3 do stop what became known as Tivoization (preventing modification).
What Tivo actually did was break their proprietary software when you modified the GPL parts of the system.
Some related links:
https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://events19.linuxfoundation.org/wp-content/uploads/2017...
> But to use that app store you usually have to agree to a TOS that prohibits things like redistributing and reverse engineering.
LGPL has it a requirement that the application needs to be distributed in a form where you can replace and modify the LGPL bits. Either via dynamic linking or separately-distributed object files. I'm not sure how you could be considered in compliance with this when the development environment for consoles is an expensive devkit you have to sign an agreement for and the SDK/APIs etc are trade secret. At the very least, I imagine a court would take a very dim view of "well we technically shipped object files in this encrypted container that you can't read or Nintendo will sue you up the ass".
If Unity didn't get an exception license for their LGPL bits, then them and pretty much every indie dev that has shipped on console is violating the license. Bonus points for the fact that the termination clause on *GPLv2 is basically one-strike-and-your-out, so they would have to individually go to each LGPL library Unity touched and beg for forgiveness before ever using those libraries ever again.
On iOS, any iCloud account can get a development profile set up to build and run code signed for your device. And on the App Store you can write custom EULA language that says "any activity required to exercise your rights under LGPL is explicitly allowed, App Store TOS not-withstanding." The biggest problem is just getting access to the object files and assets in order to relink the app. iOS application binaries are encrypted, and app bundles, while not encrypted, are a pain in the ass to get a copy of on a real desktop OS where the developer tools can run. For a fully FOSS app, you can just link to a Git repository to satisfy the GPL copyleft, but I doubt proprietary developers want to distribute a whole unlinked copy of their code just so you can link it in.
There was a problem with VLC on iOS a decade ago, but it mainly has to do with the fact that Apple wants team accounts to be verified with DUNS numbers. VLC is a nonprofit, which apparently made it a pain in the ass to get a DUNS number; but that was fixed a long time ago and VLC is on the iOS App Store.
No, you're right. Here's the best "article" I can find about this at the moment:
https://opensource.stackexchange.com/questions/7387/what-is-...
(copy paste from a dead link.)
Apple has the same problem as unity. Try this on a mac:
They can't upgrade bash past 3.2 (which is the last GPLv.2 release), so they're maintaining an ancient version themselves (it's old enough to smoke + vote + go to war in the US!), and they're trying to get users to switch to zsh.I looked at the LGPL 2.1, and the "or later" bit of the license is weird. Users can convert it to any version of GPL >= 2.1 at their discretion. However, the author of the library needs to specify LGPL (= any version), LGPL 2.1 (= exactly 2.1), or (recommended) "LGPL 2.1 or later" in a COPYING file.
Unity says they "deprecated" LGPL code. That makes sense unless the code pins the LGPL version. Upstream LGPL vendors could rug-pull them, bash-style, at any moment.
However, VLC's libraries are listed as "LGPL 2.1 only" here, so they explicitly claim they cannot rug pull (unless they jump to GPL3 -- that wouldn't be too surprising, since most of their stuff is AGPL, though it'd probably cause a fork):
https://code.videolan.org/explore/projects/starred
Except VLC didn't incorporate the license properly (COPYING and COPYING.lib don't say if they pin LGPL versions), and their README.md says:
> libVLC, the engine is released under the LGPLv2 (or later) license. This allows embedding the engine in 3rd party applications, while letting them to be licensed under other licenses.
https://code.videolan.org/videolan/vlc
So, Unity's probably right to be worried. "or later" includes v3, which is specifically incompatible with stuff like anti-cheat technology and consoles.
However, my best guess is that Unity's worried about pissing off third parties that have patents on the algorithms VLC implements, and they use the LGPL thing as an excuse to avoid revealing the details of those private deals.
Godot ftw.
Unity is a bad business decision nowadays. If I had to pick something commercial I'd rather pick Epic Games who at least uses lawyers to fight Apple instead of f*ing with open source devs.
Interesting 5.10.4 does not seem to exist in the provider agreement? https://unity.com/legal/provider
At one point this used to contain the clause:
> 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.
However this was removed sometime between December 3rd and December 12th according to the Wayback Machine.
Looks like it was moved into the "Submission Guidelines 1.2.b" linked from 5.10.1:
https://assetstore.unity.com/publishing/submission-guideline...
The post is over a year old (January 2024).
The relevant email is even dated 31st of August 2023.
I really would like to use Unity for projects. I actually really like the editor, the API and the ability for me to set up a lot of tooling quite easily for people who are not tech-savvy in-editor. Unity just makes it so difficult for me every step of the way with hostile behaviour towards its users, the twenty different beta packages they are Totally Making Stable Next Year, I Swear, the _harshly_ degrading performance on even just empty projects..
I'm mainly using Godot now and it's nice but it just doesn't quite compare.
Unity is actually permanently banning accounts for uploading a package that they decree has now been deprecated? What are they smoking?
Yeah, it feels to me like there's some other reason they dislike VLC that they're not telling. Does it compete with their own media player or something? Did the creator of VLC date a Unity exec's ex?
VLC violates the DMCA, as well as includes patented MPEG style codecs, the end users of which (under a mostly USA-enforced legal framework ?) are supposed to pay royalties to patent owners, which I presume they almost never do (?) :
https://wiki.videolan.org/Frequently_Asked_Questions/
So it might be possible that someone from the USA decided to strongarm Unity ?
> ...for uploading a package that they decree has now been deprecated?
Unity appears to be using the term "deprecated" to mean "removed" or "deleted". This is a fucking stupid trend that I wish we would collectively push through, but we're not quite there yet.
My interpretation of the memo from Unity is that they have deleted the VLC library from the Unity Store and have permanently banned the VLC group's Unity Store account for violation of the terms of the contract with Unity.
Corpo jargon can be difficult to understand. (This might be the primary purpose of corpo jargon.)
Unity again showing their hostility. Perma-banning developers for this reason is crazy.
Not so much "again" as "before they doubled down and went full unity". This happened before the "per install" fees, in August of 2023.
No surprise here. Unity is such a horrible company.
We moved away from Unity a few years ago when they introduced their updated licensing plan. I believe they backtracked on it almost immediately but we are still happy with our decision.
If not home-grown, where did you move to?
Previous discussion (Jan 2024): https://news.ycombinator.com/item?id=38964972
I don't know if VLC itself is even legal in countries that enforce software patents.
> 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.
It's high time the EU clamps down on Unity as well and classifies them as a gatekeeper. This behavior is absolutely unhinged.
Not just Unity, it's well past time the EU started enforcing the bans on US infocoms dating to a decade ago (Patriot Act => Snowden scandal => Schrems 2), since with it not being possible to presume any more that the USA is an ally, there's no reason to look away when they violate the fundamental rights of EU residents.
They removed someone’s entire app and they say “sorry for the inconvenience”
Sure would be a shame if someone went through the unity store and reported every single LGPL asset to Unity legal.
[2024]?
(2024)
> games built with Unity depend on LGPL code by default (hello glibc!)
So I'm being needlessly pedantic here and this doesn't necessarily go against the OP's point, but since I find this sort of stuff interesting I'd like to point out that glibc is actually GPL not LGPL. There is however an alternate license that applies to programs which link against glibc, with the intention being that the GPL prevents you from distributing glibc as part of a non-Free compiler. I'm not sure of how exactly this is expressed in the legalese but that was my understanding of it.
> 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.
Not sure if I'd be petty enough to try, but reporting every other offender is likely to get some attention and (hopefully) a change in policy.
I thought most dev stores have prohibitions against GPL and LGPL code like this? Epic's Fab distribution agreement says you can't use LGPL "unless you are merely dynamically linking a shared library" which is obviously impossible for them to enforce and not technically feasible on some gaming platforms.
The Godot store seems to allow LGPLv3 licensed code which is interesting.
Unity themselves using LGPL code isn't related because presumably they can control the way in which it is used, unlike a third party plug-in.
Only madman would develop anything with Unity after last fiasco.
I’ve read a bit this post and the gitlab repo link but I still have no idea if it’s about having a VLC desktop player playing Unity assets / games, or a plugin for Unity to have a little VLC player inside the games.. or something else ?
It's more like allowing VLC media player inside the games, maybe as a cutscene player, or playing media via a control which players can interact with inside the game.
I believe the gem lies in this sentence: "allowing (you) to build your own media-player based on VLC technology in Unity-based games".
> The integration essentially was a bridge between the Unity game engine and the VLC multimedia engine, allowing to build your own media-player based on VLC technology in Unity-based games.
Unfortunately for these guys, even if they have come up with the right solution - their own store - it doesn’t matter from the POV of commercial success. Right solutions are often NOT financially successful.
Every time I think about using Unity they remind me why I'm right in preferring something fully open source that isn't gate keeping my use of it.
did your app threaten their advertising network or revenue perhaps?
Can the link please be updated to note that this is from 2024?
I remember that VLC could not get into iOS App Store for the same reason, and the story about it was spun by everyone and their dog. Ffmpeg is there because it doesn’t have this kind of PR, and that’s it.
Different issue. The App Store controversy was because VLC was, back in 2011, licensed under the GPL. One of the VLC developers complained to Apple that the GPL license was incompatible with the App Store distribution model, so it was pulled.
The engine parts of VLC were subsequently relicensed under LGPL-2.1, and the rest of the app under MPL.
VLC has been back on the App Store since 2013.
Ugh.
Another reason for people to ditch it and use Godot.
[flagged]
Big companies hate GPL
No surprise here
But they still use libraries under GPL themselves:
> It gets better… Unity itself, both the Editor and the runtime (which means your shipped game) is already using LGPL dependencies! Unity is built on libraries such as Lame, libiconv, libwebsockets and websockify.js (at least). Full list of open-source Unity dependencies here.
So what they hate seem to be "publishers and Unity users using GPL libraries", not using it themselves.
Those libraries are under the LGPL, not the GPL, which is a huge difference in this context.
I'm assuming mouse_ was including LGPL when they said GPL because otherwise their comment has nothing to do with the article.
They are very different licenses, so their comment has nothing to do with the article, which is what I was pointing out. Including the LGPL in a comment about the GPL makes as much sense as including Switzerland in a comment about Sweden. It's an easy mistake to make if you aren't very familiar with them, but it's still a mistake, and one which leads you to nonsensical conclusions if you don't correct it.
libVLC the library is LGPL licensed, VLC the application is GPL licensed. This plugin was of course just using libVLC so it being GPL was not the issue. As you said several other libraries unity uses are also LGPL licensed.
Thank you for the explanation! If I knew that, I had forgotten.
Ah, you're very right, I misread it somehow when I first came across it... Thanks for the correction!
It's an easy mistake to make!
Nothing wrong to use someone else's work to make money for yourself. Plenty wrong to use someone else's work to make money for others.
Oversimplification I know.. but.. right?
The Ferenghi would be proud of Unity!
GPL/LGPL is more about treating users fairly than not making money. It’s just that most software companies exploit their users to various degrees.
Open source is just the transfer of property and capital from well meaning developers straight into the pockets of corporations and billionaires. Developers are well advised to always apply the AGPLv3 to everything they make. It's either AGPLv3 or all rights reserved, everything in between makes no sense.
https://zedshaw.com/blog/2022-02-05-the-beggar-barons/
> To the Beggar Baron, open source's value is its free donation.
> You would never stand on the street and offer to buy the wallets off people who are about to donate a few dollars to you.
> That'd be stupid. They're giving you their money for free. Take it and run.
Your comment makes no sense: first it attacks “open source” with derogatory language, then it strongly recommends using a certain open-source license, and then it returns to attacking “open source” with derogatory language pasted from a clueless blog post by a plonker renowned for his clueless rants.
It makes sense when you add the fact that 99% of open source is not AGPL. Criticizing "open source" is slight hyperbole.
If there's something wrong with open source software as a class, that thing would almost certainly have to be wrong with the AGPL as well, since it's a central example of the class of open source licenses, and, contrary to your comment, one of the most popular ones. If it's an exception to the generalization, you need to explain why.
So it isn't "slight hyperbole". It's utter incoherence.
If everyone in a classroom but one makes the same mistake, it's not incoherent to say the class screwed up.
And they half explained why AGPL is different, with the other half not being hard to infer. It's the only one that isn't donating code to huge companies, because they can't use it on their servers without sharing back.
Give a tiny bit of benefit of the doubt that they were saying something coherent. Please.
(Their other later comment says they considers AGPL to be in a different category from "open source", and even if that's wrong it actually makes the argument more coherent. They're explicitly criticizing open source licenses other than AGPL.)
Also 1% was just a rough guess but this survey says I was exactly right: https://github.blog/open-source/open-source-license-usage-on... If the number has changed in the last few years I'm open to updates.
Free software and open source software are not the same. AGPLv3 is not an open source license, it is the strongest copyleft free software license available at this point in time.
https://www.gnu.org/philosophy/open-source-misses-the-point....
https://www.gnu.org/philosophy/words-to-avoid.html
And it's hard to disagree with the clueless guy when what he says is happening keeps happening.
https://twitter.com/FFmpeg/status/1775178803129602500
https://twitter.com/FFmpeg/status/1775178805704888726
https://trac.ffmpeg.org/ticket/10341#comment:4
The AGPL v3 has been certified as an official open source license by the OSI for 16 years: https://opensource.org/license/agpl-v3
It's not that no begging ever happens. It's just that you're saying that "open source is just the transfer of property and capital" and it isn't.
> certified as an official open source license by the OSI
That just means open source sees itself as a superset of free software. The reality is they have completely different and incompatible values. They are not the same.
> you're saying that "open source is just the transfer of property and capital" and it isn't
Open source licenses are essentially payment in exposure. Well meaning developers are literally giving away their intellectual property in exchange for a copyright notice with their name on it being included in a billion dollar corporation's product. To me that makes no sense whatsoever. The results are predictable and I've seen plenty of people get disillusioned when the reality of it sinks in.
Free software licenses at least attempt to maximize the public good of the software being given away. This actually generates some leverage for the developer.
It's not a superset. They're literally the same licenses. Everything you are saying is nonsense except that working for exposure is a bad idea.
Not at all. AGPLv3 is a copyleft viral counter-SaaS anti-tivoization license. Licenses like BSD and MIT are basically "just include this copyright notice and disclaimer".
It is true that the two licenses differ significantly, but not in the way you are asserting, namely, that one is an open-source license and the other is not, or that one is a free-software license and the other is not.
The so-called "MIT license" (one of many licenses that have been used by MIT at different times) is also both a free-software license and an open-source license.
https://www.gnu.org/licenses/license-list.html#X11License "This is a lax permissive non-copyleft free software license, compatible with the GNU GPL."
It's also listed without comment on https://opensource.org/licenses, the list of OSI-approved open-source licenses.
Like the AGPL, it does not represent a difference between the set of open-source licenses and the set of free-software licenses.
In the list you cited:
> We classify a license according to certain key criteria:
> Whether it qualifies as a free software license.
Following the link:
https://www.gnu.org/philosophy/free-sw.html
> “Open source” is something different: it has a very different philosophy based on different values.
> Its practical definition is different too, but nearly all open source programs are in fact free.
> We explain the difference in Why “Open Source” misses the point of Free Software.
Which is the article I cited in a previous comment. It contains:
> a part of the free software community splintered off and began campaigning in the name of “open source”
> it soon became associated with philosophical views quite different from those of the free software movement
> The two now describe almost the same category of software, but they stand for views based on fundamentally different values
> We in the free software movement don't think of the open source camp as an enemy
> we want people to know we stand for freedom, so we do not accept being mislabeled as open source supporters
> What we advocate is not “open source,” and what we oppose is not “closed source.”
They are not the same.
In any case, this disagreement has nothing to do with the point I'm trying to make. I'm simply comparing the amount of leverage provided by different categories of licenses.
Viral copyleft licenses ensure the free software values are propagated. Corporations want to avoid that and this gives developers leverage. Companies must either publish code or negotiate a deal with the copyright holders.
Permissive licenses give developers no advantage. They don't get paid. Freedoms aren't guaranteed. Corporations can take the code and run. They could wake up on day and realize they dedicated parts of their lives to enriching billionaires for free.
The AGPLv3 is pretty easy for the corporations to comply with, they just have to either use the unmodified code, or give their users access to the modified code. The money will still go to them even with AGPLv3.
You have to go to non-FOSS licenses if you want to change where the money goes, but even that won't help, because if you get popular enough they will just use their giant amount of devs to re-implement your stuff and then beat you at marketing.
> The AGPLv3 is pretty easy for the corporations to comply with
> they just have to either use the unmodified code, or give their users access to the modified code
If it's so easy, then why don't they? Why do they treat it as legal kryptonite?
> You have to go to non-FOSS licenses if you want to change where the money goes
I agree with you. That's why I said "AGPLv3 or all rights reserved".
I don't necessarily want to change where the money goes though. It's about having the power to do whatever you want as the user of the software and especially as the owner of the computer that's running it.
AGPLv3 is simply the license that allows us to give away software while retaining the most possible leverage. Open source licenses just give it all away for literally nothing.
> but even that won't help, because if you get popular enough they will just use their giant amount of devs to re-implement your stuff and then beat you at marketing
That's okay. Spending one's own time and money on something is not exploitative in any way. They could also negotiate exceptions to the GPL with the copyright holders.
https://www.gnu.org/philosophy/selling-exceptions.html
Probably cautious lawyers, maybe cargo-culting, hard to tell. Some more discussion of why they don't in this LWN thread:
https://lwn.net/Articles/1019686/
FTR, AGPLv3 is considered an Open Source license, perhaps you meant permissive/pushover licenses when you said "Open source licenses just give it all away for literally nothing". Also, permissive licenses have conditions too, although they are easy to comply with, violations of them are still quite common, as they are for GPL-family licenses.
Deliberately going out of your way to put a smaller company out of business seems like shitty behavior to me. I also wonder about the anti-trust angle; Big Tech using their oligopoly in the developer labour market to kill startups that could become competitors.
I never really bought the idea that selling exceptions is ethical, probably better to downgrade to LGPL instead.
> FTR, AGPLv3 is considered an Open Source license
I distinguish free software and open source software due to their different historical roots and values.
I also distinguish licenses based on user/developer centrality. Free software licenses are primarily about users. Permissive licenses are all about developer convenience.
> permissive licenses have conditions too, although they are easy to comply with
It's easy to comply with the AGPLv3 as well. They just have to share source code under the same license and make sure we can use it.
They don't want to comply. They want to keep their code secret. They want to find little loopholes to get out of the contract. They want to create controlled "platforms", corporate digital fiefdoms where only their software can run. They want to limit our freedom and impose their will on us.
Competitors launching a service based on free software isn't the real issue. The problem is being unable to self-host this stuff on our own computers because they control the software and the hardware. It's all about us, the users of the software. Developers don't really matter.
> violations of them are still quite common, as they are for GPL-family licenses
People infringe copyright on a daily basis. It's completely normal. They often do not even realize they're doing it. Happens to proprietary software too.
Copyright is a lost cause. I advocate for its abolition.
Only reason copyleft licenses exist at all is to try to twist copyright into a fake public domain. Still much better than permissive licenses that just pretend copyright doesn't exist without actually abolishing it. Others are only too happy to take advantage of their generosity by going all rights reserved.
> distinguish free software and open source software
The movements are different sure, but when it comes to acceptable licenses, they are pretty much equivalent. Sounds like you are talking about licenses people common associate with each movement though. I agree there is somewhat of a dichotomy, although I feel like at the beginning open source was a bit more of a copyleft thing, and became more associated with permissive/pushover licenses later when GitHub became popular and Big Tech steered folks towards those licenses.
> Competitors launching a service based on free software isn't the real issue.
It is for the companies who are adopting the AGPLv3 in an attempt to be seen as "real open source" again. They don't actually care about users, except to the extent they can get cash from them, to pay back their vulture capitalist funders.
> It's all about us, the users of the software. Developers don't really matter.
Sure, as far as licenses etc go, but developers have to matter to some extent, otherwise you get unmaintained/buggy/nonexistent software.
https://xkcd.com/2347/
> Copyright is a lost cause.
In a world without copyright law, there would still be proprietary trade secret software, and Free Software. I see the Free Software movement as aspiring to providing a high level of equality of access to a work between both the original author and far downstream recipients. The license is only one aspect of that, the other is the source code, without which you can't have equivalent access to the author. The form that source comes in also matters, since there are forms that can only be modified with proprietary software, and forms that discard information (like machine code exectuables, or lossy video encoding).
https://wiki.debian.org/AutoGeneratedFiles
> I advocate for its abolition.
That would remove the one possibility of GPL enforcement that we have, since I assume we aren't going to resort to kneecapping violators when copyright goes away :)
Perhaps there would be other non-violent tactics like boycott campaigns or trademarks to mark ethical software that could be effective. We should be doing those now too though, and are to some extent.
> It is for the companies who are adopting the AGPLv3 in an attempt to be seen as "real open source" again.
If it's a problem for them, then they're not really committed to free and open source software. That's how we test them.
> They don't actually care about users, except to the extent they can get cash from them, to pay back their vulture capitalist funders.
Exactly. This is why we cannot fooled by their attempts to open wash their reputation. They're still looking to control and monetize and exploit users at every turn.
> developers have to matter to some extent
Developers are users too.
Users can also hire developers to work on what they need. I've been hired to customize open source software. I even upstreamed the work. Pretty great as far as jobs go. I think this is how professional programming should be like.
> That would remove the one possibility of GPL enforcement that we have
It would also get rid of "anti-circumvention" nonsense and allow us to copy and distribute software much more freely regardless of attempts to lock things down.
It'd fix many more problems than it'd cause. No need to enforce anything if everything is already free by default. Only one copy is needed for infinite replication.
> Perhaps there would be other non-violent tactics like boycott campaigns or trademarks to mark ethical software that could be effective.
The Open Source Hardware Association has a trademark that projects can use to advertise. It can be revoked if they're not compliant.
Case in point:
https://github.com/clockworkpi/uConsole/issues/27
It's the LGPL, not the GPL. Huge difference.
This is about the LGPL, which is a very different licence. I’ve not heard of it causing any problems. Glibc is licensed in this way, everything uses that.
The LGPL is a very different license, but glibc is not licensed under it, nor under the GPL.
It's got a number of different licenses for it's various components. LGPL 2.1 is among them.
License file at https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=LICEN...
Source at https://sourceware.org/git/?p=glibc.git;a=summary
I appreciate the correction. It looks like specifically the long double libm functions (things like extended precision square root and logarithm) and the DES implementation from SSLeay are licensed under the LGPL? That seems to conflict with badgersnake's link https://www.gnu.org/software/libc/#license
Someone should update this then. Isn't glibc the poster child for LGPL? https://en.wikipedia.org/wiki/Glibc
That’s not what it says here: https://www.gnu.org/software/libc/#license
It is amazing to me the commentary confusing GPL and LGPL on this site. The misinformation being spread about the LGPL, or just assuming the LGPL is the same as the GPL is mind boggling. I can't be to surprised, I guess. GPL happens after the L, and of course, we know GPL "doesn't allow commercial applications" right? So that's all we need to discuss.
Seriously, it's just four characters, and doesn't take long to look up without just assuming it's the same as the GPL.
The argument "the lawyers saw GPL in LGPL and just made an assumption" is all the more plausible when you have people in the field who make the same mistake.
The GPL does allow commercial applications. That's how we got Linux, nearly every embedded board support package ever, etc.
I should have been more explicit by making it clear that part was sarcasm based on the comments I'm seeing elsewhere on this post. Apologies.
Sorry, I probably should have given the quotation marks more weight.
I find popularity of LGPL licenses a bit weird.
Allows:
- Commercial use of the software
- Commercial use of the source code for projects that run on the company's servers or internally
- Commercial use of the library is allowed if dynamically linked
Blocks:
- Commercial use of the source code for local apps that run on user's device
- Commercial use of the library if statically linked for local apps that run on user's device
I would expect a licence like MPL to be more popular than LGPL.
The GPLs don't concern themselves with commercial use. You can use GPL-licensed software for any application you wish, that is what software freedom means. It's just that if you do use copylefted free software, you must provide, free of charge, the source code of the software using it and any modifications made.
If you run things on the servers/cloud (excluding more recent AGPL) you don't need to provide any source code.
If this weren't the case, then every web server running linux would have to offer their users the source code to linux. Seems pretty silly, probably most software shouldn't be AGPL.
AGPL is best used by projects that want to offer dual licensing for a fee, so they can get corporations to fund their development.
Most software probably should be AGPL licensed and its use is best for projects who want to protect what ought to be basic human rights which unfortunately aren't enshrined in law.
Oh give me a break. What basic human rights are being violated by Linux being licensed with the GPL? GPLv3 would be a nice improvement, but human rights violations for it not being AGPL??
I'm not a huge fan of AGPL but I think being "silly" is the least of my worries. A few redundant github links on the about page is a small cost for getting open source to stay actually open in the era of cloud services.
I do agree that it's "best" used in that kind of dual licensing, but I wish companies were less allergic to it so it could be used in general purpose ways. (It or a lawyer-friendly alternative.)
The FSF has a whole article on why you'd choose GPL or LGPL [0]. In general they agree with you that LGPL is overused, but they do identify a few reasons why you might choose LGPL.
That said, if the other option is something like MPL then I can think of a number of reasons why LGPL is better. At least LGPL ensures that modifications to your library itself remain free, whereas a more permissive license allows changes to be locked up entirely in a proprietary fork.
[0] https://www.gnu.org/licenses/why-not-lgpl.en.html
Doesn't MPL require to release any modifications made to the library itself?
Oh, yes, I missed that! You're correct.
It's still more permissive than LGPL in that it isn't 'infectious' even when statically linked, the license only applies to the source file, not to any derived work. That makes the requirements more straightforward but does limit the freedom of the user to dynamically swap the library out for one that they'd prefer.
Not if you put them in a new source code file, no.
You're confusing "commercial" and "proprietary". Also LGPL doesn't block static linking with proprietary software, it just want that you allow the end user to replace the library with a modified version, and there are several ways to allow it.
"just"
LGPL is pretty much the license for "if you use my code, you must also provide your customers a source copy of the same license, but if you ship a binary just let people know so they can ask me for the source".
Users get the benefit of not having to keep a source code archive for compiled libraries every release, but still apply GPL restrictions and rights if you decide to copy code from within the library.
If your customer is internal, that's not a problem. But realistically, internal tooling may as well be based on pirated and stolen code. How would anyone even find out?
I think it has its charms. You can use the library as-is and everyone who cares can find the source code elsewhere (it's probably on github somewhere anyway), but you can't take it as a basis and alter it to make your own project out of it without keeping the product open.
In the modern "everything requires HTTP calls to the network" era of software, AGPL may be a better solution for making sure the source code remains open, but for old-fashioned on-device apps there's a nice balance between freedom and obligations.
The freedom it was intended to preserve was the ability to modify the library and replace it, having your changes reflected in the application. Static linking breaks that freedom.
Maybe that's why web apps have become more prevalent?
no.
Not trying to play devils advocate, but it goes both ways. There are proprietary libraries in a lot of solutions too. The LGPL is under many distributed closed solutions that are sold for profit, so I think its WEEE bit of the kettle calling .. ya you get it. I don't want to turf war, but its more systemic than you probably think. In this case, its just the pry-bar used that the risk to blow up the entire community of developed software with open libraries.
Tread lightly maybe.
What goes both ways? Everyone involved is fine with proprietary libraries being used.
> The LGPL is under many distributed closed solutions that are sold for profit, so I think its WEEE bit of the kettle calling .. ya you get it.
No, I don't get it. The LGPL allows that and they're happy with it. Where are you seeing hypocrisy?
[flagged]