LPGL Legal Issues - Utterly Confused (SDL & OpenAL)

1. Any code that does not statically link the library.
Found here
2. Just dynamically link your application
3. You don't have to release anything, but if you want to release source code you can. Looks what ID did with Doom and Quake.

PS: here's a peice of the LGPL that might help a bit more on your concerns:

The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, while the latter only works together with the library.

I admit I am a bit confused by section 6 (your code is isolated from the LGPL license) and section 5 (your code is now under the LGPL license), too.

There was some rumblings about how that various interpretations of section 5 and 6 of the LGPL could be legally inforced if you had, say, a Java application that used LGPL classes. (Is Java doing "linking" as the license says in 5, or is it runtime loading, such as a DLL in section 6?)

But for C/C++, appearently if you read those sections more in detail, it does seem to discount dynamically linked libraries. (Even the headers of a LGPL project can be compiled in, as long as it's just "numerical parameters, data structure layouts and accessors, and small macros/inline functions".)

However, that part of the license is a bit fuzzy and it has lead to a lot of confusion.

I think an audio library that used OpenAL as its backend would fall into section 5 as a derivative work, and therefore is subsumed under the LGPL license. (In other words, your library couldn't stand without OpenAL.) Here, see this from Section 5:

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

But then again, IANAL, so take my advice with a huge grain of salt.

Thank you both for your explanations, it makes a lot more sense now.

@eedok - That page is exactly what I needed but couldn't find. Thanks! However it really seems that their statement:

Quote:

The simple answer is "Yes", just dynamically link with SDL and you're fine. You do not have to include the source code to your application, since the end user can drop in a new version of the SDL shared library, which is the intent of the license.

Conflicts with what is said on the license page, which has got me in a bind.

@FenrirWolf - Thank you for that as well. I am getting tripped up on 'using' and 'derviations' of work. My audio uses OpenAL right now as its backend, so I can see now it is under the LPGL license, especially since without OpenAL, it couldn't stand. However, If I made it so it did not have to have OpenAL, which is not possible for what I am dong, but still hypothically, then could I abide with what SDL says about "just dynamic link in the .dlls"?

Once again thank you for your time.[smile]

- Drew

I still don't see the part of the license that conflicts with what the SDL page says. As for the OpenAL license, would the end user be able to relink the library if they made changes to it? If the answer is yes, then the way you're releasing it is fine.

Quote:

Original post by eedok I still don't see the part of the license that conflicts with what the SDL page says. As for the OpenAL license, would the end user be able to relink the library if they made changes to it? If the answer is yes, then the way you're releasing it is fine.

This is what I am talking about:

Quote:

You do not have to include the source code to your application, since the end user can drop in a new version of the SDL shared library, which is the intent of the license.

Then

Quote:

You must also do one of the following: 1. Include the source code for the version of SDL that you link with, as well as the full source or object code to your application so that the user can relink your application, or 2. Include a written offer, valid for at least three years, to provide the materials listed in option 1, charging no more than the cost of providing this distribution, or 3. Make the materials listed in option 1 available from the same place that your application is available.

Which # would I be doing if I did not release source code or anything else and I dynamically linked? On the OGRE site they give a short faq like SDL but they say:

Quote:

The above is a precis, please read the full license agreement before downloading any source.

Thanks your for your time and patience, but that is what I am getting lost about.

- Drew

Two simple requirements.

1. make it so the user can change SDL and used the changed version with your program. (a) by dynamic linking or (b) by providing an object file that could be linked with an SDL object file to produce and executable.

2. provide a link to download the SDL source on your site. (OR, include the source with your program. OR, written offer to mail it. most people don't do these)

Thank you for making that more clear C-Junkie, one last question though:

Quote:

2. provide a link to download the SDL source on your site. (OR, include the source with your program. OR, written offer to mail it. most people don't do these)

What is SDL source defined as? The code of the SDL version you used, all of your game's source code that uses SDL, the entirety of your game's source code, or a combination of the first and third/second? I have to assume that you do not have to release the media files as well, but if you used scripts, then would you have to release that as well?

---

Here is what I am thinking about. What is to stop someone from let's say using AngelScript to script an entire game. The basics of setting up SDL is done in the .cpp file, but everything else is from scripts. To release the 'source code' that simply means giving out the base framework which sets up SDL as well as AS. Evrything else, since it's scripted can remain confidential. Technically, you will still be able to 'buidl' the game, it just won't do anything.

- Drew

Quote:

What is SDL source defined as? The code of the SDL version you used, all of your game's source code that uses SDL, the entirety of your game's source code, or a combination of the first and third/second? I have to assume that you do not have to release the media files as well, but if you used scripts, then would you have to release that as well?

The source of SDL in general(ie putting made with SDL http://libsdl.org on your title screen of your game would be sufficient).

Quote:

Original post by eedok The source of SDL in general(ie putting made with SDL http://libsdl.org on your title screen of your game would be sufficient).

Technically, no. The source has to be available from the same location as your work that uses it, for example:

http://myawesomesite.net/mygame.tar.gz
http://myawesomesite.net/libSDL-1.2.7.tar.gz

Although very few people do this, and IIRC Sam Lantinga (author of SDL) has specifically stated he doesn't mind. Some authors of LGPL libraries could potentially get very upset about this, although I hardly see why.

Ahh thanks Cozman. I guess I will need to talk to someone in the legal field eventually to determine if my software (audio library) will fall into the section 5 or section 6 and why. Although I am still curious about my last question:

Quote:

What is to stop someone from let's say using AngelScript to script an entire game. The basics of setting up SDL is done in the .cpp file, but everything else is from scripts. To release the 'source code' that simply means giving out the base framework which sets up SDL as well as AS. Evrything else, since it's scripted can remain confidential. Technically, you will still be able to 'build' the game, it just won't do anything.

- Drew

[edit]Awesome, thanks for that cozman![/edit]

[Edited by - Drew_Benton on February 17, 2005 9:29:27 PM]

Quote:

Original post by C-Junkie Two simple requirements. 1. make it so the user can change SDL and used the changed version with your program. (a) by dynamic linking or (b) by providing an object file that could be linked with an SDL object file to produce and executable. 2. provide a link to download the SDL source on your site. (OR, include the source with your program. OR, written offer to mail it. most people don't do these)

Is absolutely correct, just make sure that if you want to be super safe, you host a mirror of the SDL source on your site.

To answer your question, the LGPL does not affect that, you don't even have to give away the code you wrote in SDL, let alone the Angel Script code, it's no different.

Ok thank you everyone! I think I have reached a final conclusion. In section 6, which is defined as

Quote:

6. 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. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: ... b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. ...

That is more than understandable now so I can see why it is ok to just dynamically link and provide SDL's source code. I comprede now thanks to your guys explanations [smile].

- Drew Benton

Quote:

a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)

If I wanted to satisfy the LGPL under clause a), does that mean I'd include my game's .o files with my distribution along with the library covered by the LGPL?

- carb

If you dynamically link to a LGPL library, you do not have to release object files. You can simply release your exe. The reason for this is that if the user wants to change the LGPL library he just needs to recompile it. Since your program is dynamically linked, then the changes will show up in your program.

If you statically link to a LGPL library, you must release source code or object files so that the user can make adjustments to the LGPL library and have them be reflected in your program.