Since we talked about it many times, I think that someone can find it interesting.
The assertion that you must deploy the lib in a separate jar to be LPGL-complaiant is a bit moronic, since there’s no difference if you deploy a lib within the main jar or in a separate one, java-side. In addition, we may say that Java dynamic links everything so an inclusion is always LGPL complaiant, but we must also consider that Java is not linking the way C/C++ does, so…
My opinion is to stay away as much as one can from GNU theological licensing, since they’re more concerned about creating an open source superpower centered around GNU itself instead of promoting inter-licenses open source collaboration like OSI do (in fact most OSI approved licenses are not considered compatible with GNU, and highly criticized by Stallman & co… that’s odd, open source shouldn’t be all on the same side?).
I don’t understand what you mean here. The text you link to doesn’t say a LGPL library must be distributed in a separate jar.
Well, since you started it GNU is not about creating a “open source superpower” it’s about keeping free software free. The GPL and the LGPL ensures that any modifications you make to free software also must be released as free software. I think this is a reasonable request. But you should choose the software license that fits best for your project and your mentality.
This has been a (minor) annoyance for me for many years. I’ve attempted to contact the FSF myself to clarify the (L)GPL wrt. Java, and have never had a response. I’m glad someone finally made them sit up and take notice. Although it’s not much better than silence, really…
It may or may not mention distributing LGPL code in a separate jar file - in true FSF tradition, they’ve missed the point completely, failed to understand the problem domain, and then proceeded to muddy the waters even further with vigorous hand-waving, and without explaining a damn thing.
[quote]The typical arrangement for Java is that each library an application uses is distributed as a separate JAR (Java Archive) file. Applications use Java’s “import” functionality to access classes from these libraries. When the application is compiled, function signatures are checked against the library, creating a link. The application is a then generally a derivative work of the library. So, the copyright holder for the library must authorize distribution of the work. The LGPL permits this distribution.
[/quote]
This paragraph can be read in several ways. Does the LGPL permit the distribution of code only if it’s in a separate jar? Otherwise what is the point of the first sentence?
Creating “a link”? No, the (L)GPL makes a serious distinction between “static” and “dynamic” links. Which is this? The statement that the application becomes a derivative work seems to imply they mean static! Sounds like there’s no place in Java for dynamic linking.
As regards “checking function signatures” on compilation - are they talking about the source-to-bytecode compile? Because that sounds like if you “compile” against a public-domain interface, you can (once compiled) substitute in an LGPL library and avoid the whole issue. Hell, I’ll write a program to reverse-engineer compliant interfaces for anyone who wants one - half a page of Reflection should do it.
As Java developers generally deal with APIs, not implementations, stating that compiling against a library is the same as the GPL’s “static link” concept is utterly broken - that may be how C works, but Java is a different beast altogether. Compiling to interfaces is something that C developers never have the option of, thus the (L)GPL has not been equipped to deal with it.
The FSF need to have a chat with some serious Java developers, get to know the system, read through their licences, then write new ones for Java developers to use. A wise man once said to me that once you realise that C was written solely for the purpose of writing UNIX, you’ll understand why there are much better language choices for writing applications and non-UNIX operating systems. In the same way, the (L)GPL has been crafted specifically for the world of C, and it has limited applicability to other environments.
My interpretation is that they just describe the normal way of distributing Java libraries. It has no relevance to LGPL really.
The only place where the LGPL mentions static and dynamic linking is in this sentence:
“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.”
So, there is no difference between static and dynamic linking. The GPL doesn’t mention linking at all. The GPL FAQ explains it best I think:
You can do whatever you like as long as you don’t distribute or copy software copyrighted by some other person. The purpose of a license is to allow you to copy and distribute some other persons copyrighted work. The function and class signatures in a library is copyrighted by the person who wrote the library. If the library is released under LGPL the signatures are covered by LGPL as well. If you compile a Java application that uses the library you have included part of the library in you application (the class and method signatures) and thus you have created a derivative work. It doesn’t matter if you distribute the library with the application or not. That’s my interpretation.
Java’s dynamic linking can be compared to shared libraries which is available on most Unix systems (and Windows systems).
[quote]My interpretation is that they just describe the normal way of distributing Java libraries. It has no relevance to LGPL really.
[/quote]
If I were responsible for the legality of a distributed program, I wouldn’t like to rely on anything so vague as that description - I think that’s my point.
[quote]So, there is no difference between static and dynamic linking. The GPL doesn’t mention linking at all. The GPL FAQ explains it best I think:
But what do you consider “aggregation” in the Java context? As a Java application has zero reliance on a particular implementation of a library, it sounds as though all Java applications are “mere aggregations” - and therefore the GPL has no hold over the users of GPL libraries.
[quote]The function and class signatures in a library is copyrighted by the person who wrote the library. If the library is released under LGPL the signatures are covered by LGPL as well.
[/quote]
I think reverse-engineering and free-use come into play there. But even if they don’t, how about a GPL implementation of the Java 1.4 logging API? My application may be using it, I may be distributing the library in my download, but by the description the FSF have released to clarify their position, it seems like the GPL also has no hold here either.
[quote]I disagree.
[/quote]
No problem, you’re free to! ;D
Don’t get me wrong - I like the GPL. I’ve released code under it, I’ve contributed to projects licenced under it, and every day I benefit from the work of the FSF. I’d love to see the GPL better accepted by the Java community, because I really do feel there is space in this world for RMS’s utopian vision. However, I stand by my opinion that the GPL and everything that currently exists around it just doesn’t work outside of C-land. Here’s a quote from the section of the FAQ you linked to above:
[quote]If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
[/quote]
Now, if we had a Java-centric FAQ to go alongside the GPL, that might clear everything up. As it is, with no guidelines as to the intention of the GPL in the Java context, it’s all rather up in the air. You can get the gist of things, and make some pretty reasonable assumptions, but what business would go forward with a GPL’d Java library today, given that?
Well, thanks for the feedback, I agree that, as usual, is a mess!
The dark points of the license is the bad thing, IMHO.
Lots of people are using it just because has GPL on the name and GPL is cool by definition. This attitude is hindering many Java projects (game or not), like JOrbis, some IT java libs (recently we had to drop a template engine for an application just because it was under LGPL and was unclear what we had to do with it on java).
The odd thing is that if you contact developers, many times they give you directions that openly violate the license they’re using (and the author agreement doesn’t keep you at safe from GPL or GPL zealots retailation, since GPL licenses supersede the author’s willing) or they say that they don’t care how you use their program as soon you give them credits (so why not publish it under BSD, instead?).
This happened to me with SDL (3 years ago when the project was in its infancy more or less) and with JOrbis (at the beginning of this year).
I agree totally. I was an hacker when I was young (every developer begins his work doing hacks, I think), even today I’m very supportive or open source and from my skill tree you’ll clearly see that I’m also skilled to do linux kernel hacking and embedded systems programming. Sometimes these skills are intersected with the old way of making games (C/C++ with lots of asm involved).
The problem is that I’m not a low level programming language zealot, just like I’m not a Java zealot.
Open Surce and linux/hacking world are modeled like C/C++, they are very hard to modification and reuse, in other words, they are stubborn. The LGPL was conceived for C (it has or had explicit references to C, just like GPL has), many hackers see every non-C languages as a menace to be destroyed since they’re slow and inefficient, not even these figures make them change their limited attitude:
This is a common misconsception, even in super closed worlds. To my misfortune I had the unluck to be able to work/outsource/consult new technology & programming paradigms for some big names of european gaming industry. I was always treated as a moron (more or less), that is wasting his time over a dead technology by C/C++ dinosaurs that never took an architectural approach to remove code inefficiency from their games.
So IMHO is not uncommon that they are simply not expert enough (or we must say disinterested) on the matter to tackle the license on that way, even because GNU seems interested on pushing only .NET (they aim to be the MS of linux world after all, and they already are as raw power and software support) and always openly attacked Java.
Even with these premises if you talk with many open developers or attend to OS conferences like I’m usually do you’ll shockingly discover that most of them judges every new technology and language as a great step back ™ off from their beloved C and system dependance. After all, they love to say, C is portable and multiplatform enough, you just have to recompile it (no matter if you’ll mess with dependancies and obscure scripts 90% of the time).
I think that the open source in general has a common vision with the traditional gaming industry: the will of not change the way of the things and to not get the new technology fast enough.
I think OOP languages are hairy for licenses that impose you their support just because of the implications of inheritance, dynamic invocations, reflections etc etc, I don’t want to know how AOP will fare in this scenario
Better to remain in the world of static & dinamic link where the deployment alternatives does not grow exponentially and clever programmers cannot use your code without comply of the multitude of limitations/obligations of some OS licenses imposes.
The protection of status quo, IMHO is not such a strong point to oppose to the progession of technology.
As soon as you compile a Java application against a LGPL library you have created a derivative work. An application that is not compiled can be a non-derivative work.
So we can finally assume that the clarification clarifies nothing?
Or, that it clarifies that everything using LGPL in Java is a derivative work?
The question is why an open source lincense may “assimilate” other people work? Aside the fact it is of the GNU family and may use it without knowing exactly the implications this can hinder the usability of many really good projects in other open project (leave the closed aside, i’m not fond of it) shipped with another OSI license, since GNU doesn’t permit license-mixing (unless the license is itself GNU approved), I’m right?
No - they changed the license. It used to say static and dynamic.
Morons. Really, they have no idea how to write legal documents and no idea how to organize a piss-up in a brewery.
/me would like to make it clear that is only the morons who write the licenses and spread masses of FUD because their heads are so far up their own arses they can watch themselves fart who he’s calling morons
/me has dealt with several authors who gave up open-sourcing their code because they couldn’t get the LGPL or GPL to work / couldn’t get one frigging straight answer out of the gpl people. Most just made it BSD or etc, thereby completely undermining the point of GPL due to the sheer lunatic incompetence of the license morons. Only one (maybe two?) that I can remember made their source closed instead, and just gave away licenses individually upon request
I would be very hesitant to using the LGPL for any project as it is a much more complicated and ambigous license than the GPL (just read your comments in this thread). The BSD license is a much simpler license if you want to allow your library to be used in closed source projects.
My biggest concern with the GPL is that the Apache license is NOT (yet) GPL compatible which means that you can’t use libraries licensed under the Apache license in a GPL project.
That’s the whole point of my rants. I don’t want political/religious gurus, I want my projects to be open, licensed and protected by law.
GPL seems to do this (just because most projects are GPL) but it won’t. Their only concern is taking control over open source, they only have control in mind (Mono was born to try to take control on the ever-growing bytecode-VM world under the GNU hood, since the ever-despised Java is becoming more and more prominent and less controllable).
In addition GPL does NOT protect independent developers, like they like to say.
To make FSF and GNU stand for you in tribunal you have to tranfer or copyrights to them (I’m not joking, the Miranda ICQ team bit that bullet too), and NOTHING assure you that you have the rights back when done.
To retain your project & your rights you have to do it yourself like with any other license in the world.
My 2 cents about licenses:
Don’t care of reuse-reselling of your code but want credits: BSD
You want an open not-commercial (for the product itself, not for support or other accompaining items) license: Artistic
If Creative Commons will get more and more approved by national legal institutes, they will probably straighten the world of OS licenses more that GPL or OSI did.
CC only cares about the freedom, without compelling you (or your users) to do anything and without nasty side effects.
GNU is not about creating a “open source superpower” it’s about keeping free software free. The GPL and the LGPL ensures that any modifications you make to free software also must be released as free software. I think this is a reasonable request. But you should choose the software license that fits best for your project and your mentality.