[BAL] : [Licence] : query about LGPL and the level of publication of proprietorship features

Dear all.

I have a very specific query concerning LGPL. Let’s focus on SDL as a
genuine example: I need to port SDL down to our
proprietary graphic layer. As a consequence, I downloaded SDL sources from
the official web site and modifyed the files
SDL contain, to invoke proprietary graphic APIs offered by our
system/middleware (the same way it has been achieved for
other devices like PS2, IPOD, Nintendo DS, etc, actually, so far).

Then here is my set of significant questions about changes brought within
SDL to address or own graphic APIs ? Of course
I acknowledge that every change operated into SDL source code shall be
promulgated to recipients (similarly to other targets
like PS2, IPOD, Nintendo DS… ) but HOW FAR ?

I mean: do we have to publish our changes as a mere commented plain text
within SDL ? Knowing that’s the case for most
targets/devices SDL has been ported onto (eg: PS2, IPOD, Nintendo DS…) Is
it enough ?

In case we have to publish our changes as uncommented plain text within SDL,
do we have to provide our proprietorship (for
some, confidential) APIs in the form of header files <.h> to other
recipients… ? Are we supposed to furnish compilation tool
set, Makefiles, etc to recipients ? To allow recipients to compile our SDL
porting ? Are we supposed to furnish the libraries
our system is made of ?

By the way, w.r.t the official url
http://webkit.org/coding/lgpl-license.html how the following definitions
match our use case:
“work based on the library”: would mean our porting
SDL_downto_our_graphic_stack. Am I correct ?
whereas “work that uses the library” would account for our
system/middleware. Am I still correct ?
Reminder : “If you link a program with the library, you must provide
complete object files to the recipients so that they can
relink them with the library, after making changes to the library and
recompiling it. And you must show them these terms so
they know their rights”. Refering to this official statement from
http://webkit.org/coding/lgpl-license.html it seems that we
have to deliver our complete system; plus generation/link mecanisms to help
recipients link. Do I well understand ?

That clause seems to be very permissive (no matter what corporate
confidentiality policy might be based on). Unless such a
purpose only applies in case of static link. In other words, in case of
dynamic link, involving DLL for WIN32 or .SO for I386) we
don’t have to publish our whole system-representative set of object files.
Could you confirm my assumption ?

Thanks in advance for your further precious advice.
Kind Regards.

Jean-Pierre GOULE

Maybe others have more to tell you, but the gist is that you have to
allow the end-user the ability to modify the library that an end
product uses. If the library is SDL, that can mean distributing the
full source code of your modified version and linking your (assuming a
game) game dynamically to that modified SDL. This way, the users can
change your modified SDL and make the game use their version (by
switching the DLL). This does not force you to release any code of
your system/middleware. Layers built on top of SDL will not be
affected, just like the end product, as long as you keep LGPL code out
of them. You can assume that anyone interested in switching SDL will
have your system/middleware already. Instead of distributing (i.e.
making available) the source code for the modified SDL, I think you
can just distribute the SDL object files.

Can others verify?

Jonny D

This last part is not correct.On Mon, Apr 6, 2009 at 11:54 AM, Jonathan Dearborn wrote:

Instead of distributing (i.e.
making available) the source code for the modified SDL, I think you
can just distribute the SDL object files.


http://codebad.com/

IANAL

I mean: do we have to publish our changes as a mere commented plain text
within SDL ? Knowing that’s the case for most
targets/devices SDL has been ported onto (eg: PS2, IPOD, Nintendo DS…) Is
it enough ?

Yes. Do this.

In case we have to publish our changes as uncommented plain text within SDL,

Please do not uncomment your source code!

do we have to provide our proprietorship (for
some, confidential) APIs in the form of header files <.h> to other
recipients… ?

I do not understand your use of the term “proprietorship” (or, I do,
and I do not understand why you are invoking this use :wink:

Here is a relevant excerpt from the tail end of Section 6 of the LGPL version 2:

“For an executable, the required form of the ‘work that uses the
Library’ must include any data and utility programs needed for
reproducing the executable from it. However, as a special exception,
the source code distributed need not include anything that is normally
distributed (in either source or binary form) with the major
components (compiler, kernel, and so on) of the operating system on
which the executable runs, unless that component itself accompanies
the executable.”

“It may happen that this requirement contradicts the license
restrictions of other proprietary libraries that do not normally
accompany the operating system. Such a contradiction means you cannot
use both them and the Library together in an executable that you
distribute.”

Interpretation:

If those header files you mention are required to compile your
modified SDL library, and they are not “normally distributed with the
major components of the operating system on which the executable
runs,” then you must make them available.

This protects the open source community from such a situation as this:

  1. I upgrade an LGPL library with new functionality

  2. The modified/upgraded library requires proprietary components to be compiled

  3. The public will henceforth be unable to compile or modify the
    modified/upgraded library

In short-hand: it is required that the public actually be able to use
your copy of SDL just as they are able to use our own copy of SDL. You
mustn’t deny us “any data and utility programs needed for reproducing
the executable from it” unless it can be reasonably assumed that we
should be responsible for furnishing those parts (as per the language
in Section 6.)

Since what is contained in header files is usually trivial, usually
containing simple macros and function prototypes, you should seek to
either:

A) Reimplement the header files independently of any licensing conflicts.

B) Seek a new license for the use and distribution of those header
files from their copyright holders.

In many cases it may turn out that the header files you intended to
use provide much more content than what you actually need for your
planned SDL upgrades. This fact may make it easier to go through A or
B above.

Are we supposed to furnish compilation tool
set, Makefiles, etc to recipients ? To allow recipients to compile our SDL
porting ? Are we supposed to furnish the libraries
our system is made of ?

Everything I said about your system’s header files applies to if you
require a special compiler. If your source code is standard and will
compile on standards-compliant compilers, or any other available
compiler, then you are not required to make a compiler available.

Include your Makefiles etc. as good measure.

(Note that when working with SDL you probably should not directly
modify your “Makefile” files, rather you should modify other
components of the build toolchain, such as “Makefile.in”.)

“work based on the library”:??? would mean our porting
SDL_downto_our_graphic_stack. Am I correct ?

Your upgrade/modification to SDL is the work based on SDL, yes.

Applications you distribute using SDL (either your modification of
it or any other LGPL-licensed copy of it) are the “work that uses the
library.”

whereas “work that uses the library”? would account for our
system/middleware. Am I still correct ?

If your system/middleware links to SDL, yes.

What is more intuitive, however, is that it is your game or
application that is being linked against SDL.

Reminder :? “If you link a program with the library, you must provide
complete object files to the recipients so that they can
relink them with the library, after making changes to the library and
recompiling it. And you must show them these terms so
they know their rights”.??? Refering to this official statement from
http://webkit.org/coding/lgpl-license.html it seems that we
have to deliver our complete system; plus generation/link mecanisms to help
recipients link. Do I well understand ?

Please see the end of Section 6, which I also excerpted earlier in this email.

Note that this text applies to “work that uses the Library,” not your
modified/upgraded SDL library. The entire source code of your
modified/upgraded SDL library is required to be “made available” as
per the language of the LGPL.

If your code is standard and does not require a special compiler, you
are not required to furnish these “data and utility programs needed
for reproducing the executable.”

That clause seems to be very permissive (no matter what corporate
confidentiality policy might be based on). Unless such a
purpose only applies in case of static link. In other words, in case of
dynamic link, involving DLL for WIN32 or .SO for I386) we
don’t have to publish our whole system-representative set of object files.
Could you confirm my assumption ?

Note once again this this text applies to “work that uses the Library.”

Is there a reason you do not prefer to make your object files available?

Thanks in advance for your further precious advice.

Thanks for asking! Now may I ask you a question?

What platform are you working with!? :slight_smile:

What kind of application might you be working on!? :DOn Mon, Apr 6, 2009 at 5:55 AM, Jean-Pierre GOULE wrote:


http://codebad.com/

Ah, is it the object files of your application then? Then one can
relink the app with a different version of the LGPL library. I just
do it the dynamic way.

Jonny DOn Mon, Apr 6, 2009 at 2:05 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:

On Mon, Apr 6, 2009 at 11:54 AM, Jonathan Dearborn <@Jonathan_Dearborn> wrote:

Instead of distributing (i.e.
making available) the source code for the modified SDL, I think you
can just distribute the SDL object files.

This last part is not correct.


http://codebad.com/


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Ah, is it the object files of your application then? ?Then one can
relink the app with a different version of the LGPL library. ?I just
do it the dynamic way.

Yep, it’s the non-SDL parts that one might provide object files if he
so wanted, along with the source code to the SDL that you used (in
such a way that a user can rebuild it).

The particularity of this case is that this person is also adding a
new driver to SDL, which interfaces with Mystery Platform XYZ. So
he’ll definitely have to provide the source to the modified SDL he’s
using (I think that to comply with the LGPL, you have to provide the
source on your web site or on the disc anyway, even if it’s
unmodified, so that’s the same), but in addition, it’ll have to be
rebuildable by users (note that this isn’t “by anyone at large on the
Internet”, but by the people you distribute this code to, if I
remember correctly).

Assuming that Mystery Platform XYZ has some low-level driver code that
you’re supposed to use (much like DirectX, libX11 or DirectFB, say),
he would have to distribute the header files to that code (so that the
SDL driver itself can be recompiled, rather than just being a pile of
source code that’s pretty to look at), and provide a re-linkable
version of that code (either a static library, object files or a
shared library). If those headers/library are part of his “platform”,
he might not have to do anything.

I don’t think that he’s under any obligation of making the headers to
that low-level library non-obfuscated, but his modifications/additions
to SDL itself should not be obfuscated.

The key is that one should normally be able to take the product and
fix bugs in SDL, or modify SDL itself, recompile it, and use the
product with the fixed/updated SDL. Having the source code to an SDL
driver that uses secret header files that you do not have would not
allow that, so it’s not in compliance.

Note that there’s also the “Tivo trick” (does SDL use the LGPLv3?),
where before the GPLv3 (and the LGPLv3, which is derived from it), one
could comply with letting you rebuild the end application, but not
actually let you run it (due to a digital signature verification,
say).

Maybe he’d rather use ClanLib, which has a BSD-style license and will
let him do whatever he wants?

The usual IANAL disclaimer applies, of course.On Tue, Apr 7, 2009 at 8:25 AM, Jonathan Dearborn wrote:


http://pphaneuf.livejournal.com/

Assuming that Mystery Platform XYZ has some low-level driver code that
you’re supposed to use (much like DirectX, libX11 or DirectFB, say),
he would have to distribute the header files to that code (so that the
SDL driver itself can be recompiled, rather than just being a pile of
source code that’s pretty to look at),

IANAL and I’m not staring at the LGPL, but I don’t think that’s correct.
If the code is meant to be built against Mystery Platform XYZ, I think it’s
safe to assume that someone building against it will have the XYZ headers
already.

In other words, I don’t think SDL ships with Mac OS X, X11 and DirectX
header files.

and provide a re-linkable
version of that code (either a static library, object files or a
shared library). If those headers/library are part of his “platform”,
he might not have to do anything.

Yeah, I think that’s the case. The SDL code changes he must ship
under the terms of the LGPL would include: '#include “MPxyz.h”'
and plenty of references to the platform’s API (“MPxyz_dothis()”,
“MPxyz_dothat()”), but shipping MYxyz.h itself shouldn’t be necessary.On Tue, Apr 07, 2009 at 09:45:15AM -0400, Pierre Phaneuf wrote:


-bill!
Sent from my computer

IANAL and I’m not staring at the LGPL, but I don’t think that’s correct.
If the code is meant to be built against Mystery Platform XYZ, I think it’s
safe to assume that someone building against it will have the XYZ headers
already.

In other words, I don’t think SDL ships with Mac OS X, X11 and DirectX
header files.

Yes, but the interesting question is, what if the headers for Mystery
Platform XYZ aren’t publicly available (which I assume was what the
original poster actually was asking…)

// MartinOn Tue, 7 Apr 2009, Bill Kendrick wrote:

For LGPL things aren’t all that complicated, LGPL code is not
contagious, it doesn’t
infect other code with it’s license.
Suppose you have the Mystery Platform XYZ, and you want to use SDL
(and get your changes upstream) this is what the license requires you
to do:

  1. Write documented code and claim authorship.
    Common sense, ugly code will not be integrated. Also make it
    obvious who authored
    the code.

  2. Assign the LGPL license to the code.
    Only the code that is needed for running SDL needs to be submitted.
    If other
    libraries are needed they do not need to be supplied, see below.
    Given the
    correct development environment the code should compile.

  3. Supply makefiles and a readme stating what you need to compile the
    code
    Even if the development platform is only available under NDA,
    terribly expensive
    or vaporware, this does not stop you from publishing LGPL code. As
    long as
    the documentation that comes with the software makes it clear what
    exactly you
    need to compile or run the software - however hard it may be to
    obtain.

  4. If you link statically - supply the information needed to re-link
    your application
    to another version of SDL, minimally: o-code and a linker script
    suffice.

LGPL is a very good license for this type of middleware, since it
does not require
a certain type of license from its users, but still - care should be
taken when
LGPL code is linked to, or compiled with pieces of software that uses
a 'contagious’
type of license; i.e.: A license that requires all parts of a program
to also adhere to
its license statements.

Best regards,

DirkOn Apr 7, 2009, at 7:32 PM, Bill Kendrick wrote:

On Tue, Apr 07, 2009 at 09:45:15AM -0400, Pierre Phaneuf wrote:

Assuming that Mystery Platform XYZ has some low-level driver code
that
you’re supposed to use (much like DirectX, libX11 or DirectFB, say),
he would have to distribute the header files to that code (so that
the
SDL driver itself can be recompiled, rather than just being a pile of
source code that’s pretty to look at),

IANAL and I’m not staring at the LGPL, but I don’t think that’s
correct.
If the code is meant to be built against Mystery Platform XYZ, I
think it’s
safe to assume that someone building against it will have the XYZ
headers
already.

In other words, I don’t think SDL ships with Mac OS X, X11 and DirectX
header files.

and provide a re-linkable
version of that code (either a static library, object files or a
shared library). If those headers/library are part of his “platform”,
he might not have to do anything.

Yeah, I think that’s the case. The SDL code changes he must ship
under the terms of the LGPL would include: '#include “MPxyz.h”'
and plenty of references to the platform’s API (“MPxyz_dothis()”,
“MPxyz_dothat()”), but shipping MYxyz.h itself shouldn’t be necessary.


-bill!
Sent from my computer


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Wow, hey, let’s all write incomplete LGPL FAQs that don’t actually
answer the OP’s questions, even when it is clear that others have
already done that.

Read the whole thread before you add to it!–
http://codebad.com/