Thanks for the detailed info, Jonathan.
I agree that we could replace klee-libc with other code, but first of
all, I am wondering whether we still need it in the first place. My
impression is that everyone uses klee either standalone or with uclibc,
but please let me know if there are any users who need the "--libc=klee"
option.
Unless I hear otherwise, my suggestion would be to remove that directory
from the mainline, and perhaps just offer it as a separate external
library, as we do with uclibc.
Best,
Cristian
On 26/06/13 00:56, Jonathan Neuschäfer wrote:
On Tue, Jun 25, 2013 at 04:01:40PM -0700, Daniel Dunbar wrote:
Hi Jonathan,
Where did you derive the author information from?
If you can verify that the implementations we have are from a particular
source then we should probably import their license. If we can't verify the
right source license, then my recommendation would be to try and find BSD
licensed ones we could import (and include license, if need be).
I took the authorship information from the license comments in these
files. They are all under the 4-clause BSD license, which is quite
problematic for its advertising clause:
"3. All advertising materials mentioning features or use of this
software must display the following acknowledgement: This product
includes software developed by the University of California,
Berkeley and its contributors."
The NetBSD libc seems to suite our purpose, it's 2- or 3-clause BSD
licensed: ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/lib/libc/
I haven't reviewed the code in question yet, though.
Thanks,
Jonathan
_______________________________________________
klee-dev mailing list
klee-dev@imperial.ac.uk
https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
_______________________________________________
klee-dev mailing list
klee-dev@imperial.ac.uk
https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
