httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <di...@webweaving.org>
Subject Re: GNU Portable Threads (pth)
Date Tue, 06 Jul 1999 07:55:12 GMT


On Mon, 5 Jul 1999, Brian Behlendorf wrote:

As a question; in for example the netherlands, germany or italy, most of
the, academic, discussion quicly centrers on the definition of 'the work',
which unfortunately, when translated literally to either language, as a
perfect equivalent which has a wel defined legal meaning in IPR and so on.

It is this meaning, the fuzzy definition of it, and in part the indent of
the licence as a whole combined with article 6 not countering such, that
makes the 'work' a potential monster gobbling up a lot of IPR.

How is this for US folks. Is it the same sticking point or does it run
deeper ? Because when discussing this in NL, I sometimes feel that part
of this has more to do with a translation issue than with the real point.

Secondly, to add to the confusion, in clause 6, there is a second issue
we, as a dutch company, have had to address recently:

>   As an exception to the Sections above, you may also combine or link a
>   "work that uses the Library" with the Library to produce a work
>   containing portions of the Library, and distribute that _work_ under 
>   terms of your choice, provided that the terms permit modification of
>   the work for the customer's own use and reverse engineering for
>   debugging such

Now the 'work' in the third sentance bring a separate problem in some
countries; you are to ensure that (the terms) permit modification of
the 'work. Assuming that 'the work' refers to the underlined work
in the third sentence, this implies that you really have to give
the customer a fiar chance. I.e. to modify. 

As you are to ensure that any terms in a given contract are reasonable;
and using vi on a binary is propably not reasonable, I am told that this
propably means turning over something more source like.

Again, would such reasoning also hold for the US. I'd like for now to
focus on the US, as that is where the ASF is incorperated, and the issue
is already comlex enough as it is.

DW

> Let's talk about this sanely for a second.
> 
> The LGPL makes a distinction between "a work based on the Library"
> and a "work that uses the Library".  "Work based on the library" is
> defined as:
> 
>   either the Library or any derivative work under copyright law: that is
>   to say, a work containing the Library or a portion of it, either
>   verbatim or with modifications and/or translated straightforwardly into
>   another language. (Hereinafter, translation is included without
>   limitation in the term "modification".) 
> 
> Then it states:
> 
>   The act of running a program using the Library is not restricted.
> 
> By my reading of the LGPL (and Bill, correct me if you think IBM has a
> different opinion), we can have the end-user link Apache against LGPL'd
> libraries.  We can also (separately) distribute an LGPL'd package of all
> the essential LGPL'd libraries Apache would require during compilation,
> even with whatever mods we needed to make for whatever reason, all again
> under the LGPL.
> 
> However, we *have* to treat (Apache & other non-LGPL code) and (LGPL'd
> code) as separate "works" requiring separate distribution.  Where I think
> IBM and other large institutions have a problem is with trusting Stallman
> not to sue them over a differing idea of what a "work" is.  For example,
> if the Apache "configure" program autonomously went to the net to fetch
> the LGPL'd package, without prompt or explicit action from the end-user
> compiling the software, is it still considered a separate "work"?

> One essential sentence:
> 
>   In addition, mere aggregation of another work not based on the Library
>   with the Library (or with a work based on the Library) on a volume of a
>   storage or distribution medium does not bring the other work under the
>   scope of this License."
> 
> Is placing these files in the same .tgz file considered "mere
> aggregation"?  How about the same CVS tree?
> 
> Also note that, if we do decide to distribute a separate LGPL package,
> we'd need to do binary builds of that package, with the resulting
> libraries compiled as .o's, .so's, .dll's, whatever.
> 
> Now, section 6 tries to address this, but as Dirk noted, it has problems.
> For example,
> 
>   As an exception to the Sections above, you may also combine or link a
>   "work that uses the Library" with the Library to produce a work
>   containing portions of the Library, and distribute that work under terms
>   of your choice, provided that the terms permit modification of the work
>   for the customer's own use and reverse engineering for debugging such
>   modifications.
> 
> I would wonder how this would play against a clause which stated that
> customers who modified source code ran the risk of invalidating their
> warranties.   It's also humorous to see
> 
>   If the work during execution displays copyright notices, you must
>   include the copyright notice for the Library among them, as well as a
>   reference directing the user to the copy of this License.
> 
> given Stallman's comments on the advertising clause in the BSD license.
> 
> 6a could also be stretched to mean that source code to the work as a whole
> would need to be provided, and even though that wouldn't mean putting it
> under the LGPL, it would still be an issue for companies who combine
> proprietary code with Apache.
> 
> 6b is a bit more reassuring, though.  It suggests that we might be able to
> include LGPL'd code into the final tarball/binary build, *if* we use
> shared object loading.  
> 
> 
> 
> 
> So, there's the issues as I know them.  If others have any, please bring
> them up.  I think there *is* a way to reconcile the use of LGPL'd
> libraries with the commercial interests lined up behind Apache, although
> it is somewhat inconvenient.  
> 
> 	Brian
> 
> 
> 
> 


Mime
View raw message