[uClibc] buildroot gcc-4 proposed changes

Rob Landley rob at landley.net
Tue May 10 04:21:05 UTC 2005


On Monday 09 May 2005 11:47 pm, Manuel Novoa III wrote:
> > > > Then I would propose to stick w/ the current implementation, add what
> > > > is missing to it (all float/double/long double missing from SuSv3,see
> > > > math patches from me in bugs.uclibc.org), put your implementation
> > > > parallely to the current, so that anyone can choose the one that fits
> > > > her/his licensing requirements, until the new one will become LGPL
> > > > too.
> > >
> > > Absolutely not.  Why should I care about commercial users who do not or
> > > have never supported uClibc development?  If they want to use the old
> > > stuff, then they can go to the trouble of integrating it and
> > > maintaining it themselves.  I don't see why I should make it easy for
> > > them.
> >
> > I don't think this counts as "mere aggregation".  Can you patch it into
> > uClibc and distribute the result if it's not under a compatible license?
>
> How do you come to that conclusion?  libm is a seperate library.
>
> Manuel

Built from the same source tarball, by the same makefile, configured through 
the same menuconfig interface, and replacing code that was previously LGPL...

On the other hand, building a seperate executable from seperate C source files 
in their own subdirectory...

It's tricky.  Very much a borderline case.  I'd get Eric's opinion.  (I'm sure 
there IS a way to distribute it where all the licensing is cool.  The way to 
be sure is to stub out the old one and have the new one be a tarball that 
extracts into the uclibc directory, ala libthreads in glibc.  Distributing 
the binaries shouldn't be much of a problem, but distributing the source code 
as one tarball might...

Maybe I'm just being paranoid...

Rob

Rob



More information about the uClibc mailing list