LGPL legal questions about SMPEG

Hi,

(I will be posting this in the SDL and the SMPEG newsgroups, hoping to find
the correct listeners.)

I am pretty new to open source development and it’s surrounding questions,
so here are a few questions I have right now.

I need to create an MPEG video player for a proprietary product for the
Windows platform. My choices right now are to either use DirectShow,
Quicktime or “something else”. While having done a bit of research I found
the SMPEG lib a few days ago, which seems to be pretty well suited for my
purpose. The actual advantage would be that there is no need for installing
DX or QT.

What I would like to do is, strip it from all SDL specific stuff and make it
run under a different (closed source) multimedia engine. This shouldn’t be
very complicated as far as I have overlooked it…

But before getting into it, I wonder if this is ‘legal’ to do, since I will
not be able to release the source codes of the modified version. But
anyways, it will not have any benefit compared to the current version, it
will just run under a different engine, using different Surface structures
mainly. So actually there is not even a single worthy thing I could donate
back to the public.

Giving credits including a link and a copyright notice to the SMPEG/SDL
projects is no problem of course. (Like currently also is done with libjpeg
and some other things.)

As far as I understood the LGPL I would be allowed and encouraged to do all
this unless there were not the modifications, which of course are necessary
in this case.

I would like to hear your advice on this…

So is my plan ‘legal’?

Is this maybe an unwelcome attempt of the use of SMPEG?

Please let me know… and in case something is unwelcome, please still be
nice. I am kindly asking :wink:

Best regards,
Mario

I need to create an MPEG video player for a proprietary product for the
Windows platform. My choices right now are to either use DirectShow,
Quicktime or “something else”. While having done a bit of research I found
the SMPEG lib a few days ago, which seems to be pretty well suited for my
purpose. The actual advantage would be that there is no need for installing
DX or QT.

What I would like to do is, strip it from all SDL specific stuff and make it
run under a different (closed source) multimedia engine. This shouldn’t be
very complicated as far as I have overlooked it…

Any changes you make to SMPEG that are released MUST also release the
source of any changes.

But before getting into it, I wonder if this is ‘legal’ to do, since I will
not be able to release the source codes of the modified version. But

No, it is definitely NOT legal, unless you or your employers negotiate a
different license from the copyright holders, as I explain below.

anyways, it will not have any benefit compared to the current version, it
will just run under a different engine, using different Surface structures
mainly. So actually there is not even a single worthy thing I could donate
back to the public.

Regardless, the LGPL demands that any changes you make to the library
must be made public provided you release a modified version to the
outside world. You can refuse to accept the license, of course, but
that means that you have absolutely no rights whatsoever to the library,
as the license is the only thing that grants you that privilege.

If your changes are that minor, then what is stopping you from releasing
your changes to the public? No one who doesn’t have the alternative
proprietary graphics library you mention will care, and those who do
have it will thank you for your efforts. Don’t think that there isn’t a
single worthy thing there. If you’re concerned that your competitors
may profit off your efforts, think that you’ll be there far ahead of
them because you made the effort to do the work first. And nothing
prevents you from doing this now, and only releasing the modified
sources to the public when your product actually gets released. Your
only other alternative would be to negotiate a discretionary license
(see below).

Giving credits including a link and a copyright notice to the SMPEG/SDL
projects is no problem of course. (Like currently also is done with libjpeg
and some other things.)

The JPEG library is of course licensed with different terms, the MIT/X
Consortium license to be specific, not the LGPL, which places more
restrictions on what proprietary developers can do with it. In fact, if
you wanted to break the law, advertising that you did so would be the
quickest way to get sued. :slight_smile:

As far as I understood the LGPL I would be allowed and encouraged to do all
this unless there were not the modifications, which of course are necessary
in this case.

I would like to hear your advice on this…

So is my plan ‘legal’?

No, it is not legal, not as is. Whoever owns the copyright on SMPEG
these days (it would have been Loki, but now that Loki’s gone…) could
sue you for violating the license, and hence copyright infringement.

Is this maybe an unwelcome attempt of the use of SMPEG?

Well, whoever holds the copyright on the SMPEG code these days could
grant you different licensing terms from the LGPL. You’ll need to
contact them (whoever they are) and negotiate different licensing terms
from them in writing. Usually this means lawyer discussions, and they
could demand money from you as well. As holder of the copyright, they
cannot be in violation of any license; they have unlimited power to
license the code, so if they want to give you a discretionary license
that will allow you to make the changes you need to do.

Fortunately, I believe the FSF doesn’t hold the copyright; they would
never grant such a discretionary license.On Thu, Feb 07, 2002 at 03:06:00AM +0100, Mario Knezovic wrote:


Rafael R. Sevilla <@Rafael_Dido_Sevilla> +63(2) 8177746 ext. 8311
Programmer, Inter.Net Philippines +63(917) 4458925
http://dido.ph.inter.net/ OpenPGP Key ID: 0x5CDA17D8
Heute die Welt und Morgen das Sonnensystem!

No, it is not legal, not as is. Whoever owns the copyright on SMPEG
these days (it would have been Loki, but now that Loki’s gone…) could
sue you for violating the license, and hence copyright infringement.

Loki probably owns the majority of the code’s copyright. Loki’s current
status does NOT make SMPEG public domain, btw…those parts will become
copyright whomever the assets (for lack of a better term) are given to in
the upcoming proceedings.

It’s important to note that Loki accepted code that was contributed from
the field without having the copyright signed over. The FSF requires
documentation saying they own contributions before they’ll accept them, so
that the FSF has the full right and ability to take violators to court.
Loki didn’t do this. In this case, since it means there’s lots of people
with copyrights on lots of bits of code dispersed throughout the project
(and throughout each file), and it becomes very difficult very quickly to
decide who really owns what. And, more importantly, it becomes very
difficult to get EVERY contributor’s permission to relicense the code or
grant an exception to the LGPL.

SO, that leaves you with a few options:

  1. Find another library. SMPEG is originally based on “splay”, which (if I
    recall correctly) was either public domain or based on the BSD license. I
    could be wrong. This is taking several steps backwards, but it DOES get
    rid of the dependency on SDL right away. Another library (such as
    Quicktime, etc) handles this problem, too. Dunno how that’s licensed, but
    I imagine it’s more closed-source friendly.

  2. Write your own. Removing the dependency on SDL from SMPEG is probably
    harder than you think, anyhow.

  3. Fork out. You don’t have to make general, reasonable, and abstract
    changes to SMPEG that are universally useful. For example, if you need
    extra functionality, you can add a call inside SMPEG like:

    do_my_really_cool_proprietary_thing();

…and then have that function in something close-sourced. You still need
to make your SMPEG patches available, but even if it’s a bunch of hooks to
jump immediately out of SMPEG, that still fulfills the requirement.

  1. Deal with it. There’s no nice way to say it, but you ARE getting free
    code, and if you are going to profit from it, the least you can do is
    share the changes to SMPEG with the rest of us. You aren’t required to
    give out any source UNLESS the change is to SMPEG directly, so you don’t
    have to give away your lunch. If your lunch IS smpeg, then you need to
    rethink your business model.

Ok, I’ll get off my soapbox now. :slight_smile:

–ryan.

Hi Rafael, hi Ryan,

thank you for your answers.

Right now my application uses DirectShow and/or QuickTime to play MPEGs. The
advantage I would have when using SMPEG would be that the users do not have
to install DX/QT. That’s all, no magic.

But before getting into it, I wonder if this is ‘legal’ to do, since I
will

not be able to release the source codes of the modified version. But

No, it is definitely NOT legal, unless you or your employers negotiate a
different license from the copyright holders, as I explain below.

As explained, I do not wish to make any exceptions and I could pretty well
understand if the community would not like that.

If your changes are that minor, then what is stopping you from releasing
your changes to the public? No one who doesn’t have the alternative
proprietary graphics library you mention will care, and those who do
have it will thank you for your efforts. Don’t think that there isn’t a
single worthy thing there.

Releasing the sources of the modified version will be no problem at all, but
to me this sounds like nonsense as nobody will be able to use them. But if
this is ‘technically’ the correct way to use SMPEG in my project, why not?

If you’re concerned that your competitors
may profit off your efforts, think that you’ll be there far ahead of
them because you made the effort to do the work first. And nothing
prevents you from doing this now, and only releasing the modified
sources to the public when your product actually gets released.

I do not care at all. As mentioned, the ‘huge’ difference is to use
different Surface structures and such stuff. Nobody will benefit from this
:wink:

SO, that leaves you with a few options:

  1. Find another library. SMPEG is originally based on “splay”, which (if I
    recall correctly) was either public domain or based on the BSD license. I
    could be wrong. This is taking several steps backwards, but it DOES get
    rid of the dependency on SDL right away. Another library (such as
    Quicktime, etc) handles this problem, too. Dunno how that’s licensed, but
    I imagine it’s more closed-source friendly.

Right now I am using DirectShow and QuickTime. I only have to fill out a
form and places their logos on the CD-ROMs that are published. No biggie
there, but I would like to avoid the installation process…

  1. Fork out. You don’t have to make general, reasonable, and abstract
    changes to SMPEG that are universally useful. For example, if you need
    extra functionality, you can add a call inside SMPEG like:

    do_my_really_cool_proprietary_thing();

…and then have that function in something close-sourced. You still need
to make your SMPEG patches available, but even if it’s a bunch of hooks to
jump immediately out of SMPEG, that still fulfills the requirement.

  1. Deal with it. There’s no nice way to say it, but you ARE getting free
    code, and if you are going to profit from it, the least you can do is
    share the changes to SMPEG with the rest of us. You aren’t required to
    give out any source UNLESS the change is to SMPEG directly, so you don’t
    have to give away your lunch. If your lunch IS smpeg, then you need to
    rethink your business model.

SMPEG is definitely not my business. MPEG playback will be required in
approximately 0.5% of all ‘screens’ in this application. Anybody who is
curious to see screenshots, please feel free to visit a collection of
screenshots (of the German version) I have uploaded:
http://www.bonespark.com/lxd/lxd.html

So let me summarize what I could legally do. Please comment if this is
correct or not:

  • I ‘fork out’ SMPEG and make a changed version of SMPEG that fits my needs,
    which means especially, I remove all SDL specific stuff and replace it by
    the proprietary function calls.

  • I release the source codes including all changes I made to SMPEG on my web
    site. Technically I am complying with the LGPL rules, though nobody will
    benefit from this as nobody has the source codes for the proprietary engine
    that I am using.

The question here is: Is this still legal, though the code that I will
release, will not even be compilable? (…due to the missing libraries.)

I would like to statically link it instead of using a DLL. I am not sure if
this is allowed, too.

Your comments are highly appreciated. Thank you.

Mario

“Mario Knezovic” wrote in message
news:a3udfs$1epp$1 at hoth.stenstad.net

The question here is: Is this still legal, though the code that I
will
release, will not even be compilable? (…due to the missing
libraries.)

I would like to statically link it instead of using a DLL. I am not
sure if
this is allowed, too.

One rule of thumb is that people should be allowed to make additional
changes to the SMPEG portion of your program, relink it, and run the
resulting program.–
Rainer Deyke | root at rainerdeyke.com | http://rainerdeyke.com

I do not care at all. As mentioned, the ‘huge’ difference is to use
different Surface structures and such stuff. Nobody will benefit from this
:wink:

Well, I don’t know about that. If you used a structure very close to …

typedef struct image_s
{
Uint32 width;
Uint32 height;
Uint32 type;
Uint8 *pixels;
} image_t;

… for each frame, I would be very much able to use it, on account of the
above is exactly the image format I use in my code. (SDL_Surface is nice
and all, but too complex for its own good with OpenGL. Since I have to
load filetypes SDL_image doesn’t support, and don’t need half the types it
does, plus I need to save in a few of them, I just did it myself.

That’s a little less simple with something to play MPEG video. But as
long as you put a diff of smpeg where people can get it and keep it
dynamic linked to your code, that’s all you have to do. Static linking
would make your whole program subject to the LGPL, which I imagine is not
at all desirable.

The LGPL is kinda picky, and the GPL is of course more so. The reason for
this is, well, say you wrote libl33t and put it under the l33t license,
which for our purposes looks a lot like a BSDish license. Someone else
sees libl33t and thinks it’s not l33t enough, so they greatly enhance it
making libl33t3r, and they don’t give out their source. In addition,
maybe thy decide to sell libl33t3r. Now perhaps you don’t mind that
they’re seilling it, but given that they didn’t have anything until they
got your code, you feel that they should somehow compensate you for your
code. And because you’re a disgruntled old hippie named Richard Stallman,
you feel that any program you get should include its source code, as a
matter of your own idealistic principles. So you would really rather the
company who made libl33t3r compensate you by sharing their changes to your
code with you and the rest of the world.

The GPL and LGPL are pretty well described as double-edged swords though.
It seems for every piece of {L,}GPL software which is extended and then
given back to the community afterward, there is an argument about some
technical violation of one of these licenses. And these aren’t the clear
cut someone’s-being-bad violations either. They are usually caused by
someone who does not fully understand some clause or did not consider that
it conflicts somehow with the license of some other code they’re using.
Most of us aren’t lawyers, after all.

SO, that leaves you with a few options:

  1. Find another library. SMPEG is originally based on “splay”, which (if I
    recall correctly) was either public domain or based on the BSD license. I
    could be wrong. This is taking several steps backwards, but it DOES get
    rid of the dependency on SDL right away. Another library (such as
    Quicktime, etc) handles this problem, too. Dunno how that’s licensed, but
    I imagine it’s more closed-source friendly.

Right now I am using DirectShow and QuickTime. I only have to fill out a
form and places their logos on the CD-ROMs that are published. No biggie
there, but I would like to avoid the installation process…

Obviously with SMPEG you can just toss a DLL in the directory with the
binary. This is far simpler than depending on either of those other large
tools.

As for your diff, it doesn’t matter if others can actually use it as it
stands, as long as it’s there. Nobody ever promised that any of the code
out there would actually be useful for any particular purpose, just that
it’s there.On Thu, Feb 07, 2002 at 06:26:21PM +0100, Mario Knezovic wrote:


Joseph Carter Not many fishes

If I start writing essays about Free Software for slashdot,
please shoot me.

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020207/b71e1d75/attachment.pgp

Releasing the sources of the modified version will be no problem at all, but
to me this sounds like nonsense as nobody will be able to use them. But if
this is ‘technically’ the correct way to use SMPEG in my project, why not?

Nonsense or not, it’s what compliance with the LGPL requires.

I do not care at all. As mentioned, the ‘huge’ difference is to use
different Surface structures and such stuff. Nobody will benefit from this
:wink:

I disagree. The smart way to do what you think needs to be done would
be to generalize the surface structures so that it would work with
both SDL and with your mysterious proprietary library. That would be a
great benefit to the community. It removes SMPEG’s absolute dependency
on SDL, and allows people to plug and play backend display engines at
will, if, for instance, they wished to make an MPEG player that would go
straight to the Linux SVGA framebuffer, to SVGAlib, or straight to
DirectX surfaces, or whatever else.

So let me summarize what I could legally do. Please comment if this is
correct or not:

  • I ‘fork out’ SMPEG and make a changed version of SMPEG that fits my needs,
    which means especially, I remove all SDL specific stuff and replace it by
    the proprietary function calls.

This is still legal, yes, but I don’t think it’s the most intelligent
way to do so.

  • I release the source codes including all changes I made to SMPEG on my web
    site. Technically I am complying with the LGPL rules, though nobody will
    benefit from this as nobody has the source codes for the proprietary engine
    that I am using.

Yes, this is still legal, with a few caveats. And no, they don’t need
the source for the proprietary engine that you’re using to recompile it.
They’ll probably just need the devkit and the libraries. Unless you’ve
developed the entire proprietary library yourself, I think this is also
the situation as far as you’re concerned. You don’t have the sources
either. :slight_smile:

You can only distribute the source code on your website if that’s
also the primary means of distribution for your program. If you
distribute your program on CD-ROM, the sources will also have to be
included on the CD-ROM.

The question here is: Is this still legal, though the code that I will
release, will not even be compilable? (…due to the missing libraries.)

Yes, this is still legal. For a long time we’ve had many GPLed
applications that required Motif to be built, so the code would not be
compilable unless you had that proprietary library. For a long time,
these apps had to be distributed in statically linked form until OSF
decided to release it to the open (by which time Motif was made largely
irrelevant by the creation of GTK+ and other free software GUI toolkits
that were much better). The same situation applies here.

I would like to statically link it instead of using a DLL. I am not sure if
this is allowed, too.

Static linking to proprietary code is allowed under the LGPL only under
special circumstances. If you have to statically link your programs,
you need to provide all object code for your program in a form that the
object linker for the system you’re targeting can rebuild your program
with a modified version of the sources.On Thu, Feb 07, 2002 at 06:26:21PM +0100, Mario Knezovic wrote:


Rafael R. Sevilla <@Rafael_Dido_Sevilla> +63(2) 8177746 ext. 8311
Programmer, Inter.Net Philippines +63(917) 4458925
http://dido.ph.inter.net/ OpenPGP Key ID: 0x5CDA17D8
Heute die Welt und Morgen das Sonnensystem!

“Rainer Deyke” wrote:

One rule of thumb is that people should be allowed to make additional
changes to the SMPEG portion of your program, relink it, and run the
resulting program.

Indeed and people often miss this central concept. For example, it does
not imply that the LGPLed lib has to be linked dynamically

Hi all,

thank you all for your answers.

Especially Joseph’s made me laugh and Rafael’s had the best idea…

I do not care at all. As mentioned, the ‘huge’ difference is to use
different Surface structures and such stuff. Nobody will benefit from
this

:wink:

I disagree. The smart way to do what you think needs to be done would
be to generalize the surface structures so that it would work with
both SDL and with your mysterious proprietary library. That would be a
great benefit to the community. It removes SMPEG’s absolute dependency
on SDL, and allows people to plug and play backend display engines at
will, if, for instance, they wished to make an MPEG player that would go
straight to the Linux SVGA framebuffer, to SVGAlib, or straight to
DirectX surfaces, or whatever else.

This is a great idea. If I decide to use SMPEG, I will do exactly this.

But right now it seems I will not use it as the performance is too lousy
compared to DirectShow. I did not check that earlier as I was too excited
about this brave new world :wink:

So this leaves me with a 2nd thing I would have to do, which is improve
performance, especially in fullscreen mode (maybe by programming some kind
of fullscreen overlay thing like DirectShow does). I have seen Ryan asking
about SMPEG complaints, requests and enhancements. I will pass this to him
as well.

And actually I am running out of time, so I will probably just leave it as
it is right now.

At least I was able to contribute a very very little bit to SDL by helping
Darrell bring the CodeWarrior projects up-to-date.

If I decide to make the above mentioned changes, I will let you know and ask
how this formally has to be done to comply with this project…

Keep enjoying SDL/SMPEG.

Again, thank you all.

Mario Knezovic


mario.knezovic at SPAMISCRAPbonespark.com,
Please remove my opinion on spam to email me :wink:

Yet this is the simplest solution to doing it - handing out a bunch of .o
files is usually far less desirable than giving someone a lib and a diff
showing how they made it.On Fri, Feb 08, 2002 at 10:36:20AM +0100, Mattias Engdegard wrote:

One rule of thumb is that people should be allowed to make additional
changes to the SMPEG portion of your program, relink it, and run the
resulting program.

Indeed and people often miss this central concept. For example, it does
not imply that the LGPLed lib has to be linked dynamically


Joseph Carter Have chainsaw will travel

We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.
– Dave Clark

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020208/d4c2a3b1/attachment.pgp

Joseph Carter wrote:

Yet this is the simplest solution to doing it - handing out a bunch of .o
files is usually far less desirable than giving someone a lib and a diff
showing how they made it.

doesn’t have to be a bunch of .o files. Most linkers handle partial links
(-r to gnu or solaris ld). Not difficult, and a good alternative when
dynamic linking isn’t available or desirable

On the legality front, the LGPL (as opposed to the GPL) permits the use of a
library in a proprietary product so long as the LIBRARY is kept open source.

So include a .zip file of SDL source and one of SMPEG source with your
binary & SDL DLL distribution, and you should be fine (iirc)… That’s the
whole purpose of the LGPL, to allow libraries to be free, but used in
proprietary products…

“Mario Knezovic” wrote in message
news:a3snek$vjh$1 at hoth.stenstad.net

Hi,

(I will be posting this in the SDL and the SMPEG newsgroups, hoping to
find
the correct listeners.)

I am pretty new to open source development and it’s surrounding questions,
so here are a few questions I have right now.

I need to create an MPEG video player for a proprietary product for the
Windows platform. My choices right now are to either use DirectShow,
Quicktime or “something else”. While having done a bit of research I found
the SMPEG lib a few days ago, which seems to be pretty well suited for my
purpose. The actual advantage would be that there is no need for
installing
DX or QT.

What I would like to do is, strip it from all SDL specific stuff and make
it
run under a different (closed source) multimedia engine. This shouldn’t be
very complicated as far as I have overlooked it…

But before getting into it, I wonder if this is ‘legal’ to do, since I
will
not be able to release the source codes of the modified version. But
anyways, it will not have any benefit compared to the current version, it
will just run under a different engine, using different Surface structures
mainly. So actually there is not even a single worthy thing I could donate
back to the public.

Giving credits including a link and a copyright notice to the SMPEG/SDL
projects is no problem of course. (Like currently also is done with
libjpeg
and some other things.)

As far as I understood the LGPL I would be allowed and encouraged to do
all
this unless there were not the modifications, which of course are
necessary> in this case.

I would like to hear your advice on this…

So is my plan ‘legal’?

Is this maybe an unwelcome attempt of the use of SMPEG?

Please let me know… and in case something is unwelcome, please still be
nice. I am kindly asking :wink:

Best regards,
Mario

So include a .zip file of SDL source and one of SMPEG source with your
binary & SDL DLL distribution, and you should be fine (iirc)… That’s the
whole purpose of the LGPL, to allow libraries to be free, but used in
proprietary products…

Dynamically linking, and listing a URL to the source in a README and/or
where you distribute the binaries from is sufficient.

Thank god I don’t have to zip up glibc for every program I ship. :slight_smile:

–ryan.

On the legality front, the LGPL (as opposed to the GPL) permits the use of a
library in a proprietary product so long as the LIBRARY is kept open source.

So include a .zip file of SDL source and one of SMPEG source with your
binary & SDL DLL distribution, and you should be fine (iirc)… That’s the
whole purpose of the LGPL, to allow libraries to be free, but used in
proprietary products…

Correct me if I’m wrong, but I was under the impression that you didn’t
have to give the source code WITH the product, but that you had to make
it obviously available if wanted…

So you could have a release without the source code, but with a readme
that clearly states where to get the source from…

(and possibly, if you feel the need, a second release archive including
the source too…)

After all, Joe Public usually doesn’t want the source code, so it’s silly
to make him download it…

That’s my understanding of GPL/LGPL source code obligations…

Yours,
Andy GordonOn Fri, 15 Feb 2002, David Acklam wrote:


QueriX UK
36A London Road		http://www.querix.co.uk
Southampton		
Tel: +44 23 8023 2345	andy at querix.co.uk
Fax: +44 23 8039 9685

Where can I find info on how to use sdl_ttf with vc?
Are there any docs or example code?

thanks
Herbert

BTW I’ve got an email list(IGP) We need a couple of
programmers to help with a project. If anybody wants
more info, email me personaly.=====
Game Programming Groups
VS Entertainment(Houston game dev group, looking for members)
IGP(Internet game programming group, looking for members also)
Ask me for details…


Do You Yahoo!?
Got something to say? Say it better with Yahoo! Video Mail
http://mail.yahoo.com

Andy Gordon wrote:

[snip]

Correct me if I’m wrong, but I was under the impression that you didn’t
have to give the source code WITH the product, but that you had to make
it obviously available if wanted…

With GPL yes, with LGPL no. The idea behind LGPL is that you can link
a proprietary product to the LGPL library, but people do not have to get
the library from you (cuz then it would be effectively proprietary).
Which forces you to dynamically link to the library.

So you could have a release without the source code, but with a readme
that clearly states where to get the source from…

(and possibly, if you feel the need, a second release archive including
the source too…)

After all, Joe Public usually doesn’t want the source code, so it’s silly
to make him download it…

That’s my understanding of GPL/LGPL source code obligations…

Well there is a difference between the 2.

Yours,
Andy Gordon

Greetings,–
Michel Bardiaux
Peaktime Belgium S.A. Rue Margot, 37 B-1457 Nil St Vincent
Tel : +32 10 65.44.15 Fax : +32 10 65.44.10

Michel Bardiaux wrote:

Andy Gordon wrote:

[snip]

Correct me if I’m wrong, but I was under the impression that you didn’t
have to give the source code WITH the product, but that you had to make
it obviously available if wanted…

With GPL yes, with LGPL no. The idea behind LGPL is that you can link
a proprietary product to the LGPL library, but people do not have to get
the library from you (cuz then it would be effectively proprietary).
Which forces you to dynamically link to the library.

From the LGPL at http://www.gnu.org/licenses/lgpl.html

“For example, if you distribute copies of the library, whether gratis or
for a fee, you must give the recipients all the rights that we gave you.
You must make sure that they, too, receive or can get the source code.
If you link other code 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.”

“6. …
a) Accompany the work with the complete corresponding machine-readable
source code for the Library including whatever changes were used in the
work (which must be distributed under Sections 1 and 2 above); and, if
the work is an executable linked with the Library, with the complete
machine-readable “work that uses the Library”, as object code and/or
source code, so that the user can modify the Library and then relink to
produce a modified executable containing the modified Library. (It is
understood that the user who changes the contents of definitions files
in the Library will not necessarily be able to recompile the application
to use the modified definitions.)”

Which basically says that you can either dynamically link the library or
you can staticly link the library if you provide .o files for you
application so that the end user can relink with a new version of the
library. It also says you can leave the .o files and source for the
library on the web somewhere rather than including it with the
distribution.

Please, read the license. These are important documents. It makes me
very sad to meet programmers who have never read the GPL and LGPL. Its a
lot like the feeling I get when I meet Americans who have never read the
Declaration of Independence and the Constitution.

Bob Pendleton-- 

±-----------------------------------+

  • Bob Pendleton is seeking contract +
  • and consulting work. Find out more +
  • at http://www.jump.net/~bobp +
    ±-----------------------------------+

Es schrieb Michel Bardiaux:

Andy Gordon wrote:

[snip]

Correct me if I’m wrong, but I was under the impression that you didn’t
have to give the source code WITH the product, but that you had to make
it obviously available if wanted…

With GPL yes, with LGPL no. The idea behind LGPL is that you can link
a proprietary product to the LGPL library, but people do not have to get
the library from you (cuz then it would be effectively proprietary).
Which forces you to dynamically link to the library.

Almost :wink: … actually, you can ship your (proprietary) program with a
modified version (!!) of an LGPL’ed library - in that case, you must
publish the sources of the modified library. However, most libraries
are already in a state that suffices the requirements of the program,
so you can just dynalink with the standard library, and in that case,
the complete sources to the library have been published already, in
their standard place. The same applies to GPL libraries btw, you can
even ship your program with a modified version, and in that case you
must publish the modified library code, and again, for the standard
GPL code, you don’t need to ship it if there is a standard place for
it. Anyway, if you dynalink with a LGPL, you are on good legal ground
that you don’t need to publish the sources to your program, while
with the GPL, this is not usually the case - even that there are cases
where you can link GPL code to non-GPL stuff. The conditions are
based on a fuzzy thing called “mere use”, and that the GPL code is
"independent" of that other code, or “at arm’s length” as it was
expressed in the GPL FAQ. That’s certainly a good ground for lawyers
to discuss before court - with the LGPL you are on the safe side,
since it boils down to one condition - keep your propriatary code
and the opensource code in different files, and bind them only at
startup with the dynaloader. Basically, you could fetch some LGPL’ed
library, modify it by placing some extra hooks into it, so that
it would only correctly work when linked to some other code, being
possibly propriatary. That’s the danger in there that the copyright
holder of the LGPL’ed library has to accept, and it is probably
the reason why RMS argues that the strict GPL is a better protection
for library code too. In essence, the GPL cares about “use” and
protects from “abuse” by non-opensource enterprises, the LGPL does
not care, but it protects the code from becoming non-free - each
modification to the library must be published and it is therefore
ready to be merged back. The “customer” (of a proprietary program
dynalinked with it) has the chance to modify the modifed code, and
enhance it with the latest patches from the standard version, or look
at the modifications for a greater value so that it can be merged back
into the standard version. In most cases, the original “vendor” will
have done that anyway, since there is no use to wait for it to be done
by a third person. And therefore, one can expect that there are more
code contributions to LGPL’ed code than there are for GPL’ed ones,
since commercial entities are much easier to pick up this code (on
on hand), and since the license enforced it, they send patches back
(on the other hand), where weaker opensources licenses must refer
to good will. I see the LGPL as a good mixture, as it will ensure
the library by itself to remain free, and one can use it in
most paid jobs - I don’t know why I would need to look at the API
of GPL’ed libraries since I could only pick it in one part of my
life, which is not that one which is paying my daily expenses.

but, let’s come back to the original question:

But before getting into it, I wonder if this is ‘legal’ to do, since I
will
not be able to release the source codes of the modified version. But
anyways, it will not have any benefit compared to the current version, it
will just run under a different engine, using different Surface structures
mainly. So actually there is not even a single worthy thing I could donate
back to the public.

This is illegal. Well, unlike GPL, you are allowed to link with proprietary
code, and a different engine. Since that other engine isn’t public,
it is as you state later - it wouldn’t give much benefit for the original
opensource part AS IT IS TODAY, but it will still give an opportunity
to the USERS that will use your modified version, to simply modify it again.
And these users may contribute later on, ye know. And since it is a
modified version, you can not just dynalink with it and make a hint to
the non-modified version as this is prohibited by the license.

However, there are atleast two paths for you out of this complication:

a) make an agreement with the original copyright holder - you stated
that it is basically to strip down the code, and you would be willing
to give credit atleast. Anyway, the original copyright holder may
accept that, or he may accept that if you pay a certain fee, that
your employer might be willing to consider in return for picking this
fine piece of code. And yes, the original copyright holder is
allowed to make an extra non-opensource license agreement with you.
And no, the mere inclusion of patches sent to the original copyright
holder does not make the submitters to become copyright holders too,
they must request so, or their piece must be of such great quality
that it is beyond a simple patch but a kind of feature of its own.
Therefore, only those marked as copyright holders in the
documentation of the libary are the ones to talk to, and no, the
smpeg was not submitted to the FSF like other GNU code, so those
could veto into an extra license agreement with you. You can
get an extra license, possibly paid for.
b) the other path is derived from the section above - you are fine
with putting in function hooks, and to use different data
structures with it from different headers - as long as you ship
those header files too, along with the mofied source code. You
can use this as a backdoor with putting only function calls in
there whose call entries are resolved in a different closed-source
library that your modified-smpeg.dll must be linked with to
function correctly. Now, all you need is to publish the sources
of your stripped-down full-of-hooks code, so either ship it on CD
to your customer, or place it on the website where you probably
advertise your product too as soon as it ships. (well, I would
not like to maintain such full-of-hooks beast).

Well, part (b) is quite an effort, and since the existance of (b) is
known, you can be sure that (a) won’t cost your employer that much
money that you couldn’t afford it. So I recommend to choose (a) and
write to the copyright holders of smpeg today. And since it is as
you say, that you just strip it down, he may just give it for free
in return for an advertiser on your product box, ye know. But you
have to contact them, don’t do it just so, without asking for
an explicit permission.

cheers,
– guido http://freespace.sf.net/guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(±) s+a- r+@>+++ y++ 5++X- (geekcode)

There’s a zipfile in the package ‘visualc.zip’, that has the workspace for
SDL_ttf which contains the lib and an example.> ----- Original Message -----

From: red_dragon08@yahoo.com (Herbert Ayers)
To:
Sent: Friday, February 15, 2002 10:26 AM
Subject: [SDL] sdl_ttf

Where can I find info on how to use sdl_ttf with vc?
Are there any docs or example code?

thanks
Herbert

BTW I’ve got an email list(IGP) We need a couple of
programmers to help with a project. If anybody wants
more info, email me personaly.

=====
Game Programming Groups
VS Entertainment(Houston game dev group, looking for members)
IGP(Internet game programming group, looking for members also)
Ask me for details…


Do You Yahoo!?
Got something to say? Say it better with Yahoo! Video Mail
http://mail.yahoo.com


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Bob Pendleton wrote:

[snip]

Please, read the license. These are important documents. It makes me
very sad to meet programmers who have never read the GPL and LGPL. Its a
lot like the feeling I get when I meet Americans who have never read the
Declaration of Independence and the Constitution.

I have read it. One simply can’t repeat every single detail of it in
every posting relating to GPL/LGPL. I think I gave the essential
substance. Legalistically, static linking is a valid alternative.
Practically, no, because of possible dependencies to other libraries,
for which a archive form may not be available.

Greetings,–
Michel Bardiaux
Peaktime Belgium S.A. Rue Margot, 37 B-1457 Nil St Vincent
Tel : +32 10 65.44.15 Fax : +32 10 65.44.10