Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: [Caml-list] License Conditions for OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: John Field <jfield@u...>
Subject: Re: [Caml-list] License Conditions for OCaml
Xavier Leroy wrote:

> 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 of these look great to me.

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

This would certainly appear to meet the objections IBM's lawyers had.

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

No, I don't think the distinction between library and user code was
ambiguous.  The ambiguities I was referring to relate to the requirements
imposed on implementers to accommodate re-linking, and to the rights
it grants to users of the re-linked 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.

Personally, I agree that prohibitions on reverse-engineering are a
waste of time.  On the other hand, the lawyers seem to regard the LGPL
clause that _explictly_ allows reverse-engineering as sort of an
open-ended invitation to mischief.

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

All of their objections were related to the re-linking requirement, so
unless its removal somehow introduced new issues, I would _think_ that
the result would be acceptable.

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

FWIW, I will ask some of my colleagues who have more experience with
open source licenses than I do to see if there might be any other
licenses around (obviously not as commonly-used as the ones above)
that avoid LGPL re-linking problem.

-John

John Field
IBM T.J. Watson Research Center
http://www.research.ibm.com/people/j/jfield

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