this post was submitted on 12 Jan 2024
1072 points (97.7% liked)
Technology
59534 readers
3195 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
LGPL requires distributing the license with any code. I imagine unity does that with the core code, but it would be difficult to enforce that for assets distributed in their store, which they would be liable for legally. I imagine this will be resolved, but I no longer use Unity so idfc
From my understanding there are other third-party assets in the Unity store which use the LGPL but are not being removed.
Is there any information on them being given a pass?
Generally stuff like this goes in waves. I have no experience with the unity store, but it wouldn't shock me to find out they haven't always (and still might not...) required "apps" to list their licensing. Meaning this would be a somewhat manual effort done by a severely reduced staff.
And I'll just add on that I expect this to happen to the other "asset" stores. In industry, "GPL is cancer" and "LGPL is herpes". GPL can straight up "kill" a project and LGPL is usually a mass of headaches that are mostly manageable but can still "cause problems" at times.
I expect they will be unless they're small enough to fly under the radar
No it won't. This is 5.10.4 of the Unity Provider agreement, it's total bullshit.
Why is it bullshit? AFAIK, Unity wouldn't be able to comply with LGPL without supplying their own source code, so then this would be the only logical outcome.
Unity let me go earlier this week, so I'm really not in the mood to defend them, but this is correct. I'm on the Unity hate train as much as the next guy and i feel this is pretty cut and dry.
Sad to hear it, hope you'll find something else soon.
Thankfully I'm in Canada where Collective Layoffs are heavily protected, and I have a generous package to keep me afloat until I find the right job.
It is a sad week for tech because not everyone has these protections.
No, it's not correct. Unity's management might think that's how the LGPL works, but they're wrong.
The fact that they prefer to not do something at all instead of going through the hassle of doing something properly has always been a thing at Unity. It's correct that it is for business reasons and not necessarily logical ones.
You are only required to give source code for changes to that part for LGPL code. So only the library requires that.
Other game engines supply source code. If Unity wants any hope of redemption they should let us inspect wtf it actually does on our computers (edit: and let us make it work for our needs).
You CAN access the source code, but it's for corporate/enterprise partners. afaik
Charging for access is actually fine under L/GPL but after that you're then free to redistribute at your own price. I imagine Unity heavily control how you use and distribute your modified engine (nonfree).
Unity uses the LGPL for parts of their own products. The GPL in most cases only requires that derivative work must also be shipped with the same license. The source code from providers doesn't have to be distributed by unity, it has to be distributed by the provider. In this case that would be videoLAN, which has all their source code on GitHub. You can read the text of the LGPL here, and this is VideoLAN's post about the situation.
That puts things into perspective, thanks!
This is incorrect. The distributor of derivative works in binary form is responsible for providing the source code. They can refer to a server operated by a third party, but if that third party stops providing the source code the distributor remains obligated to ensure that it is still available. The only exception is for binaries which were originally received with a written offer of source code, where the offer can be passed on as-is, but that only applies for "occasional and non-commercial" distribution which wouldn't work here.
Can you point to the section of the LGPL that describes what you're claiming?
Section 6 of the GPLv3, which the LGPLv3 includes by reference as one of the required distribution terms in paragraph 4.d.0:
(emphasis added) There is the alternative of following 4.d.1 instead, but that's only if the application links against a shared library already present on the user's computer system—it couldn't be distributed with the program.
GPLv3 section six offers five alternative methods of satisfying the obligation to provide source code. The first (6.a) applies only to physical distribution and must include source code with the physical media. The second (6.b) also requires physical distribution plus a written offer to provide the source code to anyone possessing the object code. The third (6.c) is the one I mentioned that applies only "occasionally and noncommercially" for those who received a written offer themselves under the previous clause. The fourth option (6.d) allows for the source to be provided through a network server:
The fifth and final alternative (6.e) pertains to object code provided through P2P distribution, with the same requirements as the fourth method for the source code.
Section A in section 3 of the LGPL is the out here for unity:
As long as there is prominent notice with the distribution of the plugin, unity doesn't need to distribute the source code.
You mean "3. Object Code Incorporating Material from Library Header Files."? That section 3? I think they're using a bit more than just header files. Section 4 "Combined Works" is the one that applies here.
Also even if section 3 did apply they'd need to follow 3.b as well as 3.a and include the full text of both the GPL and the LGPL.
I thought the point of the LGPL was to allow this sort of usage without requiring the release of source code. It's an extension of the GPL to remove those requirements isn't it?
I admit this is totally not my area, but couldn't you say that about literally any online source that sold software from Steam to the Apple App Store?
Not just license. You also need to link to it as a shared library and allow users to replace it with their own build of the library. Meaning you can't use stuff like DRM and anticheats.
Yup fair point I didn't know that. Unity presumably does this with dlls that a technical user can easily swap out. In principle an asset store script could do this, but it would be very difficult to verify and enforce so I can see why they'd just ban the license outright as a CYA thing.
Maybe the answer is to distribute a vlc dll separately and only ship a linking/driving script via the asset store.
Technically it can be statically linked, but then you would need to provide artifacts (for example, object files for the non-LGPL modules) enabling the end user to "recombine or relink" the program with a modified version of the LGPL code.
Dynamic linking is usually simpler, though. And the DRM issues apply either way.
Not exactly. The LGPL inherits the methods of conveying source code from section 6 of the GPL, which has a number of different options. You can bundle the source code along with the compiled version, but you can also do it simply by including an offer the end user can redeem to get a copy of the source. For example you could include a link to the source code.