On Thu, 24 Aug 2006, 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...
Me, too. I cannot think of any other project in which the name of the runtime library is used to distinguish GPL vs. LGPL (or, come to that, any other licensing) issues. There's a mismatch going on here. Conventionally, names of run-time libraries reflect technical purposes of the library, not licensing. Let's stick with convention unless we've got really good, sound reasons for deviance. It feels like a mismatch of attempted fix and (mis-)perceived problem. If the intention of Linux-HA is that all run-time libraries should be LGPL (rather than GPL) then let's just do that. If we happen, at the moment, to have a mixture, then that's where the problem lies and that where (it seems to me!) it ought to be fixed. Establish our policy; get our stuff made available to fit with our policy, whether that be "all LGPL", or "LGPL preferred" or "each person's preference", ... > 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 . Good. It is a much closer match of problem and solution. Licences tend to be in source files. Anyone, but anyone, wanting to do their own project using our libraries is going to have to go somewhere and look anyway. If they don't check then that's their problem, not ours. That said, part of our job is to make it easy for them to find out this information. So such a "http://linux-ha.org/FileCopyrightPolicy"; URL sounds like a good idea. And sufficient. > It needs less work, but users tend to miss it, and documents > tend to be out of date:-) But an external application developer has to do some check. It is their legal responsibility, and 99.n% of them know that. Our task is simply to make this as straightforward as possible. Your "exception list" sounds good. It means that new things don't get left in limbo. (And the only person who really has to do anything is the person here in linux-ha writing the new thing, who will need to consider this anyway.) > 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. I come back to whether all this is trying to solve a problem in the wrong place. An application developer using binary packages that we provide won't see this. They (and it is _their_ legal responsibility) will need to check something else, somewhere else, anyway. And a simple text document or URL would seem to be appropriate. > 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. Again, isn't this still a mismatch of a mis-perceived issue? They still need to check; the simple file/URL suggested earlier is the appropriate match of problem to solutiuon, isn't it? > 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. Not convinced. The application developer is developing their own application, not ours. If we have done our job correctly, they don't need our source. (When was the last time each of us here trawled the source of "gcc", "glibc", "glib-2.0", ... looking for their licensing?) Summary: 1. An application developer will be aware of the need to check for licensing. (And if they're not, that's their problem, not ours.) 2. We need to sort out our own things anyway. What is our licensing? If there is a choice, then what guidance directs our choice? If there is a choice, we need to be able to document, simply for ourselves, which libraries have which licences. 3. Given that we have documented the licences (see above), we don't need to mis-apply technical fixes (I'll even use the word "kludges") to attempt (and inadequately so) to address licensing issues. My vote is: forget technical kludges. Let's decide a licensing policy, let's commit ourselves to follow it. And let's document that policy for ourselves, and its results for application developers. Hope that helps! -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. : _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
