Legal woes… any alternatives?

dmd1214 · **Joined:** Fri Mar 03, 2006 3:36 pm **Posts:** 9

I know this is a strange place to ask this…

I’m developing rel4 of my client’s expensive commercial software package. Lawyers recently vetoed our using NHibernate due to ambiguous LGPL language that may be interpreted as my client’s software needing to be offered as open source.

We have a lot of code dependant on NHibernate’s view of ORM. Also, we’ve had such a good experience (technology wise) that we want to look at other ORM’s without the LGPL.

My 2 questions for you fine folks are:
1) Has anyone dealt with this issue? The decision is final, but I’m still professionally curious about the Lawyers’ interpretation.
2) Can anyone suggest an alternative? Ideally, we would find an identical tool sans LGPL.

The most important features are:
- .net 2.0 compatibility. Does not NEED to have the 2.0 bells and whistles, but needs to work.
- same goes for sqlserver 2005
- File based mapping (as opposed to code generation or tightly coupled classes)
- Similar session management approach. We require session to be serialized over remoting calls
- Some ability to express custom searches (i.e. HQL)
- Works with multiple databases

Thanks in advance, and I hope to work with you all again soon!

- Doug

jt_1000 · **Posted:** Fri Mar 24, 2006 4:59 pm

In my discussion term "base code" is the code provided under the LGPL. (I think they refer to it as the "Library" in the LGPL lic).

According to my (non-attorney) understanding of this LGPL is that if you extend the base code in any way, then you need to release source code for that extension, if you modify the base code in any way, then you need to provide source code, if you only use the base code as a part of your solution, then you can use whatever lic you want for your own code, but the base code is still LGPL. In any case you need to be display and distribute the based code (and it's lib) with your solution.

I always went under the understanding that using LGPL without modifying the base code was a good clean way to go for COMMERCIAL applications. And if you needed to modify the base code, that you distribute the mods and try to roll them back into the base code source for the rest of the world to have. (which has nothing to do with the proprietariness of your own commercial code - or at least your coders need to make sure code is not comingled)

I think the problem with attorneys is that they always want to play it safe, and they don't understand code, headers, libraries, executable...etc and there are very few people who can bridge the gap - thus the attorney will always want to protect him/herself and/or the corp and say don't use it - which is a shame, since I think they just don't get it...

found:
http://www.gnu.org/copyleft/lesser.html#SEC1

Quote:

5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.

However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.

When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law.

If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.)

Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself.

dmd1214 · **Joined:** Fri Mar 03, 2006 3:36 pm **Posts:** 9

Thanks for your reply JT. I have read that portion of the LGPL about a dozen times. My non-legal brain wants to agree with your assessment, but I can definitly see what the lawyers are freaking out about. The thing is confusing and ambiguous at best... and that's not a good thing when it comes to the the company's livelyhood.

I would still love to find someone who has really tested the LGPL in real world situations.

I would love even more to hear about alternative packages that are out there.

But i would love most of all if LGPL added the words... "As long as you don't try to modify the code and try to compete with NHib for profit, you can do what ever you want."

jt_1000 · **Posted:** Sat Mar 25, 2006 12:47 am

Ok - your wish is granted... ;)

see here:

http://www.hibernate.org/356.html

dmd1214 · **Joined:** Fri Mar 03, 2006 3:36 pm **Posts:** 9

Embarrassingly, I never saw that link before. To me, this is the magic quote:

Quote:

Using Hibernate (by importing Hibernate's public interfaces in your Java code), and extending Hibernate (by subclassing or implementation of an extension interface) is considered by the authors of Hibernate to be dynamic linking.

Let’s see if the lawyers buy it.

Thanks for the feedback on this.

dmd1214 · **Joined:** Fri Mar 03, 2006 3:36 pm **Posts:** 9

No-go.

The statement on the site was deemed to be legally irrelevant.

The abmiguity in the lgpl quote below was the final death blow.

Quote:

5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.

However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.

specifically:

Quote:

However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library...

[/quote]

mteper · **Joined:** Wed Jun 08, 2005 4:59 pm **Posts:** 27

Here's another non-legal take on this:

To me, it appears as though LGPL predates dynamic or JITable languages and is using technical jargon that is perfectly unambiguous in the world of C/C++ but can be confusing otherwise. I am pretty sure the intent was a strict computer-language meaning of the word "link", as in use the linker to combine various files into a monolithic executable file. No more, no less. Taken as such, and I am sure that IS the intended meaning, you would be perfectly safe. But I can see how a lawyer (or any layman) without a CS degree would look at this and see the term "linking" as ambiguous. So, good luck!

You should try petitioning whatever body is in charge of LGPL to clarify the language in view of current realities.

-MT

dmd1214 · **Joined:** Fri Mar 03, 2006 3:36 pm **Posts:** 9

MT, I agree with your take on being dated and the probable intent... and certainly with the fact that most people consider this to be the case. But check this quote out from the LGPL:

Quote:

When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library

I'm afraid that I've already lost my battle :(. The last word has been spoken.

mteper · **Joined:** Wed Jun 08, 2005 4:59 pm **Posts:** 27

You know, rereading this excerpt, I would have to reverse myself. Though practically speaking I doubt this clause is enforseable even in court in light of the common interpretation, taken on face value I think it means exactly what your lawyers are afraid it means. Bummer, huh?

I am talking specifically about "or using a shared library" clause, which would pretty much mean any DLL that depends on the NHibernate.dll.

See http://users.actcom.co.il/~choo/lupg/tu ... aries.html for a quick review of C library types.

-MT

dmd1214 · **Joined:** Fri Mar 03, 2006 3:36 pm **Posts:** 9

I don't know. I might be missing something. But I think the lawyers might be right on this one. Based on my study of LGPL, I cannot find any tangible evidence that this statement is wrong:

Quote:

"If your program uses NHibernate as a DLL, the source code for your program must be offered as open source under the LGPL agreement."

I'm not talking about what I 'want' to be the case, or the 'real intention' of the well intentioned NHibernate developers... I'm talking about what the LGPL says.

Something tells me that "not being enforceable in court" is a good enough argument.

gavin · **Posted:** Wed Apr 05, 2006 8:53 pm

Guys, when the LGPL says "link", it means link. It most certainly does not mean "dynamic link". Dynamically linking against an LGPL library does not affect the license of your code.

Really, the LGPL means what it has always been interpreted to mean by every single person who has ever licensed code under the LGPL. Stop trying to make up new and novel interpretations of a license whose meaning is well established in the community.

Thousands and thousands of organizations sell software that OEMs LGPL products like Hibernate or JBoss. Are you telling me they all need to go and release their software in open source now? Are you telling me some court is going to decide to magically reinterpret the license to mean something that neither party to the license wants it to mean??

dmd1214 · **Joined:** Fri Mar 03, 2006 3:36 pm **Posts:** 9

Are you it is a stretch for someone to believe
(dynamicLink is link) == true

More relevantly, considering this LGPL quote…

Quote:

When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library

… are you saying that a shared library should not be considered analogous with dll?

I can’t sell that to the lawyers, Gavin, because I can’t sell it to myself.

To answer your question…

Quote:

Are you telling me some court is going to decide to magically reinterpret the license to mean something that neither party to the license wants it to mean??

“Wants” is not the question… “Says” is the question. And yes, I can imagine some crazy American court accepting to hear a case and using the LGPL to literally find that “executables” using NHibernate must be offered as opensource.

I would love to be wrong here. Believe me. But I need something more tangible than "wants it to mean".

pelton · **Posted:** Thu Apr 06, 2006 12:08 pm

There seems to be some work being done on the GPL and LPGL licenses. Maybe they will clear up some of the ambiguity.

Search GLP or LPGL on your favorite news search engine.

Here is one such article:

http://software.newsforge.com/software/ ... 147&tid=18

gavin · **Posted:** Thu Apr 06, 2006 12:16 pm

Let's look at the context of the quote you just read me:

Quote:

When a program is linked with a library, whether statically or using
a shared library, the combination of the two is legally speaking a
combined work, a derivative of the original library. The ordinary
General Public License therefore permits such linking only if the
entire combination fits its criteria of freedom. The Lesser General
Public License permits more lax criteria for linking other code with
the library.

ie. the sentence you just quoted me is explicitly describing the difference between the GPL and the LGPL. If your lawyers can't parse that, you need new lawyers.

Again, no court on earth is going to come up with some novel interpretation of this license that is totally different to what the FSF, the software authors (JBoss, primarily), and the software users (you guys) think it is.

The license goes on to say, in describing the intent of the LGPL:

Quote:

For example, on rare occasions, there may be a special need to
encourage the widest possible use of a certain library, so that it becomes
a de-facto standard. To achieve this, non-free programs must be
allowed to use the library. A more frequent case is that a free
library does the same job as widely used non-free libraries. In this
case, there is little to gain by limiting the free library to free
software only, so we use the Lesser General Public License.

In other cases, permission to use a particular library in non-free
programs enables a greater number of people to use a large body of
free software. For example, permission to use the GNU C Library in
non-free programs enables many more people to use the whole GNU
operating system, as well as its variant, the GNU/Linux operating
system.

Now what could possibly be clearer? How is any court going to reinterpret this license in a new and novel way that contradicts the EXPLICIT intent of the license as expressed in the preamble?!

gavin · **Posted:** Thu Apr 06, 2006 12:26 pm

http://en.wikipedia.org/wiki/LGPL

Quote:

The main difference between the GPL and the LGPL is that the latter can be linked to a non-(L)GPLed program, which may be free software or proprietary software.

Quote:

The LGPL places copyleft restrictions on the program itself but does not apply these restrictions to other software that merely links with the program.