Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane <patrick@watson.org>]

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:

  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