Jump to content
  • Advertisement
Sign in to follow this  
Nick of ZA

Library licenses, taken individually and together

This topic is 3168 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all. I'm inexperienced re the distribution/sale of proprietary software that is developed using a licensed "free" libraries, but I need to get educated fast. I have 4 different libraries I'm using at the moment and they use the following licenses: -BSD License (1 lib) -Apache Software Foundation License (1 lib) -LGPL (2 libs) Q1. I'm developing my game in Java. And as you can see... I am relying rather heavily on LGPL, which, from what I've read so far (at least in regards to Java due to the nature of it's linking) could be problematic if I don't want to release my source code. Has anyone got anything positive to offer on this topic?Specifically, how can I go about linking with LGPL libraries in a method that doesn't use the "import" statement (see http://www.gnu.org/licenses/lgpl-java.html)? Q2. Am I going to have any problems using these side by side in my work, noting that I will not be changing any of their source at all? Any help would be appreciated. TIA, Nick

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Nick of ZA
Specifically, how can I go about linking with LGPL libraries in a method that doesn't use the "import" statement (see http://www.gnu.org/licenses/lgpl-java.html)?

Wait, what? How do you intend to go about using classes from a different package without the import statement? And why?
Quote:
Am I going to have any problems using these side by side in my work, noting that I will not be changing any of their source at all?
No, these licenses all allow dynamic linking to closed-source applications.

Share this post


Link to post
Share on other sites
(Please don't bite my head off here, I am trying to work within the guidelines of the law, hence my posting here. If there is a way for me to work with the license in such a way that causes me not to have to a) release my code under LGPL or b) allow reverse engineering of my code in order to allow debugging of the bundled lib, then like any serious commercial developer, I'm going to look into those options. But breaking the law is NOT a risk I'm willing to take.)

In reponse to your question, well, I've seen it mentioned that using Java as an application server via methods that are completely generic (i.e. not based on something like RMI) such as SOAP or JMX, under the letter of the LGPL, does not constitute a breach of the license. As to the "why", I'd think that part would be obvious: this is a powerful library that has features that will save me a lot of development time. And working off my own meagre funding I'm not in a position to pay thousands (dollars, euro, pounds) to buy a commercial solution.

EDIT (clarification)

Here's what I'm not clear on, with respect to Java, taken from LGPL v3:

"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."

Apparently there's some controversy surrounding the definition of "shared library mechanism" or more accurately, what constitutes dynamic linking in Java. And THAT is where the problem comes in, and why I'm asking these questions. In C++, link against the DLL, credit the author and include the license info, and you're done. With Java, not so simple. Or is that a fallacy?

[Edited by - Nick of ZA on April 12, 2010 5:10:20 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Nick of ZA
Apparently there's some controversy surrounding the definition of "shared library mechanism" or more accurately, what constitutes dynamic linking in Java. And THAT is where the problem comes in, and why I'm asking these questions. In C++, link against the DLL, credit the author and include the license info, and you're done. With Java, not so simple. Or is that a fallacy?
It's not a fallacy, but it's wrong. Java's shared library system is very similar to the C runtime's. Like C, in response to an import directive, Java's library loader searches the classpath for a matching package, and imports it. SOAP and CORBA and COM and whatever do things in a more complicated manner, but they don't scratch any unscratched LGPL itch.

The link you posted is the FSF swearing up and down that you can use Java libraries in an LGPL context, simply by importing them and keeping the JARs separate. Maybe you should believe them?

Share this post


Link to post
Share on other sites
Maybe you didn't notice this part:

"If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications."

Let me just repeat that last bit:

"...and reverse engineer your code to debug these modifications."

Your thoughts?

Share this post


Link to post
Share on other sites
IANAL, but they do not seem to be arguing that you must release your application open-source if it links with a java LGPL library. Rather, they seem to be arguing that you must not threaten the user with legal action for reverse-engineering ATTEMPTS that specifically pertain to the debugging of their open-source libraries.

The LGPL is all about allowing users (and developers) to attempt to replace the version of the LGPL'ed code you package with the system with one they build themselves from a binary they have built themselves. This is done for two reasons: 1) if you make modifications to the LGPL library directly and don't redistribute source, then that is illegal, and the only way for someone to check your compliance is to attempt to try an unmodified version of the library with your app. 2) It makes it easier for others to maintain and make improvements on the open-source PARTS of your application. Since both of these actions are effectively impossible with static linking on C/C++, thats why the fsf argues that static linking is prohibited.

In java, however, it is trivially easy to do both of those things, even with closed source code, because of the way linking on java works. I can do a java decompile on one or many parts of an application, using jar files or individual class files, and almost all linking happens at runtime. For this reason, many java closed-source applications impose an ADDITIONAL restriction that, although decompilation and jar-file extraction are trivial, the end user may NOT do these things without fear of legal action, even if the reverse engineering is successful.

As you can see, such a restriction (worded something like http://www.nvidia.com/object/nv_swlicense.html (section 2.1.3) ) would actually play havoc with the LGPL's intended purpose: If you linked with LGPL code, then included a reverse engineering prohibition, you would be using LGPL code as a seperate dynamic library but effectively prohibiting someone from doing or even attempting to do the things that the LGPL is designed to allow which I mentioned above. You would be violating the spirit of the LGPL with respect to the open-source parts of the library.

I don't know your application, but I doubt you actually need/want a reverse-engineering restriction, even though your application is closed source. If you decide you REALLY don't want people to even try to pull your class files out of your distribution (OMG MY GAME LOOP IS A TRADE SECRET!!!111eleventy!!) then you can probably do what the LGPL code requires by wording your reverse-engineering restriction something like this in your licence:

"
Open Source Components: This software uses the following open-source components, which are heretofore mentioned as "LGPL LIBRARIES" for the purposes of this document:
<Library 1>
<Library 2>
...

part 4:
No Reverse Engineering. Customer may not reverse engineer, decompile, or disassemble the SOFTWARE, nor attempt in any other manner to obtain the source code, except in order to debug, test, or otherwise utilize the above-mentioned LGPL LIBRARIES pursuant to the licence under which they are distributed.

No Separation of Components. The SOFTWARE is licensed as a single product. Other than the above mentioned LGPL LIBRARIES, Its component parts may not be separated for use on more than one computer, nor otherwise used separately from the other parts. LGPL LIBRARIES may be removed, modified, replaced, or other utilization pursuant to the licence under which they are distributed."

I am not a representative of the FSF, nor am I a lawyer for the software you intend to use, so tread with caution, but if I WAS one of those things, I would be satisfied with this restriction.

Share this post


Link to post
Share on other sites
Steve,

Even if UANAL, you make excellent points, in particular your final suggestion is a very sensible one. Thank you. I will definitely think on this. During this early stage, I'm happy to use the LGPL v2.1 libraries I've been using so far. The "may not prohibit reverse engineering" clause does not prevent me from compiling my Java source to a native executable, making it as hard to reverse engineer as any C application (may not be that hard, but you can only do what you can do).

I wanted to make a final note for anyone who reads this thread, of a fairly crucial difference between LGPL v2.1 and v3. 2.1 re the reverse engineering clause. LGPL v2.1 section 6 states:

"As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications."

Note here that *the work* refers to the combined work -- your own code and the libraries taken together. Thus, prohibiting reverse engineering of your own proprietary code in LGPL v2.1 is a no-no, as it forms part of that combined work. (Unless we do something like Steve has suggested above.)

With v3, we see the corresponding clause in section 4:

"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:..."

Here we see the part that was giving me trouble, amended. We are now told that you may not restrict modification to portions of *the Library* (how things have changed!) contained in the combined work and reverse engineering for debugging such modifications [to the library].

Thanks for the replies.

Best,

Nick

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!