[SDL] Re: Embedded license? (SDL contributers please read!)

[Ricardo Cruz]

Em Sexta 28 Outubro 2005 01:14, o Elden Armbrust escreveu:
> Steaphan Greene wrote:
> >On Thu, Oct 27, 2005 at 08:42:51PM +0200, Torsten Giebl wrote:
> >>Hello !
> >>
> >>>That would completely change the whole idea.  This would mean you'd be
> >>>back to proprietary games just releasing a single binary and if a new
> >>> piece of hardware isn't supported by the statically linked version od
> >>> SDL, you are once-again screwed.  I think (hope?) that Sam doesn't want
> >>> to see this happen to SDL.
> >>
> >>Okay, this would be more than Sam wanted, but it would
> >>allow people to choose whether they want to distr. the
> >>binary stat. or dynam. For me it is always good if the coder
> >>has more rights than less.
> >
> >In my understanding, you can already do this, so long as a dynamically-
> >linked version is also available.  This is part of the main difference
> >between the LGPL and GPL.  Am I misunderstanding this?
> >
> >I don't see any reason why you'd want to distrib a statically linked
> >version of it though, if you don't have to.  You can always just distrib
> >the shared lib (or dll) along with the executable in case it's not on
> >the system.  Am I missing something here too?
>
> The way I've deciphered the legalese:
> GPL - Any use of the software covered by the GPL license must be
> provided in source form, as well as any derivative work.  This means
> that if libfoo is GPL, and you make a program called BAR, then the
> source code must be distributed with the binary and use a license that
> is compatible (read: doesn't conflict with any of the GPL licensing
> issues).
>
> LGPL - Any use of the software covered by the LGPL license is not
> required to be provided in source form, nor is a derivative work, as
> long as the LGPL work is not included physically into the work using or
> deriving from the LGPL work.  Since statically linking includes the code
> and symbols for the library, that would mean you must make the program
> you made available in source form.  In this instance, libfoo is LGPL and
> if you link BAR statically you must provide the source code for both (in
> some manner).  However, if you link BAR dynamically to libfoo then you
> may distribute BAR without any restrictions (unless of course you use a
> different licensing scheme, etc) aside from the notable mention set
> forth in the LGPL.
>
> This is a *severely* dumbed down version of how the GPL and LGPL
> licenses break down, and by no means should be used verbatim as a
> definition of either.  If you *really* need to know about what you can
> or can't do under those licenses, or using software that does, consult
> an attorney.  Seriously.
> Mind you, there are other similar licenses.  However, most of those
> licenses either have certain caveats that aren't obvious, or are lacking
> in some serious way which can fail to protect your work.
>
> Perhaps there are existing licenses which will work for what Sam wants
> to do.  Personally the zlib license has always appealed to me
> personally..however..
> The Apache Software License appears to be exactly what I would be going
> for if I were in Sams shoes:
> http://www.opensource.org/licenses/apachepl.php Basically: notable mention,
> no restrictions aside from not claiming you made the library, or using the
> libraries name anywhere in the name of your product.
> Nice and liberal, while still maintaining that balance.
>
> -Elden
>
 Merits aside, I guess Apache license is out of question because it is not 
GPL-compatible. A lot of SDL-based games are GPL and I think it would be a 
hassle to just ask them all to change their license.

 By the way, what do you like about it? Doesn't it have actually more 
restrictions than the LGPL and even GPL?

Cheers,
 Ricardo

-- 
How come only your friends step on your new white sneakers?