Re: Results of "downloading compressed program images" request

[Joel Sherrill <joel@OARcorp.com>]

Sorry for not replying sooner.  I have been away form email for a few
days.

On Sat, 10 Jan 1998, Richard Stallman wrote:

> 	Joel> I dismissed kermit because I remembered that it could not be
> 	Joel> included in Linux distributions because of the licensing.
> 
> Kermit is not free software; it is far too restricted.  Thus, it
> cannot be included in any free operating system.  For the definition
> of free software, see http://www.gnu.org/philosophy/categories.html.

That was my conclusion.

>     Joel> Someone else may be able to give a better explanation but
>     Joel> let's take the Every discussion I have ever seen of the LGPL
>     Joel> on-line says that if you use an LGPL'ed library in your
>     Joel> application, then you must provide the proprietary part of
>     Joel> your application in a form such that it can be relinked
>     Joel> against the LGPL'ed code.
> 
> Yes, this is what the LGPL requires.  The LGPL was designed
> specifically to require this.

I am glad to hear that I understand what the LGPL requires.  This is how I
explain to people how to satisfy it.

> The danger of a spurious liability lawsuit is a part of life in our
> society, and it makes sense to be concerned about it.  It seems to me
> that Joel is disproprortionately worried about one scenario out of
> many that could lead to this result--and not a particularly likely
> one.  Using an LGPL-covered library makes no real difference to the
> situation, because it is always possible for a customer to tinker with
> the box he bought, and break it.
> 
> People usually deal with this issue with warning labels, such as,
> "Don't mess with this, that voids the warranty and it might even be
> dangerous."

I am paranoid about this because my focus is not on a single application.
Whatever license we pick for RTEMS impacts every RTEMS application.
RTEMS is a real-time operating system but it is typically linked 
with the application code into a single executable image.

I agree that the risk of anyone actually relinking an embedded
application is small.  And I will even grant that even if you
were sued, the odds of actually losing are small.  But the risk
is there.  And the cost of defending yourself in a legal battle
could be high.

More important in my mind are the risk of physical injury from
an altered embedded application and the distribution burden I
am placing on users.

> We use the ordinary GPL for some of our libraries.  In fact, that is
> our default choice, for a library just as for any other program.

I think the GPL is perfect for software which is "complete" unto itself.
The problem is for libraries and the implact the license has upon the
intended user domain.

> The GNU project's goal is to encourage and facilitate the development
> of free software.  We want to encourage people to use free software,
> even when they are proprietary software--but that does not mean we
> think that developing proprietary software is a good thing, or that we
> aim in general to help people do that.

The RTEMS community is a bit unusual.  Most write software for custom
boards/systems which are not of interest to a wide user base. But those
same users are very good at identifying reusable, shareable components
which do make sense to redistribute and share.  I guess the embedded
domain is a bit different in that every application is proprietary but the
"infrastructure" software can be free and shared.

> Using the GPL for a library means it is available only for free
> programs.  That way, we help the development of free software but do
> not help the development of proprietary software.  In many cases that
> is exactly what we want to achieve.

That is the conflict with the embedded world.  The tools and many
libraries can be shared from project to project and made free software but
ultimately, the application is nearly always proprietary.  Free software
targetting embedded users must account for this in the choice of license.  

Much software from the non-embedded world can be tailored for use in an
embedded system (a communications protocol or compression library for
example).  But if the choice of license is unpalatable to the embedded
community, it will simply not be used.  

> We make an exception, and use the LGPL or the libgcc.a distribution
> terms, when there is a specific reason to do that.  The most common
> reason is that a particular library is the key to using a much larger
> body of free software, instead of some proprietary alternative.

That is the same argument I am making.  It also applies to RTEMS and the
GNAT run-time.

> For example, libgcc.a is a tiny part of GCC; if libgcc.a were covered
> by the GPL, it would be blocking proprietary developers from using
> GCC.  We judged it was better for free software development to have
> more users for GCC, and thus more development of GCC.

For RTEMS, it was more a choice of very few users.  

> The existence of equivalent alternatives is also a crucial factor.
> There are many proprietary compilers, and many proprietary operating
> systems that have C libraries which, while not free software, may be
> linked into compiled programs.  So if we did not allow using libgcc.a
> and GNU libc in this way, that would not hamper the development of
> proprietary programs; it would only give the developers a reason to
> pick a different compiler, or a different operating system.
> Clearly it is better for the progress of free software to allow
> use of these particular libraries in proprietary software.

Amen.  This is exactly where RTEMS falls. 

> But that is not true for for all libraries.  If a free library
> implements some useful special feature, often it is better (for the
> development of free software) to distribute it under the ordinary GPL
> so that it gives free software development efforts an advantage
> over proprietary development efforts.

Good example.  Is there currently an example of a library which falls into
this category?

--joel
Joel Sherrill                    Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985