Ricardo Cruz wrote:>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
Maybe I should have been more clear. I like the zlib license because it
gives almost complete control to the developer. You can open source it,
you can closed source, whatever you want. Now, for the Apache license:
in terms of number of restrictions, yes there are more restrictions as
far as I know. As for the severity of those restrictions, however, that
is where the true difference lies. I’ll copy the two licenses below
(abridged, of course), followed by a good reason for my feelings on it.
(Work was easy today, so I’m in the mood for a little conversation.
Apache license:
-
Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer. {Self
explanatory}
-
Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
[Again, self explanatory]
-
The end-user documentation included with the redistribution, if any,
must include the following acknowledgment:
“This product includes software developed by […].”
Alternately, this acknowledgment may appear in the software itself, […]
{This is actually one of the points that makes this license ideal for
the embedded version, in my mind.}
-
The names […] must not be used to endorse or promote products
derived […]
{Standard jargon for a good number of licenses}
-
Products derived from this software may not be called “Apache”, nor
may “Apache” appear in their name, without prior written permission
[…] {This is beneficial, as someone might make a very bad game about
something raunchy, controversial, etc. and stick SDL to it for some free
press ™}
Of course, all references to Apache would be changed, as it would be a
modified Apache license when used with SDL.
Now, the (current) LGPL license:
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
1. You may copy and distribute verbatim copies of the Library’s
complete source code as you receive it,[…] and distribute a copy of
this License along with the Library.[…] {You can copy it. Duh.}
2. You may modify your copy or copies of the Library or any portion of
it, thus forming a work based on the Library, […] meet all of these
conditions:
a) The modified work must itself be a software library.
b) You must cause the files modified to carry prominent notices
stating that you changed the files and the date of any change.
c) You must cause the whole of the work to be licensed at no charge
to all third parties under the terms of this License.
d) If a facility in the modified Library [...]
{Not pertinent in this instance.}
3. You may opt to apply the terms of the ordinary GNU General Public
License instead of this License […] Do not make any other change in
these notices.
Once this change is made in a given copy, it is irreversible for that
copy, […]
4. You may copy and distribute the Library (or a portion or derivative
of it, under Section 2) in object code or executable form under the
terms of Sections 1 and 2 above provided that you accompany it with the
complete corresponding machine-readable source code, which must be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange. {Here is where the problems
begin. How do you supply machine readable source code which may well
contain source code licensed under a closed, and possibly covered by a
non-disclosure agreement, which isn’t unheard of on embedded systems}
If distribution of object code is made by offering access to copy from a
designated place, then offering equivalent access to copy the source
code from the same place satisfies the requirement to distribute the
source code, even though third parties are not compelled to copy the
source along with the object code. {This clears up the above paragraph a
bit, basically allowing you to offer it from the same place as the
binary, though not requiring it be bundled with it.}
5. 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.
However, linking a “work that uses the Library” with the Library creates
an executable that is a derivative of the Library (because it contains
portions of the Library), rather than a “work that uses the library”.
The executable is therefore covered by this License. Section 6 states
terms for distribution of such executables. {And here is where we really
get into trouble.}
When a “work that uses the Library” uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be linked
without the Library, or if the work is itself a library. The threshold
for this to be true is not precisely defined by law.
If such an object file uses only numerical parameters, data structure
layouts and accessors, and small macros and small inline functions (ten
lines or less in length), then the use of the object file is
unrestricted, regardless of whether it is legally a derivative work.
(Executables containing this object code plus portions of the Library
will still fall under Section 6.)
Otherwise, if the work is a derivative of the Library, you may
distribute the object code for the work under the terms of Section 6.
Any executables containing that work also fall under Section 6, whether
or not they are linked directly with the Library itself.
6. As an exception to the Sections above, you may also combine or link
a “work that uses the Library” with the Library to produce a work
containing portions of the Library, and distribute that work under terms
of your choice, provided that the terms permit modification of the work
for the customer’s own use and reverse engineering for debugging such
modifications.
You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License. You must supply a copy of this License. If the work during
execution displays copyright notices, you must include the copyright
notice for the Library among them, as well as a reference directing the
user to the copy of this License. Also, you must do one of these things:
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.) {Here it is, the dreaded paragraph
that keeps many companies away from the L/GPL licenses. If you use
the library and link statically you have to provide your executables
code. Period.)
b) Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (1) uses at run time a
copy of the library already present on the user's computer system,
rather than copying library functions into the executable, and (2)
will operate properly with a modified version of the library, if the
user installs one, as long as the modified version is
interface-compatible with the version that the work was made with.
{This is the exception built-in for shared linking.}
c) Accompany the work with a written offer, valid for at least three
years, to give the same user the materials specified in Subsection
6a, above, for a charge no more than the cost of performing this
distribution.
{This is nice, but when building for an embedded device, shared
linking isn't always guaranteed}
d) If distribution of the work is made by offering access to copy
from a designated place, offer equivalent access to copy the above
specified materials from the same place.
{Same as above applies.}
e) Verify that the user has already received a copy of these
materials or that you have already sent this user a copy. {Moot.}
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 materials to be
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. {Again,
this applies specifically to the embedded device market in this case.}
[Snip.]
{What follows is unrelated to the topic at hand.}
Assume the following:
Joe Shmoe makes a game, “Foobar the blogmeister.” for the Sony PSP.
(Assuming that…) The Sony PSP cannot link to shared libraries, and
therefore must be linked statically.
The PSP SDK contains software which restricts the free distribution of
the code contained. (Read: You can’t give away the SDK or any part thereof.)
Now Joe wants to use SDL to handle all the menial work and get his game
working quickly.
Picture a large flashing “NO!” sign. That’s exactly the answer he’d get
from a lawyer when asked if he could use SDL.
SDL, according to the LGPL, requires that the source code to a work
which links statically must be available to the public.
However, Sonys PSP SDK almost certainly will not allow the source code
of their work to be given away.
Likewise, the game itself might be the next Quake/Half-Life/Unreal which
Joe wants to keep hidden from prying eyes which might steal his work.
Even without looking at company specific terms, the UMD used by the PSP
is unreadable (as far as I know) on anything but a PSP. This means that
Joe must offer his source code via mail, the internet, or some other means.
There are a myriad of reasons not to use the LGPL/GPL license on an
embedded platform, but very few that would warrant using it.
Don’t get me wrong, the LGPL/GPL licenses are great, but not
particularly conducive for use on an embedded platform.
Remember that while many of us might not have a problem with open
sourcing our software, most companies are firmly against it still.
Feel free to comment, take this to another conversation, do as you wish.
Consider my comments LGPL’ed. 
-Elden Armbrust
