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
[Caml-list] Dynamically evaluating OCaml code
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-04-09 (07:37)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] Dynamically evaluating OCaml code
On Fri, 2004-04-09 at 16:33, Remi Vanicat wrote:

> If it is LGPL + special exception (as the stdlib of ocaml) I don't see
> the problem. GPL can be a problem thought.

Not sure of the 'special exception' but my impression is that
whilst one is free to use "as is" an LGPL library by
first compiling it, then linking to it, without polluting
the licence of the code using it, that freedom doesn't
extend to the source itself. If I combine parts of 
the source of a library with my own sources, my sources
are contaminated.

My distro is entirely in 'pre-source' form,
which makes a mockery of the LGPL. 

It isn't clear what happens here:

(* LGPL_client.ml *)
module LGPL.Make(struct type t = int end)

ocamlc -i LGPL_client.ml > LGPL_client.mli

well, is that a 'derived work' covered by LGPL
or is it free for any use?

It sure as heck ain't a compiled binary: LGPL is basically
"unsustainable gobblegook" <g> outside the realm of C programming.
The legal impact would seem to me to be: 
permission for use isn't explicitly
and clearly given, so it doesn't exist.

Ocaml itself isn't a problem: the intent is clear,
the distro is to be trusted (I won't modify it even
if I do find a bug), and there is always an option
of a commercial licence.

I don't feel so trusting of third parties,
and can't expect to require my clients to either.

Actually, GODI will probably help enormously,
by at least imposing some uniformity on the
way in which third party packages are installed,
the potential reduced need to fiddle with a third
party component may provide enough separation
between sources to prevent contamination.

John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners