Keisuke MORI wrote: > Alan Robertson <[EMAIL PROTECTED]> writes: >> Matthew Soffen wrote: >>> I don't see it being any problem. >>> Is there any "convention" that other projects use ? >> >> 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 think changing the library names to distinct its license is > not so common, and I feel a bit uncomfortable...
Being a little different has never bothered me much ;-). > Other options came up to my mind are: > > 1. Clearly note somewhere on a document, probably in > "Exceptions" section on http://linux-ha.org/FileCopyrightPolicy . > > It needs less work, but users tend to miss it, and documents > tend to be out of date:-) The FileCopyrightPolicy is really intended for developers. > 2. Separate the directories for LGPL and others in the source tree. > Only LGPL files (that conform to the project policy) should > be put into lib/ directory, and for other directories it > depends on each module or developer. For example, GPL'ed > lib/crm might be in, say crm/lib, and when the developer > decide to change some of the functions to be LGPL, he may > want to move those into lib/ directory with the new license > statement. > > Users who concern the license just need to check if it's in > lib/ directory. They don't have to look through all the > source code in the tree. The directory structure is used by the build mechanism to enforce build ordering, and build order isn't at all tied to license. For example, right now, all lib directories are built first. This might be messy and have other implications. And, moving files between directories is messy with CVS. Although with Mercurial it's less messy. > > 3. Separate RPM package for LGPL libraries, say heartbeat-lib-*.rpm, > which is intended to be used by users as to the project policy. > > Users who concern the license should only use the libraries > in this RPM. A problem would be, because the lib rpm is > always required, all users have to do extra steps to > download and install. Well... The idea about a separate package is good -- if you're using RPMs. If you're building a product based on our code, you may not use our RPMs, but repackage it yourself to include only what you need. Quite a few people don't use RPMs at all. > I personally think that 2. is clear enough and good for developers, > although I'm not sure how big the impact is for the library in question. > > I hope it helps. > > BTW, if this topic came up from my post about the license, > it is not an urgent issue for me. sorry if I confused you. It made me start thinking. If you need for us to change the license for the code you asked out, let Andrew know. I think I misunderstood or misjudged his intentions. I think it's likely that he'd make it available to you LGPL. Unfortunately from a legal perspective, the ruling document is always going to be information in the source files. This is just intended to make it easier to figure out -- both for us and for the user of our software. -- Alan Robertson <[EMAIL PROTECTED]> "Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
