Re: [Caml-list] License Conditions for OCaml

["Ohad Rodeh" <ORODEH@il.ibm.com>]

There is one long standing issue that I've had with the Caml license. I
have a BSD licensed
system (Ensemble) that uses a non-standard, Caml derived, Unix library. We
call our library "Unix" library Socket,
and it contains various performance hacks and a port to winsock2. The issue
is simple, what is
the license for Socket?  On the one hand, it should be BSD, because we
wrote it, and it is part of
a BSD system. On the other  hand, since it uses some (little) of the Caml
code, it should have an LGPL license.

I really think that that Socket should have a BSD license. One way to solve
this problem would be to make the inner
Unix header file public (i.e., copied to lib/caml/*.h). Our use of the Unix
library sources is to the extent (almost entirely)
of using the header files.

   Any thoughts?
     Ohad.



Xavier Leroy <xavier.leroy@inria.fr>@pauillac.inria.fr on 28/11/2001
20:22:39

Sent by:  owner-caml-list@pauillac.inria.fr


To:   John Field/Watson/IBM@IBMUS
cc:   caml-list@inria.fr
Subject:  Re: [Caml-list] License Conditions for OCaml



John,

Thank you for your feedback -- it's very interesting to hear from an
industrial user who got the opinions of competent lawyers.

Let me just state again what we'd like to achieve concerning the
licensing of the OCaml runtime and libraries:

1- Users can link with it, statically or dynamically, without any
   restrictions on the final program.
2- Users can modify the runtime or the libraries themselves, but then
   must make their modifications public under the same conditions as
   the original source.
3- The license should be standard, OSI-approved, and well known to the
   public that cares about these things.

All three items are easy to justify: for 1, we don't want to bother
anyone who uses OCaml; for 2, we'd like OCaml to remain open
source, meaning that everyone should be able to benefit from the
modifications on OCaml itself that someone did; and for 3, we're not
competent for inventing yet another license and get it recognized as
open source compliant.

Now the problem is that apparently there is no existing license that
matches these three criteria.  The LGPL was chosen before we realized
all its implications w.r.t. static linking.  But popular licenses such
as BSD or X don't meet criterion 2.  Our current hope is that the LGPL
with a special exception to paragraph 6 saying "you can link with our
code any way you like" would fulfill all three requirements.

> IBM's lawyers have lots of experience dissecting the innards of
> various open- and quasi-open source licenses.  They are _very_ wary
> of the LGPL.  I won't attempt to explain or justify all of
> their concerns, some of which I don't fully understand.  However,
> their principal objections were to the clauses of the LGPL allowing
> "reverse engineering" of and "modifications" to the code.  The lawyers
> realize that the _intent_ of these clauses is probably benign.  However,
> the license provisions are so ambiguously worded (as ample discussion
> on this list has demonstrated) that the requirements it imposes on an
> implementer and the rights it grants to a user are very unclear.

Clearly, we want to allow "modifications" to the OCaml code itself
(otherwise it's not open source), but not impose this requirement on
the user code.  Are you saying that the LGPL is sufficiently ambiguous
not to distinguish clearly between library code and user code?

As for "reverse engineering", I don't really care.  If we void
paragraph 6 of the LGPL, the user isn't required to allow reverse
engineering.  Still, commercial licenses that prevent reverse
engineering are silly -- here in the European Union (and in other
countries as well), reverse engineering is explicitly allowed by law
in certain circumstances, so putting such a provision in your license
is just calling for the whole license to be invalidated by a EU court.

(Besides, if I buy, say, a TV set, I can open it and reverse-engineer the
circuit board to my heart's content; I might void the warranty this
way, but I'm not doing anything illegal.  I find it hard to understand
why it should be any different with software.)

> In addition to the legal ambiguities, the provision requiring
> that the code be distributed in a way that allows re-linking of
> the libraries is a major administrative hassle

I fully agree with this.  My proposal is basically to remove this
requirement for the OCaml libraries.

> As a result of the issues above, IBM's general response to
> applications that use LGPL libraries is to require that the
> libraries be dynamically-linked.  Since this wasn't feasible with
> OCaml, we had to distribute the application in bytecode, rather than
> opt-compiled form.

Suppose we remove the re-linking requirement.  Would that be enough to
allow distribution of an ocamlopt-compiled executable in IBM's
lawyers' opinion?

> If the OCaml developers don't feel that the relinking provisions of
> LGPL are important, I would strongly advise adopting an alternative
> license that unambiguously allows static linking of OCaml libraries
> without imposing any additional requirements on the application.

As I said above, the other standard licenses (e.g. BSD, X) don't offer
enough guarantees about the OCaml libraries and runtime themselves
remaining open source.

- Xavier Leroy
-------------------
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



-------------------
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