On 2006-08-23T14:41:08, Alan Robertson <[EMAIL PROTECTED]> wrote: > Not that I know of. I just thought this might make things clearer to > those who want to link to our libraries - which ones are under which > license.
I _do_ agree we need to document which APIs/ABIs we want to support (if any), and which license this falls under, and how stable we expect that API/ABI to be (ie, which symbols will we carry forward, are apps likely to break from 2.0.7 -> 2.0.8 for example, will a recompile suffice, and which changes will prompt an increase in major/minor version?). There's also the detail that the LGPL license must also apply to the headerfiles themselves, not just to the library. Thus, what I think would make more sense is to simply remove all header files for non-public functions from /usr/include/heartbeat/ ;-) Everything in there should be "public", else why put it there ... And then figure out some way to comment on API/ABI stability. BUT, I agree our libraries need a more consistent naming scheme! If we're changing the library names, we ought to add a "heartbeat" or an "hb" in there, to avoid filename collisions. libccm, libcib, plumb et cetera are not very indicative of the libs belonging to heartbeat. Putting the license of the library into the name of the library itself seems to achieve too little. But I guess we _could_ add the _gpl qualifier in there at the same time... Sincerely, Lars -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge" _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
