On Fri, 9 Nov 2001, Patrick M Doane wrote:

> On Thu, 8 Nov 2001, Will Benton wrote:
> 
> > Whoa, nelly!  I don't know that I'd characterize the LGPL as a
> > "problem", but your reading of it is completely off the mark.  The LGPL
> > requires that if you distribute an application linked to a library, that
> > you must allow users to re-link against newer versions of the library
> > that maintain interface compatibility, presumably by providing object
> > files, bytecodes -- OR you must distribute an application that uses
> > shared libraries.  It is C-centric, but I do not think it poses any
> > problems.  (You must also redistribute any changes you make to the
> > LGPLed library itself.)
> 
> OCaml doesn't provide support for shared libraries (although 3.03 does
> provide some dynamic loading capabilities for bytecode only). So we
> need to consider the portions of the license that apply for static
> linking. The LGPL provides some rather contradictory statements in section
> 6 regarding that:
While this is true for stock ocaml, there is a patch that adds shared
linking support to 3.03Alpha, with limited scope though - i386 ELF only.
(shameless plug) You can find it here http://algol.prosalg.no/~malc/scaml

> 
>   1. you may also compile 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.
> 
> This clause is enough to throw out most commercial applications. It is
> standard industry practice to disallow reverse engineering. Most software
> companies are going to resist changing this - and for good reason too.
> 
> Note that the license terms must also permit "modification of the work for
> the customer's own use". I'm not sure of any way to comply with that
> without providing source code.  Object files are certainly not suitable
> for modification by customer use.
> 
>   2. Accompany the work with the complete corresponding machine-readable
>      source code for the Library including whatever changes were used in
>      the work (which must be distributed under Sections 1 and 2 above); and,
>      if the work is an executable linked with the Library, with the complete
>      machine-readable "work that uses the Library", as object code and/or
>      source code, so that the user can modify the Library and then relink
>      to produce a modified executable containing the modified Library.
> 
> Here it suggests that object code is sufficient but this can't be modified
> for the customer's own use. Perhaps this contradiction invalidates this
> section of the license, I don't know. I'm not a lawyer. The only
> reasonable way I see to comply with these two points is to provide source
> code.  Do you have any suggestions on how a user can modify object code
> for their own use?
> 
> These issues aside, the LGPL is still a real pain to deal with.
> 
>   - The LGPL text must be included with the distribution.
>   - All copyright notices for the product need to include the copyright
>     notice for Inria
>   - All these notices must also direct the user to the LPGL license
>   - All source to the INRIA libraries and standard runtime must be
>     included in the distribution. This is particularly annoying for
>     Windows developers because that distribution doesn't come in source
>     form.
>   - All source code (or perhaps object code) for my application must
>     be come with distributed.
>   - Or, as an exception to the previous two, a written letter must be
>     included with the product to be able to get those two.
> 
> This is a lot of hassle - nowhere near the suggestion that "the LGPL puts
> no restrictions at all on programs linked with LGPL-ed binaries."
> 
> There are other license problems as well. In particular, some of the
> libraries distributed with OCaml (like Str) are based on GPL code, but the
> manual does not mention this and it would be very easy for a developer to
> get into trouble because of that.
> 
> I'm sorry if this sounds like just a lot of complaining, but I'm sure
> folks in the commercial world would rather pay a small fee to avoid these
> issues entirely. Ideally, any OCaml executable (with the exception of this
> created with ocamlmktop) should be unencumbered from license issues. I
> believe this was the intent of the INRIA team, but this is not the current
> situation.
> 
> -------------------
> Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
> To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr
> 
> 

-- 
mailto:malc@pulsesoft.com

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr