LGPLness in lib

[dtaht]

I have to admit that I have lust in my heart to be able to lift bits of ipv6calc into a simpler library mostly dedicated to dealing with prefix pools quickly (sse2 and arm intrinsics for the fast stuff). But to do that, I'd have to license it LGPL, and it looks as though ipv6calc the program is GPLv2 (which is fine) and most of the libraries could be LGPL, except that they aren't.

[pbiering]

would you mean split up existing libraries, e.g.

/usr/lib64/libipv6calc.so.0.99.2
/usr/lib64/libipv6calc_db_wrapper.so.0.99.2

into more? Then first a set of functions must be defined which can be used by 3rd party tools linked to new library...unfortunatly code isn't really clean enough structured. I've started working on some abstraction layers to keep at least here the API stable enogh, see mod_ipv6calc which tries to use partially abstracted functions.

Also then only the abstracted functions should be marked as "exportable".

BTW: most of the "intelligence" is in the library and not in the binaries.

So the major work would be

• define set of function which is "allowed" (and consistent to use) to be used by 3rd party tools
• adjust/extend functions to have them either longterm API stable or containing a version in the API call (requires to deal with stable or versioned structures)
• check existing code for any other license dependencies (e.g. overtaken code)
• then potentially change the license of the code which exports the the defined set of functions and all dependend code...(more or less all the lib code)

[dtaht]

Yep. Too difficult to do to your codebase. What I started doing instead was start from scratch with lots of ranting.

I am a pretty dedicated user of ipv6calc (and thank you for it!), but it's the busted prefix distribution/splitting/searching from within a variety of C and C++ daemons that has been making me crazy, and that's what I'm going to try to address in the coming months.