uClibc copyright and licence audit
Hi,
I've taken over the Debian uclibc package a few months ago, and while
the technical bits of the package are working fine, the current
copyright/licencing situation makes it very difficult to upload the
package into Debian (i.e. my last uploads have been rejected for that
reason).
The situation is as follows: uclibc has over 2000 source files (~1800
files ending in .c and .h, plus the build system), with lots of
different copyright holders and licences. While the situation is not
hopeless (the vast majority have clear information, and I haven't found
too many :-) incompatibilities so far), it is nonetheless needed to do a
full audit.
There are a few "trivial" files consisting of three or four lines of
code that do not have proper attribution, and some stuff seems to have
been duplicated and patched (mostly in the ld.so directory) without
adding the authors of the modifications; also it is necessary to
cross-check whether some of the licences affect each other in curious
and interesting ways (for example, the LGPL stipulates that the build
system is part of the source; however large parts of that are GPLed,
which could lead people to argue that the binaries are also under the
GPL (the LGPL permits relicensing under the GPL and stipulates that the
build system is part of the source, so the only way to reach a
consistent licencing would be to apply the GPL everywhere).
So, I'm planning to go through all of the files and find out who wrote
what, add the proper attribution in the source files and a longish
document that summarizes everything. As this is significantly more fun
with more people, I'm asking for supporters.
There are a few different options:
- an IRC meeting
this would probably take place on either 22nd/23rd or 29th/30th this
month, probably on freenode's #uclibc or if people request it on a
different channel
- a RL meeting
I'd offer to host such a meeting in Munich if there is interest (this
could be combined with a visit to the Oktoberfest if it happens on the
29th/30th or 5th/6th/7th next month)
- a wiki page
less "fun", but does not limit things to happen in a certain time frame
- inside the svn
probably still needs some additional coordination to avoid people doing
duplicate work, but has the advantage of all the info ending up in the
right place from the start.
Opinions?
Simon
Reply to: