Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Keermalec

Concerned with the LGP License for openIL

This topic is 6408 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

This is indirectly related to OpenGL as NeHe has recently put OpenIL versions of his tutorials online. OpenIL is a fantastic tool for importing several image file formats, distributed under the "Lesser General Public License" or LGPL. I recently read it through and it seems to say that an executable which uses OpenIL must also be distributed under the LGPL.
quote:
...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.
In short, the license gives you the obligation to make your source code available for a simple distribution fee at most. What this means is: any game or app you make with OpenIL has to be distibuted with source code. Did I get this right? You can read a copy of the LGPL here. Edited by - Keermalec on 11/30/00 7:29:38 AM

Share this post


Link to post
Share on other sites
Advertisement
I hope not.

There may be a difference between a dynamic linkied library and a linked library.

Interesting issue, anyone knows what can be done ?

Share this post


Link to post
Share on other sites
Afaik, the LGPL is ment for libraries to AVOID the viral aspect of it''s big brother, the GPL. the GPL forces any application that links with a GPL-ed piece of software to also be published under the GPL and thus has to open up the source code.

the LGPL does not force you to do that. However, if you make modifications to a LGPL-ed licensed piece of software and distribute THAT as executable you have to publish the modified piece of software also as sourcecode.

Thus not your application.

If you compare the LGPL with the GPL you''ll see this difference. Check out the LGPL and the GPL licenses at www.gnu.org.

(rule of thumb: Avoid GPL-ed software libs if you don''t want to publish your sourcecode. Avoid *GPL-ed software libs if you don''t want to publish modifications in sourceformat.)

--

Get productive, Get DemoGL: http://www.demogl.com

Share this post


Link to post
Share on other sites
If I understand the language of the LGPL, it says that commercial applications may use LGPL'ed libraries and not release the source code to the application. If you make mods to the library, you MUST release those as source code to the public. If anyone disagrees please let me know.



Edited by - europa on November 30, 2000 10:26:05 AM

Share this post


Link to post
Share on other sites
Hi,

Rather worryingly, section 6 of the LGPL states that if you statically link to the library, not only does the library source need to be made available, but also enough of your code to rebuild the executable should the library change. This can be in the form of object files, but it is still bad news.

The alternative is to link to a .DLL (or other dynamically linked) version. This way, only the library source code has to be made available, even if it is unmodified.

So basically, if you want to keep your source closed, only use LGPL libraries that are available in a .DLL form. I haven''t looked at OpenIL so I don''t know whether it is available as a DLL.

Dan

Share this post


Link to post
Share on other sites
Well from what I can see, you need to link openil.lib and include openil.h to compile an executable using openil. Then that executable needs openil.dll to run. So you are including a portion of the library in your executable, and so it seems your executable comes under the terms of the LGPL... But I hope I''m wrong.

Share this post


Link to post
Share on other sites
Hey, thanks for your support of OpenIL. Now, about the LGPL problem...if you dynamically link with OpenIL (use the dlls that are generated by any MSVC++ project included), you don''t have to release *any* of your source. The openil.lib that you link with to access the dll basically does not count, as you could load OpenIL yourself with GetProcAddress(), etc. The problem with static linking is that it is against the LGPL, though I would like for people to be able to statically link with OpenIL and posted something about this on the site awhile ago (don''t think I made an archive, sorry). Of course, this affects DJGPP users, who don''t have any kind of dynamic-loading mechanism... The only main thing that the LGPL is trying to protect against someone ripping my code and putting it in a closed source program. If you modify OpenIL in any way, you must release the sources that you modified (to my understanding of the LGPL). This is to keep a million different incompatible versions of OpenIL floating around. I hope I''ve answered everyone''s questions. Always feel free to send me an e-mail -- I usually respond. =]

Share this post


Link to post
Share on other sites
Keermalec: if there is a dll, you''re not statically linking. The .lib is just the importlibrary for the linker to setup stubcode (generated by your compiler) so the dll gets loaded and your program can call the functions properly. Therefor, if you link to a LGPL-ed library that is distributed as a .h, .lib and .dll / .so package, you can safely use it in your non-LGPL application, because you''re not statically linking.

Statically linking is done when you just have a .lib and a .h (f.e. the jpeglib is distributed that way). The compiler will ADD portions of the code (all code is in the .lib) in the .lib into your own program. So THEN you''re adding portions of the LGPL-ed program (but via the compiler) to your program and you should distribute the program under the LGPL.

However I don''t think the GPL, nor the LGPL will hold up in court because by LAW no license can force you to violate your own right how to distribute your OWN property.

DoomWiz: you could release the stuff under 2 licenses: 1 for the continueing of the library (and that''s thus the only stable version tree), and you choose the LGPL for that, and one for people who want to statically link to libraries because perhaps they also made a library using your library, and thus the user of THEIR library has to distribute more than 1 library while he just uses 1, so choose the BSD license for that, so people can statically link to the library.

You can also make your own license of course. Use the LGPL but remove the part about statically linking and sourcecode. (oh, and call it differently than ''LGPL'')

But it''s up to you if you want that. I understand the importance of ''opening up changes to the community'', but at the same time that power is also a delimiter on the userbase: potential programmers who want to use your lib will now back off because of the restrictive license terms. If that''s fine by you, no problem, if you don''t want that: add another license or change the license.



good luck.

--

Get productive, Get DemoGL: http://www.demogl.com

Share this post


Link to post
Share on other sites
SUMMARY:

Dynamic linking:
CLOSED SOURCE CODE ALLOWED.

Static linking:
OPEN SOURCE CODE ONLY.


let''s go for dynamic linking...

BTW you cannot know if people are taking part of your code in their closed source code, and it''s possible to take your code and use it freely if modified at more than 50%.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!