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

That is not really an issue.  If you distribute linked executables for
computer X, using an LGPL-covered library, the LGP requires you to
provide your customer with object files for computer X--but not for
any other computer.

    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.

It would be strange if there were such a statement on our web site.
We don't do "open source" and we don't agree with the open source
movement, so the question of whether it will or won't work in a
certain domain is not one we would be very concerned with.  If you
could tell me which page you saw this in, I'd appreciate that.

    1- Users can link with it, statically or dynamically, without any
       restrictions on the final program.

It is easy enough to do that.  That is what we did in the GCC support
library, libgcc, because it consists mainly of many very simple
functions.

    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.

To *require* people to publish modified versions of a program is, in
general, unacceptable for free software--such a requirement would make
the software non-free.

However, to say that *if* the user publishes the modified version he
must do so under a certain license is legitimate.  That is what the
GPL does, for instance.

It is also legitimate in a free software license to require
publication of the modified library source if an executable containing
the modified library is published.  Perhaps they would like to do
this.
-------------------
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