David Lee wrote:
> 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.
This is not about licensing policies. We have a licensing policy which
has been around for 5 years - and was documented properly about a year ago.
Well... There is a difference between internal and external interfaces.
And there needs to be such a distinction.
Internal interfaces link against GPLed code.
External interfaces link against LGPLed code.
So, it depends on what kind of an interface it is.
So, it makes no sense to make an internal library LGPLed. And, it
defeats what we're trying to do, and would confuse people.
If it's a private interface, then our licensing policy says it should be
GPL. But, for technical reasons we may have internal libraries to
implement internal interfaces (in fact we have lots of them). In many
cases some of our most complex GPLed code is in libraries. One could
imagine having everything but the main be in an internal library.
Most or all of our modules have external interfaces that you can talk to
them through using IPC. All the libraries necessary to talk our form of
IPC are LGPLed. So, if the external (client side) libraries are LGPLed,
then it is legal to use them to talk to the module.
But, there are also libraries used only by the server sides of these
interfaces -- and they implement lots of things that are not intended to
be public. They should NOT be LGPLed - for a variety of reasons -
confusion among them.
Drawing an ASCII art picture, here is how things work:
+---------+---------+--------+ +--------+------------+
| Server |GPLed |Server | | Client |Client |
| code |Internal |IPC code+---IPC---+IPC code|Application |
| GPL |Libraries| GPL | | LGPL |Any License |
+---------+---------+--------+ +--------+------------+
Boxes which butt up against each other are 'linked' together. things
that talk to each other over IPC or a comm link are connected with a line.
And, this is our policy -- and it makes good sense. Unfortunately, it's
a little less simplistic than "all libraries are LGPLed".
This is why I brought this up in the first place.
Regarding your suggestion...
Basically your suggestion would mean "put no code important to us in
protecting our product into any library". Which would then warp our
build structure and technical architecture to the IP policy - which
would definitely not interest me.
--
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/
