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.
https://assetstore.unity.com/publishing/submission-guideline...
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.
So Unity will ban itself?
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.
That requires the library to be dynamically linked. Not sure if that's in play here.
>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.
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.
> 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.
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.
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'
"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."
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.
"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 “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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
If you’re not pushing an agenda, you have the public domain or the unlicense as options completely simple understandable options.
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.
I don't think it is so much as many people mistaking their beliefs for facts.
I believe the gem lies in this sentence: "allowing (you) to build your own media-player based on VLC technology in Unity-based games".
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.
AGPL is best used by projects that want to offer dual licensing for a fee, so they can get corporations to fund their development.
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.)
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.
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.
I used to work there, proud of their technical accomplishments, ashamed of pretty much everything else.
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.
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.)
It's high time the EU clamps down on Unity as well and classifies them as a gatekeeper. This behavior is absolutely unhinged.
Tread lightly maybe.
> 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?
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.
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?
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:
% bash --version
GNU bash, version 3.2.57...
Copyright (C) 2007 Free Software Foundation, Inc.
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.
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.
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.
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...
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.
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.
Additionally, Videolabs is listed at https://www.videolan.org/videolan/partners.html
I guess the project is well-aware of the corporation.
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.
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.
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 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'm mainly using Godot now and it's nice but it just doesn't quite compare.
mouse_•19h ago
No surprise here
diggan•19h ago
> 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.
HenryBemis•18h ago
Oversimplification I know.. but.. right?
The Ferenghi would be proud of Unity!
bitmasher9•18h ago
matheusmoreira•18h ago
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.
kragen•17h ago
Dylan16807•17h ago
kragen•4h ago
So it isn't "slight hyperbole". It's utter incoherence.
Dylan16807•2h ago
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.
matheusmoreira•16h ago
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
kragen•7h ago
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.
pabs3•2h ago
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.
kragen•17h ago
diggan•17h ago
kragen•4h ago
Dylan16807•17h ago
kragen•5h ago
zorgmonkey•16h ago
kragen•4h ago
tempfile•18h ago
badgersnake•18h ago
kragen•17h ago
actionfromafar•17h ago
pmontra•17h ago
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
kragen•4h ago
badgersnake•11h ago