English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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: 2001-12-06 (12:28)
From: Sven <luther@d...>
Subject: Re: [Caml-list] License Conditions for OCaml
On Wed, Dec 05, 2001 at 07:46:11PM -0700, Richard Stallman wrote:
>     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.

Yes, i understand that, but the whole point of this is that the customer get
the right to use the program he buys, isn't it ?

Suppose he has some hardware which will get discontinued for some reason, like
the alpha case, and has to buy new hardware of some other kind, he cannot
anymore fullfills his right to use the program.

But anyway, this is not the point here, and would be difficult to obtain,
apart from providing full source code of the app.

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

mmm, don't remember, but it was in 98 or 97, a link from the fsf pages, i
think in a faq or a document (maybe even from you, don't remember) that dealt
with reasons to use free software.

IT went on saying that there is no reason, apart from some very leading edge
areas were there is still not widely known innovation hidden in the soruce
code, to not choose to give people access to the source code, or something

But then, maybe i am wrong, and did read it from the open source guys, but the
time frame makes that somewhat unlikely.

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

mmm, but then i suppose the libgcc is not licenced under the LGPL, is it ? 

This may be a good solution, but is such a licencing scheme compatible with
linking with LGPLed or GPLed code ?

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

Yes, i know, i guess this is what was meant here.

Anyway, there is no way you can force someone to release code you don't know
about :)))

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

I guess so.


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