A package under review — ocserv — uses code from CCAN repository. As I understand CCAN is a copylib according to https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Copylibs as there are no upstream releases (only a code repository).
CCAN URL: http://ccodearchive.net/
ocserv URL: http://www.infradead.org/ocserv/
In ocserv, there is no ccan library shipped, only individual code snippets (macros and some functions) from CCAN are used. The licenses of the code snippets are MIT, CC0 and LGPLv2.1, which are compatible with ocserv's GPLv2.
We discussed this at today's meeting but it turned out to be somewhat tricky after we started diving into the details. We're leaning towards allowing this under a copylibs exception but we are likely to require separate exceptions for tracking each module being bundled.
We're definitely going to have to discuss what the virtual provides should look like. At least some of the modules in ccan come from another source. For instance, the lists module seems to be shared with the kernel and the hash module originates here: http://burtleburtle.net/bob/c/lookup3.c
Maybe something like bundled(kernel-list) and bundled(bobjenkins-lookup3).
(We also discovered that memcached also includes the bobjenkins code so tracking this between implementations is more than theoretical).
If you'd post the list of ccan modules that are being bundled to this ticket, that would be helpful. Thanks.
The modules used by ocserv are the following:
1. container_of: http://ccodearchive.net/info/container_of.html
2. htable: http://ccodearchive.net/info/htable.html
3. hash: http://ccodearchive.net/info/hash.html
4. list: http://ccodearchive.net/info/list.html
(the following aren't used directly by ocserv they are dependencies of the above 4)
5. check_type: http://ccodearchive.net/info/check_type.html
6. build_assert: http://ccodearchive.net/info/build_assert.html
Note however, that the CCAN archive has some modules that are similar to some kernel APIs, but they are '''not''' identical. For example the list module in the linux kernel is under GPLv2-only, while in CCAN it is under a BSD-MIT license. Also the API isn't identical (check for example list_add() in kernel and in CCAN, they accept different parameter types). So I don't think that this can be named the linux-list module.
I think that mentioning the bundled modules with a link to upstream (e.g. bundled(ccan-container_of), bundled(ccan-list) ) could be sufficient for someone to get an idea about the contents. That would also be sufficient to someone making a library out of ccan, to know which modules are in actual use.
Going into a higher level of granularity (e.g. jenkins lookup3, or just another person's macros) may be hard to enforce as it is difficult to discover (public domain code may be present inline in other code and no maintainer could be able to find out where did that code came from originally).
Yeah, that's why I hate copylibs... the practice includes some of the worst ways to bundle libraries that make it hardest on us.
One of the core principles of the bundled libraries guidelines is that we are able to track all the instances of code together so that a security issue that is raised against one of the instances of the code can be applied against all of the instances. If we can't do that then we probably wouldn't want to issue a bundled library exception. That's what makes this particular instance of copylibs so problematic... the way it's constructed makes tracking even harder than usual.
They are not that bad. At least if you compare with the situation where every project had its own linked-list implementation, its own hash tables etc. Now at least there are some mature implementations to copy from. What is missing is a library that is available everywhere (like libc) containing those functions.
glib is very good for desktop applications, but it is rarely available in an embedded system (probably too big). So I'm not sure its suitable for server application that (also) targets small systems.
Proposal for the virtual provides:
Please use the virtual provides listed in comment:8
Other programs may use those virtual provides to include those snippets of ccan. If they wish to bundle a different snippet of ccan, they should apply for a new exception from the FPC.
Added to table on the no bundled libs page.
CCAN is a site and code repository that collects small, useful C code files. Several bundled library exceptions have been granted for individual modules from that site on the basis that they are copylibs. See the table on https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_exceptions for the list of modules and the virtual provides to use for them.
to comment on this ticket.