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 -

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

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

Regards,
- Graeme -

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

Adriaan van Os wrote on Wed, 01 Jul 2015:

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

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

Adriaan van Os wrote on Wed, 01 Jul 2015:

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

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

In our previous episode, Sven Barth said:

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

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

"Marco van de Voort" wrote

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

In our previous episode, Adriaan van Os said:

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.

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.