caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: monnier+lists.caml/news/@rum.cs.yale.edu, luther@dpt-info.u-strasbg.fr
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] CDK license
Date: Thu, 07 Jun 2001 10:25:40 +0900	[thread overview]
Message-ID: <20010607102540J.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: <5lpuchy5of.fsf@rum.cs.yale.edu>

From: "Stefan Monnier" <monnier+lists.caml/news/@rum.cs.yale.edu>
> >>>>> "Dave" == Dave Berry <Dave@kal.com> writes:
> > I would encourage people to use an X/BSD-like license for code
> > whereever possible.  This license allows anyone to do anything whatsoever
> > with the code, provided that they keep the copyright notice and NO
> > WARRANTY notice.  It saves you all this hassle with determining what is
> > and is not allowed, and which code may be linked or distributed with which
> > other code.
> 
> You seem to be talking about the original BSD license.  Note that in that
> license, the requirement to keep the copyright notice makes it incompatible
> with the GPL license (which is why there is a revised BSD license which
> does away with the "keep the copyright notice" part).

The X license does not contain that clause, so I suppose that by X/BSD
he meant the revised BSD license already, which is certainly the
most free license you can imagine, the next step being public domain.

I also like BSD very much, but using it requires everybody agreeing on
such a free license, while as Sven points out it includes the possibility
of non-cooperative behaviour.
LGPL was choosen for ocamlrun, to specifically forbid this. You can
include the ocaml runtime in an ocaml program, but you cannot make
modifications to it to serve a different purpose without publishing them.
As a result, it is used for everything else in the system, since any
executable will depend on parts of the ocaml runtime anyway.
(If it is switched to BSD someday, I'll certainly switch all my
libraries to BSD also, after checking with contributors. I would honestly
prefer it for simplicity.)

Yet, I think the LGPL is reasonably balanced. It tries to protect the
code itself (which BSD does not really), while not (much) restricting
its use.

The subtle part, as has already been discussed on this list, is
section 6 of the LGPL, about linking, which I reproduce below.
Outside of the problem that the condition may cause incompatibilities
with licenses of other libraries (if they prohibit reverse engineering
for instance), there is a difficulty with changes in the format of
.cmi or .cmx files between versions.
Basically, section 6 says that if you do not publish source code, then
when asked you should provide a link-kit for your program allowing to
rebuild the executable from modified versions of the runtime and
libraries protected by the LGPL.  But since almost every version of
ocaml has a different format for the .cmi, one reading would be that
you have to provide a link-kit for every new version of ocaml. This
seems utterly impractical. Writing it somewhere explicitly might be
useful. Something like: "The work in binary form described in section
6 is to be understood as compiled by a specific version of ocaml. You
are not liable to provide it for other versions." This looks like it
is already included in the provisions about changes in the text of the
interface, but the problem is that incompatibilities can be created
without changing the source code. (By the way I'm sure that nobody
ever produced such a link-kit. But did anybody distribute
closed-source caml software?)

Sven had also concerns with section 5, particularly about the use of
functors understood as derivative work. This may be related to the
problem with templates in C++. However, functors in caml do not imply
recompilation for each use, so I think this is not a problem. There is
also inlining, but ocaml does not do much more inlining than C, for
which it is considered OK. As a result I think that there is no real
need to explicitly say that ocaml linking is to be understood as
linking.

The GNAT approach which Brian presented, of taking the GPL but
allowing linking unconditionally, is more liberal than LGPL, and
avoids these problems.  You don't have to provide a link-kit for your
executable.
This would make things much simpler, but I'm not sure it covers the
original goal of using the GPL: wouldn't it allow one to include
modified versions of the runtime in an executable, without publishing
the changes?

Regards,

Jacques Garrigue

----------
Extract from LGPL version 2

  6. As an exception to the Sections above, you may also compile or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications.

  You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License.  You must supply a copy of this License.  If the work
during execution displays copyright notices, you must include the
copyright notice for the Library among them, as well as a reference
directing the user to the copy of this License.  Also, you must do one
of these things:

    a) Accompany the work with the complete corresponding
    machine-readable source code for the Library including whatever
    changes were used in the work (which must be distributed under
    Sections 1 and 2 above); and, if the work is an executable linked
    with the Library, with the complete machine-readable "work that
    uses the Library", as object code and/or source code, so that the
    user can modify the Library and then relink to produce a modified
    executable containing the modified Library.  (It is understood
    that the user who changes the contents of definitions files in the
    Library will not necessarily be able to recompile the application
    to use the modified definitions.)

    b) Accompany the work with a written offer, valid for at
    least three years, to give the same user the materials
    specified in Subsection 6a, above, for a charge no more
    than the cost of performing this distribution.

    c) If distribution of the work is made by offering access to copy
    from a designated place, offer equivalent access to copy the above
    specified materials from the same place.

    d) Verify that the user has already received a copy of these
    materials or that you have already sent this user a copy.

  For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it.  However, as a special exception,
the source code distributed need not include anything that is normally
distributed (in either source or binary form) with the major
components (compiler, kernel, and so on) of the operating system on
which the executable runs, unless that component itself accompanies
the executable.

  It may happen that this requirement contradicts the license
restrictions of other proprietary libraries that do not normally
accompany the operating system.  Such a contradiction means you cannot
use both them and the Library together in an executable that you
distribute.

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr


  reply	other threads:[~2001-06-07  1:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-06  9:44 Dave Berry
2001-06-06 10:04 ` Sven LUTHER
2001-06-06 15:44 ` Stefan Monnier
2001-06-07  1:25   ` Jacques Garrigue [this message]
2001-06-08 12:59     ` Sven LUTHER
2001-06-07  9:03   ` Joerg Czeranski
  -- strict thread matches above, loose matches on Subject: below --
2001-06-06 10:24 Dave Berry
2001-06-06 16:24 ` Brian Rogoff
2001-06-08 13:27   ` Sven LUTHER
2001-06-08 15:35     ` Brian Rogoff
2001-06-08 13:24 ` Sven LUTHER
2001-05-30 19:06 Brian Rogoff
2001-05-31  1:05 ` rbw3
2001-06-06  7:05   ` Sven LUTHER
2001-06-06  7:42     ` Sven LUTHER
2001-05-31  2:27 ` Jacques Garrigue
2001-05-31  3:11   ` Brian Rogoff
2001-05-31  7:46     ` Fabrice Le Fessant
2001-06-06  7:40     ` Sven LUTHER
2001-06-06  8:36       ` reig
2001-06-06  8:51         ` Sven LUTHER
2001-05-31 22:05 ` John Max Skaller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010607102540J.garrigue@kurims.kyoto-u.ac.jp \
    --to=garrigue@kurims.kyoto-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=luther@dpt-info.u-strasbg.fr \
    --cc=monnier+lists.caml/news/@rum.cs.yale.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).