TDBF licensing

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

TDBF licensing

Graeme Geldenhuys-6
Hi,

Am I correct in understanding that TDBF included with FPC is a LGPL
licensed component, the one that doesn't have the static linking
exception. So I can't use it in any commercial products or tools without
being forced to release all my source code?

Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TDBF licensing

Jonas Maebe-2
On 30/06/15 00:09, Graeme Geldenhuys wrote:
> Am I correct in understanding that TDBF included with FPC is a LGPL
> licensed component, the one that doesn't have the static linking
> exception.

TDBF originally comes from http://sourceforge.net/projects/tdbf/ and is
indeed distributed under the LGPL.

> So I can't use it in any commercial products or tools without
> being forced to release all my source code?

It doesn't matter whether the products or tools are commercial or not.
The LGPL means that if you link statically against TDBF, you have to
provide (on request) the object files of your program to customers that
bought the original tool so they can relink it against newer/modified
versions of the TDBF code.

There is no reason why you would ever have to release your own source
code, except if you would start mixing your own source code into the
TDBF units or so.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TDBF licensing

Graeme Geldenhuys-6
Thanks Jonas for all the information. I'll pass this information on to
the person that asked me.

Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TDBF licensing

Adriaan van Os-2
In reply to this post by Jonas Maebe-2
Jonas Maebe wrote:
> It doesn't matter whether the products or tools are commercial or not.
> The LGPL means that if you link statically against TDBF, you have to
> provide (on request) the object files of your program to customers that
> bought the original tool so they can relink it against newer/modified
> versions of the TDBF code.
>
> There is no reason why you would ever have to release your own source
> code, except if you would start mixing your own source code into the
> TDBF units or so.

Wikipedia <https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License> writes

        Essentially, if it is a "work that uses the library", then it must be possible for the software to
be linked with a newer version of the LGPL-covered program. The most commonly used method for doing
so is to use "a suitable shared library mechanism for linking". Alternatively, a statically linked
library is allowed if either source code or linkable object files are provided.[2]

The most common solution is to compile LGPL code into a shared/dynamic library.

Regards,

Adriaan van Os

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: TDBF licensing

Jonas Maebe-2

Adriaan van Os wrote on Wed, 01 Jul 2015:

> Jonas Maebe wrote:
>> There is no reason why you would ever have to release your own source
>> code, except if you would start mixing your own source code into the
>> TDBF units or so.
>
> Wikipedia  
> <https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License>  
> writes
>
> Essentially, if it is a "work that uses the library", then it must  
> be possible for the software to be linked with a newer version of  
> the LGPL-covered program. The most commonly used method for doing so  
> is to use "a suitable shared library mechanism for linking".  
> Alternatively, a statically linked library is allowed if either  
> source code or linkable object files are provided.[2]

Of course releasing the source code is also fine, but it's never required.

> The most common solution is to compile LGPL code into a  
> shared/dynamic library.

This is currently quite hard with FPC, as every library compiled with  
FPC contains its own RTL and hence does not share the RTL state with  
the applications that use it. To solve that, you need Delphi-style  
dynamic packages support, which Sven is working on.


Jonas


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Duplicate RTLs

Adriaan van Os-2
Jonas Maebe wrote:

> This is currently quite hard with FPC, as every library compiled with
> FPC contains its own RTL and hence does not share the RTL state with the
> applications that use it. To solve that, you need Delphi-style dynamic
> packages support, which Sven is working on.

Where is sharing-the-RTL-state an issue ? I compiled several plugins with FPC for the same
application and never ran into a problem with duplicate RTLs. But I don't use much of the RTL.

Regards,

Adriaan van Os

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Duplicate RTLs

Jonas Maebe-2

Adriaan van Os wrote on Wed, 01 Jul 2015:

> Jonas Maebe wrote:
>
>> This is currently quite hard with FPC, as every library compiled  
>> with FPC contains its own RTL and hence does not share the RTL  
>> state with the applications that use it. To solve that, you need  
>> Delphi-style dynamic packages support, which Sven is working on.
>
> Where is sharing-the-RTL-state an issue ?

The main ones will be allocating/freeing memory unless you use  
cmem/sharemem (including passing around reference counted types),  
exception catching (your program's exception class won't be related to  
the library's exception class), anything involving global variables  
(either implementation or interface) in units that exist both in the  
library and in the program.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Duplicate RTLs

Sven Barth-2

Am 01.07.2015 16:21 schrieb "Jonas Maebe" <[hidden email]>:
>
>
> Adriaan van Os wrote on Wed, 01 Jul 2015:
>
>> Jonas Maebe wrote:
>>
>>> This is currently quite hard with FPC, as every library compiled with FPC contains its own RTL and hence does not share the RTL state with the applications that use it. To solve that, you need Delphi-style dynamic packages support, which Sven is working on.
>>
>>
>> Where is sharing-the-RTL-state an issue ?
>
>
> The main ones will be allocating/freeing memory unless you use cmem/sharemem (including passing around reference counted types), exception catching (your program's exception class won't be related to the library's exception class), anything involving global variables (either implementation or interface) in units that exist both in the library and in the program.

Not to mention RTTI (basically a superset of the "exception handling" case mentioned by Jonas).

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Duplicate RTLs

Marco van de Voort
In our previous episode, Sven Barth said:
> exception class), anything involving global variables (either
> implementation or interface) in units that exist both in the library and in
> the program.
>
> Not to mention RTTI (basically a superset of the "exception handling" case
> mentioned by Jonas).

Also RTTI like class info (not used over typinfo unit) like IS, AS, .InheritsFrom?
IOW Objecttype identity operations.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Duplicate RTLs

Adriaan van Os-2
Marco van de Voort wrote:
> Also RTTI like class info (not used over typinfo unit) like IS, AS, .InheritsFrom?
> IOW Objecttype identity operations.

Thanks for the info. I suggest to document this somewhere. But I am not (in my own code projects)
using RTTI, class info, FPC memory allocation, reference counted types, exception catching or
global variables. Which explains that I never got in trouble there.

Regards,

Adriaan van Os

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Duplicate RTLs

Sven Barth-2
In reply to this post by Marco van de Voort

Am 01.07.2015 21:40 schrieb "Marco van de Voort" <[hidden email]>:
>
> In our previous episode, Sven Barth said:
> > exception class), anything involving global variables (either
> > implementation or interface) in units that exist both in the library and in
> > the program.
> >
> > Not to mention RTTI (basically a superset of the "exception handling" case
> > mentioned by Jonas).
>
> Also RTTI like class info (not used over typinfo unit) like IS, AS, .InheritsFrom?
> IOW Objecttype identity operations.

That's what I meant with RTTI. From the compiler/RTL point of view all that /is/ RTTI (in the literal sense as "runtime type information", not the "published properties" etc we usually understand as it).

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Duplicate RTLs

Marco van de Voort
In reply to this post by Adriaan van Os-2
In our previous episode, Adriaan van Os said:
> Marco van de Voort wrote:
> > Also RTTI like class info (not used over typinfo unit) like IS, AS, .InheritsFrom?
> > IOW Objecttype identity operations.
>
> Thanks for the info. I suggest to document this somewhere. But I am not
> (in my own code projects) using RTTI, class info, FPC memory allocation,
> reference counted types, exception catching or global variables.  Which
> explains that I never got in trouble there.

Note various to/from string and date types use locale info that is also
duplicated. Basically everything that uses RTL state + anything that uses
compiler generated tables. (there is two times RTL state and there can be
two copies of those compiler tables).

Some of it is somewhat documented on

http://wiki.freepascal.org/packages

specially the "What do we need them for? What's "special" about packages?"
part.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Duplicate RTLs

Mark Morgan Lloyd-5
Marco van de Voort wrote:

> In our previous episode, Adriaan van Os said:
>> Marco van de Voort wrote:
>>> Also RTTI like class info (not used over typinfo unit) like IS, AS, .InheritsFrom?
>>> IOW Objecttype identity operations.
>> Thanks for the info. I suggest to document this somewhere. But I am not
>> (in my own code projects) using RTTI, class info, FPC memory allocation,
>> reference counted types, exception catching or global variables.  Which
>> explains that I never got in trouble there.
>
> Note various to/from string and date types use locale info that is also
> duplicated. Basically everything that uses RTL state + anything that uses
> compiler generated tables. (there is two times RTL state and there can be
> two copies of those compiler tables).

Plus if using the Lazarus IDE/LCL, you can have forms embedded in a DLL
(or unix .so) rather than in the main program. It's possible to copy
stuff between the two to e.g. merge menu structures: it takes work but
isn't particularly painful.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal