On 10/5/2010 8:11 PM, Zach Welch wrote: > No, this problem derives from the mess of intellectual property laws > that must be respected in order to preserve the integrity of the myriad > of projects that want to be using this code, while still allowing all future > improvements to flow seamless between them.
And that "all future improvements" is where this gets really tricky. You can put BSD code into GLIBC. (You may not be able to get the FSF to put it into FSF GLIBC without an assignment, but you can ship an Ubuntu GLIBC built this way. Perhaps the EGLIBC members might consider waiving the requirement for FSF assignment for EGLIBC, and you could get the patch in EGLIBC. Etc.) But, if I'm a downstream GLIBC developer, and I choose to improve your memcpy, and I do so in the context of GLIBC, my changes are quite likely to be LGPL. And you won't get to put those into Bionic, say. So, if you really want this, the best solution is probably to have an upstream "string routines" project and host the code there, and encourage libc's of all flavors to incorporate that code, and to contribute changes there. But, you probably have better luck if you do not restrict it to ARM; i.e., if you are willing to also accept code for other CPUs, and even share algorithmic infrastructure that's common across various CPUs. You also want to design for some of the differences between a statically linked libc and a dynamic libc. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
