Hi, Regarding this, I have the linkage with Tso's libuuid almost done in base/pdf-types-uuid.[ch].
However, Tso's libuuid does not provide generation of name-based UUIDs, as required in doc/gnupdf.texi; it provides time-based and random-based generation only. So, my question is: is the name-based generation a must? If it is, I could implement it in libuuid and then come back to libgnupdf to complete the linkage. If it is not, this task is almost done :) By the way, I'm feeling curious about the UUID module: where is it going to be used? Albert 2011/1/22 Jose E. Marchesi <jema...@gnu.org>: > > Hi Albert. > > As for the standard compliance, he pointed that the uuid library is > written to follow the OSF/DCE specification, which was used as source > material for RFC 4122 and X.667. AFAHK, 4122 and X.667 are aligned. I > hadn't got enough time to check if the alignment is partial or total > between both specifications. I think it should be performed before > deciding if libuuid's code is going to be the official uuid module > implementation or not. > > Tso's uuid library provides both UUID generation and parsing routines. > More than enough for our needs. > > Regarding the license, libuuid was originally released under LGPLv2, > but currently it is under a BSD license to allow Apple to use the > library in MacOS X. So the library is compatible with GPLv3. Ted would > appreciate changes or improvements made to libuuid to be donated back > using the currently BSD license (is that possible after adopting it in > a GPLv3 project?) instead of forking it in the GPLv3-only universe. > The BSD license legally allows us to do that, but he doesn't consider > it "a neighborly thing to do". > > I don't think that will be a problem. The simplest way to go is to > write a thin layer in pdf-uuid.[ch] and link with libuuid. In case we > need to extend the library (quite unlikely) we can contribute the > changes under the BSD license. > > -- > Jose E. Marchesi jema...@gnu.org > GNU Project http://www.gnu.org >
