[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