Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (117)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  GNU takes position on LGPL and java  (Read 2848 times)
0 Members and 1 Guest are viewing this topic.
Offline z.e.r.o

Junior Member




Java games rock!


« Posted 2004-12-22 08:54:34 »

GNU took a position on the LGPL and Java question:

http://www.gnu.org/licenses/lgpl-java.html

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?).

Sorry for the rant Sad

Matteo Anelli
.brain - http://www.dot-brain.com
Offline phazer

Junior Member




Come get some


« Reply #1 - Posted 2004-12-22 10:24:08 »

Quote

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.


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.

Quote

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?).

Sorry for the rant Sad


Well, since you started it Smiley  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.

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #2 - Posted 2004-12-22 19:04:53 »

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.


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.

Hellomynameis Charlie Dobbie.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline phazer

Junior Member




Come get some


« Reply #3 - Posted 2004-12-22 20:07:28 »

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?


My interpretation is that they just describe the normal way of distributing Java libraries. It has no relevance to LGPL really.

Quote

Creating "a link"?  No, the (L)GPL makes a serious distinction between "static" and "dynamic" links.


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:

http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

Quote

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.


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.

Quote

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.


Java's dynamic linking can be compared to shared libraries which is available on most Unix systems (and Windows systems).

Quote

In the same way, the (L)GPL has been crafted specifically for the world of C, and it has limited applicability to other environments.


I disagree.

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #4 - Posted 2004-12-22 21:35:43 »

Quote
My interpretation is that they just describe the normal way of distributing Java libraries. It has no relevance to LGPL really.


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:

http://www.gnu.org/licenses/gpl-faq.html#MereAggregation


Apologies, I used the terms in error.  You're quite correct that the GPL terms are "combined" and "aggregated".

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.


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.


No problem, you're free to! Grin

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.


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?

Hellomynameis Charlie Dobbie.
Offline z.e.r.o

Junior Member




Java games rock!


« Reply #5 - Posted 2004-12-23 04:58:43 »

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

Matteo Anelli
.brain - http://www.dot-brain.com
Offline z.e.r.o

Junior Member




Java games rock!


« Reply #6 - Posted 2004-12-23 05:26:15 »

Quote

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.


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:

http://www.shudo.net/jit/perf/

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 (TM) 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 Sad
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.

Matteo Anelli
.brain - http://www.dot-brain.com
Offline bwbrooklyn

Junior Member


Projects: 2


Hmm. I just thought of something...


« Reply #7 - Posted 2004-12-23 15:07:49 »

Quote

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.


In other words there is no way to create a non-derivative work using LGPL (Java) code? Is that what you mean?

The Misadventures of M.A.D.S.
http://www.themisadventuresofmads.com
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #8 - Posted 2004-12-23 15:28:12 »

Aye, that be the rub. :-/

Hellomynameis Charlie Dobbie.
Offline phazer

Junior Member




Come get some


« Reply #9 - Posted 2004-12-24 08:40:22 »

Quote


In other words there is no way to create a non-derivative work using LGPL (Java) code? Is that what you mean?


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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline z.e.r.o

Junior Member




Java games rock!


« Reply #10 - Posted 2004-12-24 11:01:09 »

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?

Matteo Anelli
.brain - http://www.dot-brain.com
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #11 - Posted 2004-12-24 11:27:31 »

Quote


Apologies, I used the terms in error.  You're quite correct that the GPL terms are "combined" and "aggregated".


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

malloc will be first against the wall when the revolution comes...
Offline phazer

Junior Member




Come get some


« Reply #12 - Posted 2004-12-24 17:15:46 »

Quote

Morons. Really, they have *no idea* how to write legal documents and *no idea* how to organize a piss-up in a brewery.


That's a bit harsh considering the fact that GPL held up in German court:

http://www.groklaw.net/article.php?story=20040725150736471

I would say Sun's licenses are much worse than the GPL.

Offline phazer

Junior Member




Come get some


« Reply #13 - Posted 2004-12-24 17:24:14 »

Quote

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?


See this list for licenses that are compatible with the GPL:

http://www.gnu.org/philosophy/license-list.html

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.

Offline z.e.r.o

Junior Member




Java games rock!


« Reply #14 - Posted 2004-12-26 13:39:08 »

Quote


See this list for licenses that are compatible with the GPL:

http://www.gnu.org/philosophy/license-list.html



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.

Matteo Anelli
.brain - http://www.dot-brain.com
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

radar3301 (12 views)
2014-09-21 23:33:17

BurntPizza (31 views)
2014-09-21 02:42:18

BurntPizza (22 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (29 views)
2014-09-20 20:14:06

BurntPizza (33 views)
2014-09-19 03:14:18

Dwinin (48 views)
2014-09-12 09:08:26

Norakomi (74 views)
2014-09-10 13:57:51

TehJavaDev (103 views)
2014-09-10 06:39:09

Tekkerue (51 views)
2014-09-09 02:24:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!