LGPL

[auser]

I'm just trying to get GnuTLS working with PB. GnuTLS is mainly under LGPL (the parts I need are LGPL some other stuff I don't need anyway is GPL).
I've found different ways to do that. It works via ImportC or via PrototypeC but in both cases I need to define the functions and even some variables and structures of the header from gnutls.h
But if I use or convert such content to PB-Syntax out of an lgpl header file to be useable in PB what does that mean for my app afterwards?

Am I required to put even my app under the LGPL since it used modified parts of the header files?

Would there be a difference compared from ImportC or PrototypeC?

Greetings,
auser

[IdeasVacuum]

...Your questions need to be put to the authors of the lib you are using (GnuTLS?)

[freak]

The LGPL has a section concerning header files:

3. Object Code Incorporating Material from Library Header Files.

The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following:

a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License.
b) Accompany the object code with a copy of the GNU GPL and this license document.

I read that to mean that using function prototypes, structures, constants and variables is no problem.

[Zach]

Yeah, I imagine a statement like this would suffice.. No matter what license you release your program under

Portions of this software are based on/use parts of the gnuTLS library. Parts of the gnuTLS library that are used by this software are available in the /source/ directory included in this package. The modified version of the gnuTLS source for the PureBasic programming language is included in the /source/pb directory. The parts of this software which use gnuTLS, as well as the PureBasic source code for those parts are licensed under the terms of the LGPL.

Ok that's really basic, but its the general idea.. You'd have to work in specific rights and prohibitions according to the license, and what can/can't be done with the work, etc.
But I would assume, like Freak has touched on, if you include the source for your modified versions of the headers and whatever else you've had to use from the library, and license those portions under LGPL, there shouldn't be a problem...

Or I could be completely wrong. Interpreting all the various Licenses out there is a pain in the butt.

[freak]

Yeah, I imagine a statement like this would suffice.. No matter what license you release your program under

Portions of this software are based on/use parts of the gnuTLS library. Parts of the gnuTLS library that are used by this software are available in the /source/ directory included in this package. The modified version of the gnuTLS source for the PureBasic programming language is included in the /source/pb directory. The parts of this software which use gnuTLS, as well as the PureBasic source code for those parts are licensed under the terms of the LGPL.

Ok that's really basic, but its the general idea.. You'd have to work in specific rights and prohibitions according to the license, and what can/can't be done with the work, etc.
But I would assume, like Freak has touched on, if you include the source for your modified versions of the headers and whatever else you've had to use from the library, and license those portions under LGPL, there shouldn't be a problem...

Or I could be completely wrong. Interpreting all the various Licenses out there is a pain in the butt.

That is not how i read it. You only have to include a note if what you include exceeds simple structure/function/variable definitions:

[...] You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, [...], you do both of the following:

As long as you just use definitions you only have to include the license/statement with the library itself, and if that comes installed with the system/as a separate package then you are done already. This is just my interpretation though. I am not a lawyer.

[auser]

if you include the source for your modified versions of the headers and whatever else you've had to use from the library, and license those portions under LGPL, there shouldn't be a problem...

If I include just source then even the other part have to be LGPL. You may not just take source of LGPL code, include it to your source and use a different license afterwards. There are some exceptions which freak wrote above. But everything else have to be LGPL. And the question is if a pbi file is still some kind of header file that just includes numerical parameters, data structure layouts and accessors. I think it's a little bit more special in PB where it's not possible to just include an unmodified header like all other would do.

Interpreting all the various Licenses out there is a pain in the butt.

Yes. But LGPL is often used and I'm pretty sure I'm not the first one who is trying to use such content and asking himself that kind of question. Even PB itself used LGPL stuff with OGRE (which moved to some MIT license in 1.7 as far I remember) and not to forget SDL (linux part).


Greetings,
auser

[Zach]

True, you cannot include an unmodified header. But in my opinion, practically speaking, including the unmodified original header itself in a source directory, is practically the same thing. Either way people have access to the unmodified original source, yes?

But like I said....pain in the butt, and all that.

[freak]

In the section i quoted above, it sais:

The object code form of an Application may incorporate material from a header file that is part of the Library. [...]

Your 'object code' (= executable) may include material from the headers as long as it is just definitions as the section further specifies. Whether or not this 'material' existed in the form of a pb file before it ended up in your object code is irrelevant.

You can see the PB file as a translation step, just as ASM code is a translation step when compiling C or PB code. When you are translating the definitions to PB so you can use the library, you are not creating "a work based on the C header". All you do is "compile" it to PB.

If this were a problem, then the whole LGPL would be pointless for libraries. This is why this header exception exists in the first place. The whole point of the header file is to enable you to use the library.

[SFSxOI]

I'm just trying to get GnuTLS working with PB. GnuTLS is mainly under LGPL (the parts I need are LGPL some other stuff I don't need anyway is GPL).
I've found different ways to do that. It works via ImportC or via PrototypeC but in both cases I need to define the functions and even some variables and structures of the header from gnutls.h
But if I use or convert such content to PB-Syntax out of an lgpl header file to be useable in PB what does that mean for my app afterwards?

Am I required to put even my app under the LGPL since it used modified parts of the header files?

Would there be a difference compared from ImportC or PrototypeC?

Greetings,
auser

along with the above other replies ...

The LGPL covers things/methods created from, or used from, the items covered under the LGPL as they exist in the LGPL covered code. It does not cover things that are new and unique that you create on your own without the LGPL covered items even if they do produce the same result. If you directly convert an item method from the LGPL items to a PB version then the LGPL applies unless stated in the LGPL otherwise, if you create something new that does something like the LGPL item and did not use the LGPL item method to create such a thing then that is not covered by the LGPL (its the same with most things, like car tires for example - they all do the same thing but only the processes/materials/methods used for a specific brand is patented but the general function is not.) If something is commonly publically available under public domain and is not covered by the LGPL and does something similar to the LGPL function method then the LGPL does not apply. You can mix and match things with things that are covered under the LGPL, if you do this only the parts of your code that use the LGPL items would be covered under the LGPL and your statement(s) should indicate that as well like "parts of this code are covered under the LGPL.... blah blah blah" and include the LGPL required license stuff in the documentation/comments, but you do not need to identify specific portions which are or are not covered. This being said, you can duplicate a way of doing something as long as you do not duplicate the license method. If you do duplicate the license method in any form then its covered under the license. Only a method is licensable, not the end result. If for example (very simple example and not the best one as common general simple math would not be covered under the LGPL), if a method under the LGPL to arrive at a result of 2 is "1 + 1 = 2", then you can't use that method to get the same result but you can do "4 + 4 - 6 = 2" - the same result but different methods used to arrive at the result, a better example would be:

Code: Select all

LGPLFunctionMethod openourspecialfile()
ourfile + that file + their file = somefile
start or open our file somefile

The result is the target file being opened
Using that specific LGPL method, even if converted to a PB version, would be covered under the LGPL
  
  
However; if you use the Pure Basic OpenFile(#File, somefile$)
The result is the same but uses a different method that is not covered under the LGPL (that is unless the PB OpenFile is covered under the LGPL)

Methods are licensened, not results.

[auser]

@SFSxOI: I think that would not really help any further regarding the material used in header files? Or how should the method of variable definition should be remixed?

ERROR_SUCCESS = 0;

ERROR_SUCCESS = 1-1 ; // this would suck...

Anyway I agree with freak: If this were a problem, then the whole LGPL would be pointless for libraries.


One point I'm still not sure is comparrision regarding "ImportC" and "PrototypeC and GetFunction". With ImportC I can use .obj and .lib and with PrototypeC and Getfunction I can use .dll. I guess using the .obj is static linking (and would cause my application to be LGPL) but I'm not sure regarding .lib.

Greetings,
auser

[SFSxOI]

@SFSxOI: I think that would not really help any further regarding the material used in header files? Or how should the method of variable definition should be remixed?

ERROR_SUCCESS = 0;

ERROR_SUCCESS = 1-1 ; // this would suck...

Anyway I agree with freak: If this were a problem, then the whole LGPL would be pointless for libraries.


One point I'm still not sure is comparrision regarding "ImportC" and "PrototypeC and GetFunction". With ImportC I can use .obj and .lib and with PrototypeC and Getfunction I can use .dll. I guess using the .obj is static linking (and would cause my application to be LGPL) but I'm not sure regarding .lib.

Greetings,
auser

No, not a constant because a constant is just simple math, it just is = to something (a result, which makes the constant a result) so ERROR_SUCCESS could be used without attributing the license (although if there is a specific name for the constant such as LGPL_ERROR_SUCCESS that is specific to the code and not in general public domain use then either you rename the constant to something else, use a comparable name like from the MS API, or use the same name and attribute the license because the LGPL_ERROR_SUCCESS constant name is specific to that code LGPL). If it were a method though thats specific to the LGPL code to arrive at a constant value then you can't use that specific method to arrive at that same constant value unless you attribute the license in your code. Of course, anything that the LGPL aready allows can be done, and freak is correct. Methods are licensed, results are not.