Browse thread
Re: [Caml-list] License Conditions for OCaml
- John Field
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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