Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2010-07

Licensing issue: Subclassing

5 messages · 4 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Vladimir Zhirov

Hi,

There was a question raised in Russian FPC forum about whether LCL license (modified LGPL) should be applied to a subclass of LCL class: TMyButton = class(TButton)
This turned out to be a deeper problem, since it would also affect subclassing from RTL/FCL classes:
TMyObject = class(TObject)

Reading gnu.org does not clarify the situation because:

A) GPL FAQ states that "Subclassing is creating a derivative work." (http://www.gnu.org/licenses/gpl-faq.html#OOPLang)

But:

B) LGPL states that "A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License." (http://www.gnu.org/licenses/old-licenses/lgpl-2.0.html#SEC3, "5.")

So this seems unclear whether application that subclasses from RTL/FCL/LCL is a derived work of RTL/FCL/LCL and must itself be licensed under Modified LGPL, making source code open.

BTW, LGPL v3 explicitly allows subclassing:
"Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library."
(http://www.gnu.org/licenses/old-licenses/lgpl-2.0.html#SEC3), but Modified LGPL is based on LGPL v2.

I understand that the whole point of Modified LGPL is to allow creating closed-source products using FPC/Lazarus. But in the above aspect it seems not clear enough.

Would someone of the core team please comment on this?

Maybe subclassing deserves to be explained in some licensing FAQ or even explicitly allowed in Modified LGPL itself?

Best regards, Vladimir Zhirov
Florian Klaempfl
to Vladimir Zhirov
Vladimir Zhirov wrote 14 lines
So this seems unclear whether application that subclasses from RTL/FCL/LCL is a derived work of RTL/FCL/LCL and must itself be licensed under Modified LGPL, making source code open. BTW, LGPL v3 explicitly allows subclassing: "Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library." (http://www.gnu.org/licenses/old-licenses/lgpl-2.0.html#SEC3), but Modified LGPL is based on LGPL v2. I understand that the whole point of Modified LGPL is to allow creating closed-source products using FPC/Lazarus. But in the above aspect it seems not clear enough.

Well, the point of the Modified LGPL above is not complete: the goal is also that one has to release changes like bug fixes to the RTL/FCL sources. So the thumb rule is pretty simple: as long as you use unmodified rtl/fcl sources/code, you don't have to release any source code. If you use modified rtl/fcl sources, you've to release the patches to the rtl/fcl sources.

Would someone of the core team please comment on this?

Subclassing a class which is under the modified LGPL used by FPC does not require to release any sources of the subclasses under the modified LGPL.

Mattias Gaertner
to Vladimir Zhirov: There was a question raised in Russian FPC forum about whether LCL license (modified…
Show quoted text 38 lines
Hi, There was a question raised in Russian FPC forum about whether LCL license (modified LGPL) should be applied to a subclass of LCL class: TMyButton = class(TButton) This turned out to be a deeper problem, since it would also affect subclassing from RTL/FCL classes: TMyObject = class(TObject) Reading gnu.org does not clarify the situation because: A) GPL FAQ states that "Subclassing is creating a derivative work." (http://www.gnu.org/licenses/gpl-faq.html#OOPLang) But: B) LGPL states that "A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License." (http://www.gnu.org/licenses/old-licenses/lgpl-2.0.html#SEC3, "5.") So this seems unclear whether application that subclasses from RTL/FCL/LCL is a derived work of RTL/FCL/LCL and must itself be licensed under Modified LGPL, making source code open. BTW, LGPL v3 explicitly allows subclassing: "Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library." (http://www.gnu.org/licenses/old-licenses/lgpl-2.0.html#SEC3), but Modified LGPL is based on LGPL v2. I understand that the whole point of Modified LGPL is to allow creating closed-source products using FPC/Lazarus. But in the above aspect it seems not clear enough. Would someone of the core team please comment on this?

For me the above sounds pretty clear. LCL is modified LGPL, so subclassing is B. You can subclass with your own license.

Maybe subclassing deserves to be explained in some licensing FAQ or even explicitly allowed in Modified LGPL itself?

Mattias

Jonas Maebe
to Vladimir Zhirov: There was a question raised in Russian FPC forum about whether LCL license (modified…
Vladimir Zhirov wrote
Reading gnu.org does not clarify the situation because: A) GPL FAQ states that "Subclassing is creating a derivative work." (http://www.gnu.org/licenses/gpl-faq.html#OOPLang)

That's normal *in the context of the GPL*: to subclass you have to link to the code of the original class, and hence you are bound by the terms of the GPL (because you link against GPL code).

Show quoted text 10 lines
B) LGPL states that "A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License." (http://www.gnu.org/licenses/old-licenses/lgpl-2.0.html#SEC3, "5.") So this seems unclear whether application that subclasses from RTL/FCL/LCL is a derived work of RTL/FCL/LCL and must itself be licensed under Modified LGPL, making source code open.

It's just like linking against a GPL library always causes your program to become a derived work, while linking against a LGPL library (under the LGPL terms) does /not/ cause your program to become a derived work. What is considered to be a derived work differs between the LGPL and the GPL.

BTW, LGPL v3 explicitly allows subclassing: "Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library."

That section was added for the purpose of C++ classes (in which case actual code from the library headers is embedded in your program), see e.g. http://www.chineselinuxuniversity.net/news/44652.shtml :

***
LGPLv3 is perfectly suited for C++ template libraries. This is mostly thanks to section 3, which addresses exactly this sort of case. When application developers use such header files whose materials are incorporated directly into the object code, they only need to provide notice that they're using your library, and include a copy of LGPLv3 with their application. Thus, there's no longer the technology mismatch that the libstdc++ licensing FAQ discusses about LGPLv2.1. ***

At most, that exception might be necessary if you use the fgl unit. In any other case, there is definitely no problem.

Would someone of the core team please comment on this?

As Florian said, there is no problem.

Jonas

Jonas Maebe
to Jonas Maebe
Jonas Maebe wrote 6 lines
> BTW, LGPL v3 explicitly allows subclassing: > "Defining a subclass of a class defined by the Library is deemed a > mode > of using an interface provided by the Library." That section was added for the purpose of C++ classes

... C++ *template* classes ...

Jonas