Re: [Caml-list] License Conditions for OCaml

[Sven <luther@dpt-info.u-strasbg.fr>]

On Fri, Nov 30, 2001 at 08:23:16PM -0700, Richard Stallman wrote:
> People seem to have included me in the middle of a discussion of some
> licensing issue.  The discussion is very abstract, and I can't tell
> what people are arguing about.
> 
> Could someone send me a brief description of the actual scenario?
> Who is doing what to whom?

Well, ...

First i am not a member of the ocaml team, nor am i related to them in any
way, Also i have not really followed the discution of last week, since i was
away at a conference. And it was not i who included you in the discution.

That said, as the debian packager of the ocaml packages, maybe it is my place
to try to keep you current with what is going on, altough i don't know if you
can help here, and what was the mind of the one who included you in this
discution, which was rather rude i think, he could have given more information
about this and informed us also.

Anyway, i will try to resume this as best i could, others may fill in the
things i miss, and again, anything i say here will only be my opinion, and
should not engage anyone other than me.

If you want more information about ocaml, i encourage you to go to the web
site (caml.inria.fr should be a good start). I will not say more than ocaml is
a functional language of the ML family.

Ok, the thing is like this, after having long had a non free licence, the
ocaml team choose to use a dual licencing scheme, choosing the QPl for the
compiler and the LGPL for the runtime library linked with the programs. They
are mostly the sole authors of the stuff, so changing licence don't cause any
problem.

Now, the real problem, is that ocaml is not currently using shared object
files, altough it can use shared C libraries.

The result of this is that object files, separated into .cmi files and .cmo
files, the second on containing the object code, and the first one containing
all the typing information needed to link in the object files. (this is for
the bytecode version, which is arch independent, for the native code version,
which produce asm output, there is the .cmi, the .cmx containign the code, as
well asa .o product also).

Now, as i understood the LGPL, you can statically link a program you do with
this runtime library, which is akin to the libc on a gcc based system,
provided you either :

  1) provide the source code of your app.

  2) provide the object files (.cmo and .cmi) and a way to linking it (a
     makefile i guess)

There may be other possibilities, but these two are the main reasons.

Since ocaml is a compiler suite and a product destined to be widely used by a
lot of people, and even in some proprietary/closed-source/commercial/whatever
products, the first solution cannot always be fullfilled.

There is always the second solution, which in my opinion would be nice, but
still not optimal (well, it works with true arch independent bytecode, but it
will not survive investing in hardware of a different arch, but since most
people use only i386, this may be moot).

Now, the thing that started this thread is that one of the persons finds the
.cmi too much information bearing to be shared. After a private discution i
had with this guy, which i will not report here for privacy reasons, it happen
to be that this guy company is working on some of the leading edge stuff that
i read on the FSF pages, from you or someone else i think, may be one of those
place were open source will not work.

Also, he finds that this may be a bad point for him advocating the use of
ocaml to his collegues and bosses, since the information contained in the .cmi
makes the reverse engineering of the bytecode too easy (his claim, i did not
ever try this kind of stuff, but i guess it makes sense, similar to
stripped/unstripped C code, but with stronger type information).

Since one of the target of ocaml is precisely such people, this raise a
certain amount of problems, together with a wide misunderstanding about what
the LGPL permit or don't permit in the case of static linking.

Now, the upstream authors are aware of this fact, maybe did misunderstood its
impact at the start of the LGPLed licencing, and now may want to change it for
something else, possibly a modified LGPL or something such, and this has
started a huge thread, as you may have seen.

What the authors want, is (i quote) a licence for the runtime library that
allows :

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.

This seems a worthy goal, altough there are various solutions about this.

I understand that there are two reasons for the restriction on static linking,
the first being to give the user of the final program the right to rebuild the
program with a bug fixed version of the runtime library, the other being some
considerations about an unscroupoulous vendor modifying the library and
putting the modification in its work and not the give it back as they should.

I think this limitation is not widely understood and accepted, and also, maybe
in the rather small ocaml community not really such a problem.

Finally, i guess the true solution to this, would be technical, i.e. to enable
dynamic linking in ocaml, and keep the LGPL. But then, i am not doing the
coding, nor have i the time for it, so ...

I hope this quick resume have helped you udnerstand the problem, if you have
other questions, feel free to ask if you have other doubts.

Friendly,

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