Retiring from uClibc development

Rob Landley rob at landley.net
Sat Apr 8 19:52:00 UTC 2006


On Sunday 02 April 2006 8:43 pm, Rich Felker wrote:
> On Sun, Apr 02, 2006 at 01:31:45PM -0500, Rob Landley wrote:
> > On Saturday 01 April 2006 10:20 pm, Manuel Novoa III wrote:
> > > > The same argument could be made about the Linux kernel itself, which
> > > > is GPL not LGPL.
> > >
> > > A commercial user's application would be _linked_with_ GPL'd code,
> > > which is a big difference from just using the kernel.
> >
> > Statically linked, sure.  The question is where can you successfully
> > argue "mere aggregation" with shared libraries that have a stable and
> > documented API?  If you write proprietary CGI scripts and ship them on a
> > device where they're served up by GPL apache, is your CGI now GPL? 
> > Where's the line?
> >
> > Assume for the moment that they're using a totally unmodified binary of
> > your library they got from a third party (so they've never even seen
> > uClibc source code), and their app is entirely from their own source
> > code, and their app was built and tested against glibc where it works
> > just fine.  Your argument is that they can become a derived work of the
> > GPL without ever posessing GPLed source code, by leaving all existing
> > GPLed files unmodified, simply by using documented APIs they read out of
> > a book and shipping your library's implementation of them.
> >
> > What actual content from uClibc gets copied into their executable?  (And
> > if you point to stuff that came from header files, why doesn't it apply
> > to glibc too?)
>
> It's copied into the product as a whole, which (in my example) does
> not run without uClibc (because glibc is too big to fit on the system.
> The intent is also critical. (Again in my example) the party shipping
> the product is not making an independent program that incidentally
> happens to work with uClibc. They're making a unified product whose
> functionality depends on the presence of uClibc.
>
> > Does a shell script run by bash fall under the GPL?  How about if it
> > extensively uses bashisms documented on the bash man page?  How about if
> > someone were to use tcc's "-run" mode on C source code, with a gpl
> > library
>
> See my final paragraph below..
>
> > listed on the command line?  Are they a derived work if they dlopen a gpl
> > library at run time?
>
> Yes, as long as the GPL has jurisdiction. (Obviously if they did not
> install/ship the GPL-licensed .so file themselves, but the user
> obtained it independently from someone else, the GPL has no
> jursidiction.)

What differentiates dlopen() with a standard function name from shelling out 
to a program on the command line?  Are you saying there's a web browser 
plugin out there that could make Internet Explorer a derived work of your 
plugin, retroactively?

There _are_ some invocation methods that the GPL does not cross.  If a 
proprietary program has an option to pipe data through /bin/gzip on its way 
to disk (or across the network), it doesn't become GPL no matter what license 
gzip is under.

> > Whether a program that uses a shared library is a derived work of that
> > shared library, or merely aggregated with that shared library, is not a
> > black and white issue.
>
> As long as copying or distribution of the library takes place by the
> allegedly infringing party, the key issue is the intent of the
> copyright holders.

Have you ever actually been involved in any litigation?

> If the intent is not to allow the code for use in 
> proprietary programs at all, and this intent is made clear, then the
> technicalities of what constitutes a derived work are not so
> important.

"I know what I meant, don't bother me with technicalities".

How far do you honestly think that would go in court?

> I don't think anyone is successfully going to argue in 
> court that the GPL granted someone more rights than the copyright
> holders intended by using the GPL.

The default behavior of people who don't interpret the license the way you do 
(or who simply don't care) is to ignore you.  You have to sue _them_ to 
enforce your license, and if they believe they have a decent defense they 
will drag the issue out for months or years, costing you lots of money to 
pursue the case.  (Look how long SCO has lasted without a leg to stand on.)

Ideally, you want to go in and get a summary judgement in your favor, or a 
strong enough initial statement from the judge that the other party is 
motivated to settle.  Saying "my license applies to any arbitrary bash script 
if I mean it to, just because the system has uClibc on it" pretty much 
guarantees you aren't getting one.

If you can't coherently explain to a judge how what they did was different 
then them shelling out to gzip, you will lose, on the derived works issue.  
There _is_ a "mere aggregation" clause in the GPL.  The license itself says 
that it's an option.  It's your job to explain why it doesn't apply.

> Rich

Rob
-- 
Never bet against the cheap plastic solution.



More information about the uClibc mailing list