Lloyd Sargent wrote:
> Mark Swayne <mark.swayne@... <mailto:mark.swayne@...>>
>> Here are the issues with different licenses:
>> 1. LGPL protects the libraries, but static linking make it's terms
>> identical to the GPL, thus it is unsuitable for our use.
>> 2. BSD license is almost like public domain, and SDCC libraries
>> could be apropriated.
>> 3. Standard GPL protects the libraries, but makes commercial/
>> proprietary development impossible.
>> 4. GPL plus runtime exception protects the libraries themselves ,
>> but allows proprietary development.
> 1. This is correct. Static linking can become very problematic. Thus
> for embedded systems it isn't a good choice.
> 2. This is NOT like public domain. By definition public domain HAS no
> copyright. This is very different from BSD which sez that you MUST
> keep the copyright info. The difference between GPL and BSD thus are
> "do I have to release modified code". BSD sez no. GPL sez you have to.
The BSD license is like public domain in that you can do pretty much
anything you want to with it. Over the limited domain of 'ability to
incorporate with proprietary software', BSD is very much like PD. It
is, as you say, different in that the code retains copyright. This is
an excellent license, and I recommend it for developers who do not care
if their code is incorporated into proprietary software. The BSD
license puts individual freedom before the needs of the community.
Whether this is a good thing is an individual moral/ethical decision,
and I do not pretend to have a definitive answer.
> 3. Not entirely correct - as long as your code is "still functional
> without the libraries" (it does not define what "functional" means)
> then yes, you can do commercial development. The trick falls in
> "functional". I'm not a lawyer and I wouldn't want to try to take THIS
> to court. Too problematic.
It's a bit tough to have a non-trivial C program that is functional
without the standard C libraries.
> 4. I'm not sure what this means - are you talking about a modified
> LGPL? I would like a little more info by what you mean by this before
> critiquing it...
I refer to the runtime exception (aka linking exception, libgcc
exception, runtime GPL) used by GCC for its libraries. I included
slightly modified text of an older version of the runtime exception in
my original post. See this page for the current text and some answers
to specific, pragmatic questions:
With this exception, commercial, proprietary development is possible.
Actually, without it, you couldn't use GCC to produce BSD licensed
software. Protecting the ability to compile software under any license
is its purpose. The reason this exception was developed is that with
C++ programs, enough code from standard libraries is directly added to
the compiled object files (through inline functions, templates, etc.).
This makes LGPL unusable for C++ libraries, just like it is unusable for
>> The only license that meets these criteria is GPL plus the runtime
>> exception. You don't have to believe me on 4, Apple Computer's squad
>> of attack lawyers holds that opinion, otherwise OS X would not be
>> compiled using GCC.
> Yes, and the Mac (of which I own many) doesn't use static linking. So
> I'm a little puzzled how this validates your argument...
GCC is used by many companies for commercial software. It is explicitly
stated in the licensing material that comes with GCC that this is
legal. GCC libraries are licensed under Runtime GPL, static and dynamic
linking have absolutely nothing to do with it. Please read the terms of
the exception I linked above.
> The only LEGAL way you can have everything about the GPL, but allow
> for static linking, is to MODIFY the GPL. As you say, this is tricky,
> at best. Again, I would argue that the cleanest route is BSD as it
> assures that the software MAINTAINS THE COPYRIGHT and has NO
> RESTRICTIONS. If Joe Blow wants to make a private version for CompCo,
> how does that take anything away from me?
Exactly. The modification has already been done. We do not need to
come up with a new, specialized flavor of the GPL. The FSF has already
done it for us. As I said in my first post, I think that SDCC libraries
should be either BSD or Runtime GPL licensed in order to be distributed
with SDCC. Either, depending on what the developer of the library
prefers. Both licenses allow an SDCC user to develop under whatever
license she pleases, which is the goal of this discussion..
> I guess I don't understand the "GPL or nothing" viewpoint. I thought
> the goal (at least with SDCC) was to allow people to use it for
> serious development, including projects they wish to sell. To that
> end, BSD gives the maximum freedom.
> Back to the shadows...
Both the BSD and Runtime GPL license meet the stated goal.
The issue of GPL vs BSD comes down to an individual value judgment. BSD
puts a premium on individual freedom--the recipient of the code is free
to do anything with the code but claim it as their own. With the GPL,
the needs of the community are given more weight--one must agree to a
social contract in order to use the code. Which is 'better' is a value
judgment and is the sort of thing that moral and political philosophers
and a few economists have devoted careers to unraveling. Do the needs
of the one out weigh the needs of the many? Kirk says yes, Spock says
no--whatever, I've never been one to appeal to dieties for guidance.
In any case, I would like to avoid a licensing war. Licensing
discussions tend to get heated and descend into pointless shouting
matches. My sincere hope is that we have avoided that fate. I made my
first post in an attempt to clarify the issues relating to possible
licenses, so that we could get back to productive topics. The key issue
was that the Runtime GPL was being confused with the standard GPL. I
hope I have further clarified the what the Runtime GPL is, how the
Runtime GPL differs from the LGPL and why the BSD and Runtime GPL
licenses are good licenses for the SDCC libraries.