5 ms·

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,

• zoobab 1y ago
  "but Unity uses LGPL assets themselves." So Unity will ban itself?
  • armada651 1y ago
    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.
• phkahler 1y ago
  >> 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.
  • jcelerier 1y ago
    It does not. https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...
    • Epa095 1y ago
      This is the relevant part: >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?
      • voxic11 1y ago
        I wouldn't call it completely trivial at the scale and complexity of something like unity, but its certainly possible.
        • phkahler 1y ago
          In practice it's probably easier to dynamically link the library.
        • arka2147483647 1y ago
          I think you would find it very difficult to find even a single game which has done this.
      • Maxatar 1y ago
        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.
• jsiepkes 1y ago
  > 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.
  • torginus 1y ago
    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'
    • Scaevolus 1y ago
      No. Read the license. https://www.gnu.org/licenses/lgpl-3.0.en.html 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."
• jmull 1y ago
  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).
  • roblabla 1y ago
    > 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.
    • voakbasda 1y ago
      > 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.
      • 1y ago
• ack_complete 1y ago
  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-Can-I-use-assets-from-the-Asset-Store-with-other-engines-Unreal-Godot-etc 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.
• thegrim33 1y ago
  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.
  • kelnos 1y ago
    > 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.
  • dcow 1y ago
    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.
  • belorn 1y ago
    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.
  • nightpool 1y ago
    > 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.