[Caml-list] License Conditions for OCaml

[Caml-list] License Conditions for OCaml

[Patrick M Doane]

Earlier this year there was a discussion about the problems of using LGPL
for the OCaml run-time system and associated libraries.

It was suggested that some of the constraints in the LGPL were not
intended. To quote a page from the Caml website:

  "The LGPL puts no restrictions at all on programs linked with LGPL-ed
libraries. Thus, users are free to distribute (or not) OCaml-generated
binaries under whatever conditions they like."

>From my reading of the LGPL, which seems to correspond with the opinions
of others on the list, this just isn't true.  If I develop an application
with OCaml, I must distribute that application with source code.  This
isn't acceptable for commercial development and I'd really hope that the
intention is for OCaml to be used outside of academia.

Will this problem be fixed for the 3.03 release?

Patrick

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

Re: [Caml-list] License Conditions for OCaml

[Rafael 'Dido' Sevilla]

On Thu, Nov 08, 2001 at 11:30:56PM -0500, Patrick M Doane wrote:
>   "The LGPL puts no restrictions at all on programs linked with LGPL-ed
> libraries. Thus, users are free to distribute (or not) OCaml-generated
> binaries under whatever conditions they like."
> 

Yeah, this is a slightly misleading statement, unless the OCaml
development team has made a modification to the LGPL similar to what was
done for the Guile license, which is LGPL with one additional clause:
blanket linking is allowed for Guile. (OCaml dev team, is this also the
license under which the runtime exists?)

If you read the license, how it works is that if you link *dynamically*
with LGPLed libraries, there are no restrictions on the license of the
linking program.  That means you have to have a shared library version.
If you have a statically linked program, or on some system that doesn't
support shared libraries/DLL's, you are going to be in violation of the
lesser GPL by linking to the static versions of the library.

You do need to distribute source code for the OCaml runtime libraries
though, with any and all modifications you made to those libraries as
well (if any).  But you need not distribute source for those programs
which are linked dynamically to the runtime libraries.  That's why
programs like the Linux Yahoo! Messenger client can get away with
linking to a LGPLed library like GTK+ without revealing their source
code.

-- 
Rafael R. Sevilla <sevillar@team.ph.inter.net>   +63(2)   8177746 ext. 8311
Programmer, Inter.Net Philippines                +63(917) 4458925
http://dido.engr.internet.org.ph/                OpenPGP Key ID: 0x5CDA17D8
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Xavier Leroy]

> Yeah, this is a slightly misleading statement, unless the OCaml
> development team has made a modification to the LGPL similar to what was
> done for the Guile license, which is LGPL with one additional clause:
> blanket linking is allowed for Guile. (OCaml dev team, is this also the
> license under which the runtime exists?)

We haven't yet modified the LGPL to remove these silly restrictions on
linking with LGPL code, but plan to do so in the near future.  

We'd be interested in examples of other software projects that did this.
You mention Guile, however it seems to be under the (standard) GPL
(not even LGPL).

> If you read the license, how it works is that if you link *dynamically*
> with LGPLed libraries, there are no restrictions on the license of the
> linking program.  That means you have to have a shared library version.
> If you have a statically linked program, or on some system that doesn't
> support shared libraries/DLL's, you are going to be in violation of the
> lesser GPL by linking to the static versions of the library.

Not at all.  In case of static linking, the LGPL requires that you
give users the ability to re-link your program with modified versions
of the LGPL-ed library.  In practice, this means that you have to
provide the .cmo or .cmx/.o files for your OCaml program in the
unlikely event that someone asks for them (in order to exercise
his/her LGPL rights of re-linking with modified Caml libraries).

No big deal, really, but still silly.

- Xavier Leroy
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Dave Scott]

On Fri, 9 Nov 2001, Xavier Leroy wrote:

> We haven't yet modified the LGPL to remove these silly restrictions on
> linking with LGPL code, but plan to do so in the near future.  
> 
> We'd be interested in examples of other software projects that did this.
> You mention Guile, however it seems to be under the (standard) GPL
> (not even LGPL).

AT&T's omniORB  ( http://www.uk.research.att.com/omniORB/ ) has a similar
tricky licensing arrangement. The core CORBA library code is LGPL'ed
while the associated tools (including the IDL compiler) are GPL'ed. Since
the IDL compiler emits part of its own source in its output which then 
gets linked statically into all CORBA apps, there is an extra licensing
note covering this (otherwise people might have to GPL all their CORBA
code).

>From the README.FIRST file in the omniORB source distro:

>>>>
omniORB3 is copyright AT&T Laboratories - Cambridge. It is free
software. The programs in omniORB3 are distributed under the GNU
General Public Licence as published by the Free Software Foundation.
See the file COPYING for copying permission of these programs. The
libraries in omniORB3 are distributed under the GNU Library General
Public Licence. See the file COPYING.LIB for copying permission of
these libraries.

We impose no restriction on the use of the IDL compiler output. The
stub code produced by the IDL compiler is not considered a derived
work of it.
<<<<

Not completely the same but nevertheless intersting...

Cheers,
-- 
Dave Scott   --   Lab for Comms Engineering   --   CUED
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[David Brown]

On Fri, Nov 09, 2001 at 09:45:45AM +0100, Xavier Leroy wrote:
> > Yeah, this is a slightly misleading statement, unless the OCaml
> > development team has made a modification to the LGPL similar to what was
> > done for the Guile license, which is LGPL with one additional clause:
> > blanket linking is allowed for Guile. (OCaml dev team, is this also the
> > license under which the runtime exists?)
> 
> We haven't yet modified the LGPL to remove these silly restrictions on
> linking with LGPL code, but plan to do so in the near future.  
> 
> We'd be interested in examples of other software projects that did this.
> You mention Guile, however it seems to be under the (standard) GPL
> (not even LGPL).

This is the license from the runtime of the GNU Ada Compiler.  Note the
special exception.  Also this is GPL, with the exception:

--           Copyright (C) 1995-1998 Ada Core Technologies, Inc.            --
--                                                                          --
-- GNAT is free software;  you can  redistribute it  and/or modify it under --
-- terms of the  GNU General Public License as published  by the Free Soft- --
-- ware  Foundation;  either version 2,  or (at your option) any later ver- --
-- sion.  GNAT is distributed in the hope that it will be useful, but WITH- --
-- OUT ANY WARRANTY;  without even the  implied warranty of MERCHANTABILITY --
-- or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License --
-- for  more details.  You should have  received  a copy of the GNU General --
-- Public License  distributed with GNAT;  see file COPYING.  If not, write --
-- to  the Free Software Foundation,  59 Temple Place - Suite 330,  Boston, --
-- MA 02111-1307, USA.                                                      --
--                                                                          --
-- As a special exception,  if other files  instantiate  generics from this --
-- unit, or you link  this unit with other files  to produce an executable, --
-- this  unit  does not  by itself cause  the resulting  executable  to  be --
-- covered  by the  GNU  General  Public  License.  This exception does not --
-- however invalidate  any other reasons why  the executable file  might be --
-- covered by the  GNU Public License.                                      --

This seems to be working well.  It allows this library to be linked with
programs.  If someone wishes to incorporate the code, however, it
requires the GPL to be followed.

The wording would have to be changed from instantiating generics,
though.

This does also allow modifications.  If the person doing the
modifications also agrees to the exception.

I also believe this exception has been agreed upon by the FSF.

David Brown
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Brian Rogoff]

On Fri, 9 Nov 2001, Xavier Leroy wrote:
> > Yeah, this is a slightly misleading statement, unless the OCaml
> > development team has made a modification to the LGPL similar to what was
> > done for the Guile license, which is LGPL with one additional clause:
> > blanket linking is allowed for Guile. (OCaml dev team, is this also the
> > license under which the runtime exists?)
> 
> We haven't yet modified the LGPL to remove these silly restrictions on
> linking with LGPL code, but plan to do so in the near future.  
> 
> We'd be interested in examples of other software projects that did this.
> You mention Guile, however it seems to be under the (standard) GPL
> (not even LGPL).

GNAT, www.gnat.com, also uses a modified standard GPL. They've been doing
it for a while, and they even have commercial customers. Here's the whole 
damned thing 
--
-- This is free software; you can redistribute it and/or modify it under
-- terms of the GNU General Public License as published by the Free Software
-- Foundation; either version 2, or (at your option) any later version.
-- This software is distributed in the hope that it will be useful, but WITH
-- OUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
-- or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
-- for more details. Free Software Foundation, 59 Temple Place - Suite
-- 330, Boston, MA 02111-1307, USA.
--
-- As a special exception, if other files instantiate generics from this
-- unit, or you link this unit with other files to produce an executable,
-- this unit does not by itself cause the resulting executable to be
-- covered by the GNU General Public License. This exception does not
-- however invalidate any other reasons why the executable file might be
-- covered by the GNU Public License.

Why not just translate Ada jargon to OCaml and swipe this? 

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

Re: [Caml-list] License Conditions for OCaml

[Tom]

I think it is great that enabling more widespread usage is
high on the list of goals of the OCAML project.

As far as I can tell, the GPL license that GNAT is under is 
considerably more restrictive than the LGPL license used by 
OCAML.  Under the GPL license, you cannot incorporate any 
GNAT source code into your code without redistributing your 
code under the terms of the GPL.

Furthermore, I believe Guile is distributed under the terms 
of the GPL (not the LGPL), and that is why it needs a special exemption 
when embedded in some other software system.

As I understand it, no further exemptions should be needed for a system
covered by the LGPL in order to allow its use as part of a
closed-source, proprietary system.  I would recommend consulting
a lawyer before making any changes to the LGPL--it has been carefully
crafted and vetted over many years.  Modifying it risks not only
breaking the protection it attempts to achieve, it may also scare
people away, since nobody will have any experience with what "a modified
LGPL license" actually means.  If you want to enable even more free 
distribution and usage than the LGPL, maybe it's worth considering 
another license that people already understand pretty well, like BSD or X11.

Tom

--- Brian Rogoff <bpr@bpr.best.vwh.net> wrote:
> On Fri, 9 Nov 2001, Xavier Leroy wrote:
> > > Yeah, this is a slightly misleading statement, unless the OCaml
> > > development team has made a modification to the LGPL similar to what was
> > > done for the Guile license, which is LGPL with one additional clause:
> > > blanket linking is allowed for Guile. (OCaml dev team, is this also the
> > > license under which the runtime exists?)
> > 
> > We haven't yet modified the LGPL to remove these silly restrictions on
> > linking with LGPL code, but plan to do so in the near future.  
> > 
> > We'd be interested in examples of other software projects that did this.
> > You mention Guile, however it seems to be under the (standard) GPL
> > (not even LGPL).
> 
> GNAT, www.gnat.com, also uses a modified standard GPL. They've been doing
> it for a while, and they even have commercial customers. Here's the whole 
> damned thing 
> --
> -- This is free software; you can redistribute it and/or modify it under
> -- terms of the GNU General Public License as published by the Free Software
> -- Foundation; either version 2, or (at your option) any later version.
> -- This software is distributed in the hope that it will be useful, but WITH
> -- OUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> -- or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
> -- for more details. Free Software Foundation, 59 Temple Place - Suite
> -- 330, Boston, MA 02111-1307, USA.
> --
> -- As a special exception, if other files instantiate generics from this
> -- unit, or you link this unit with other files to produce an executable,
> -- this unit does not by itself cause the resulting executable to be
> -- covered by the GNU General Public License. This exception does not
> -- however invalidate any other reasons why the executable file might be
> -- covered by the GNU Public License.
> 
> Why not just translate Ada jargon to OCaml and swipe this? 
> 
> -- Brian
> -------------------
> 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


__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[David Brown]

On Mon, Nov 12, 2001 at 12:07:42AM -0800, Tom wrote:
> I think it is great that enabling more widespread usage is
> high on the list of goals of the OCAML project.
> 
> As far as I can tell, the GPL license that GNAT is under is 
> considerably more restrictive than the LGPL license used by 
> OCAML.  Under the GPL license, you cannot incorporate any 
> GNAT source code into your code without redistributing your 
> code under the terms of the GPL.

Neither license will allow you to incorporate code from the library into
your code and distribute it without being covered under the GPL (or
LGPL).  The issue is how easy is it to _use_ the library in another
program.

The GNAT license allows executables to be freely made that use the
library though.  The LGPL does not allow this.  There is an extra burden
on the developer to make sure that users have the ability to change the
library.

For example:  Let's say I write a proprietary program foo and wish to
distribute it to my customers.  If the ocaml library is LGPL, I have to
distribute at least a .cma (or .cmxa) for my application so that the
recipient of my software can relink it with the library.

With the GNAT modified library, I can just distribute my program.  I
don't need to provide source, that is up to me.

It really is a matter of what Inria wants people to be able to do.

Dave Brown
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Will Benton]

> [...]
> >From my reading of the LGPL, which seems to correspond with the opinions
> of others on the list, this just isn't true.  If I develop an application
> with OCaml, I must distribute that application with source code.

Whoa, nelly!  I don't know that I'd characterize the LGPL as a
"problem", but your reading of it is completely off the mark.  The LGPL
requires that if you distribute an application linked to a library, that
you must allow users to re-link against newer versions of the library
that maintain interface compatibility, presumably by providing object
files, bytecodes -- OR you must distribute an application that uses
shared libraries.  It is C-centric, but I do not think it poses any
problems.  (You must also redistribute any changes you make to the
LGPLed library itself.)
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane]

On Thu, 8 Nov 2001, Will Benton wrote:

> Whoa, nelly!  I don't know that I'd characterize the LGPL as a
> "problem", but your reading of it is completely off the mark.  The LGPL
> requires that if you distribute an application linked to a library, that
> you must allow users to re-link against newer versions of the library
> that maintain interface compatibility, presumably by providing object
> files, bytecodes -- OR you must distribute an application that uses
> shared libraries.  It is C-centric, but I do not think it poses any
> problems.  (You must also redistribute any changes you make to the
> LGPLed library itself.)

OCaml doesn't provide support for shared libraries (although 3.03 does
provide some dynamic loading capabilities for bytecode only). So we
need to consider the portions of the license that apply for static
linking. The LGPL provides some rather contradictory statements in section
6 regarding that:

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

This clause is enough to throw out most commercial applications. It is
standard industry practice to disallow reverse engineering. Most software
companies are going to resist changing this - and for good reason too.

Note that the license terms must also permit "modification of the work for
the customer's own use". I'm not sure of any way to comply with that
without providing source code.  Object files are certainly not suitable
for modification by customer use.

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

Here it suggests that object code is sufficient but this can't be modified
for the customer's own use. Perhaps this contradiction invalidates this
section of the license, I don't know. I'm not a lawyer. The only
reasonable way I see to comply with these two points is to provide source
code.  Do you have any suggestions on how a user can modify object code
for their own use?

These issues aside, the LGPL is still a real pain to deal with.

  - The LGPL text must be included with the distribution.
  - All copyright notices for the product need to include the copyright
    notice for Inria
  - All these notices must also direct the user to the LPGL license
  - All source to the INRIA libraries and standard runtime must be
    included in the distribution. This is particularly annoying for
    Windows developers because that distribution doesn't come in source
    form.
  - All source code (or perhaps object code) for my application must
    be come with distributed.
  - Or, as an exception to the previous two, a written letter must be
    included with the product to be able to get those two.

This is a lot of hassle - nowhere near the suggestion that "the LGPL puts
no restrictions at all on programs linked with LGPL-ed binaries."

There are other license problems as well. In particular, some of the
libraries distributed with OCaml (like Str) are based on GPL code, but the
manual does not mention this and it would be very easy for a developer to
get into trouble because of that.

I'm sorry if this sounds like just a lot of complaining, but I'm sure
folks in the commercial world would rather pay a small fee to avoid these
issues entirely. Ideally, any OCaml executable (with the exception of this
created with ocamlmktop) should be unencumbered from license issues. I
believe this was the intent of the INRIA team, but this is not the current
situation.

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

Re: [Caml-list] License Conditions for OCaml

[Michael Welsh Duggan]

Patrick M Doane <patrick@watson.org> writes:

> OCaml doesn't provide support for shared libraries (although 3.03 does
> provide some dynamic loading capabilities for bytecode only). So we
> need to consider the portions of the license that apply for static
> linking. The LGPL provides some rather contradictory statements in section
> 6 regarding that:
>
>   1. 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.
>
> This clause is enough to throw out most commercial applications. It is
> standard industry practice to disallow reverse engineering. Most software
> companies are going to resist changing this - and for good reason too.

That is section 1.  Section 6 begins, "as an exception to the
Sections above"...

-- 
Michael Duggan
(md5i@cs.cmu.edu)
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane]

On Fri, 9 Nov 2001, Michael Welsh Duggan wrote:

> Patrick M Doane <patrick@watson.org> writes:
>
> > OCaml doesn't provide support for shared libraries (although 3.03 does
> > provide some dynamic loading capabilities for bytecode only). So we
> > need to consider the portions of the license that apply for static
> > linking. The LGPL provides some rather contradictory statements in section
> > 6 regarding that:
> >
> >   1. 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.
> >
> > This clause is enough to throw out most commercial applications. It is
> > standard industry practice to disallow reverse engineering. Most software
> > companies are going to resist changing this - and for good reason too.
>
> That is section 1.  Section 6 begins, "as an exception to the
> Sections above"...

It's section 6. I extracted two sections from it (that I labeled 1 and 2).

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

Re: [Caml-list] License Conditions for OCaml

[Sven]

On Fri, Nov 09, 2001 at 12:58:30AM -0500, Patrick M Doane wrote:
> On Fri, 9 Nov 2001, Michael Welsh Duggan wrote:
> 
> > Patrick M Doane <patrick@watson.org> writes:
> >
> > > OCaml doesn't provide support for shared libraries (although 3.03 does
> > > provide some dynamic loading capabilities for bytecode only). So we
> > > need to consider the portions of the license that apply for static
> > > linking. The LGPL provides some rather contradictory statements in section
> > > 6 regarding that:
> > >
> > >   1. 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.
> > >
> > > This clause is enough to throw out most commercial applications. It is
> > > standard industry practice to disallow reverse engineering. Most software
> > > companies are going to resist changing this - and for good reason too.
> >
> > That is section 1.  Section 6 begins, "as an exception to the
> > Sections above"...
> 
> It's section 6. I extracted two sections from it (that I labeled 1 and 2).

But apparently without reading it indepth, or at least understanding what it
trully says.

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

Re: [Caml-list] License Conditions for OCaml

[Julian Assange]

All this legalise is very interesting, but in the end, as with all legalise
there is only one important issue:

     a) Who has the motivation, resources and standing to fuck with you?

Hint: it's not INRIA.

--
 Julian Assange        |If you want to build a ship, don't drum up people
                       |together to collect wood or assign them tasks and
 proff@iq.org          |work, but rather teach them to long for the endless
 proff@gnu.ai.mit.edu  |immensity of the sea. -- Antoine de Saint Exupery
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Sven]

On Fri, Nov 09, 2001 at 08:58:29PM +1100, Julian Assange wrote:
> 
> All this legalise is very interesting, but in the end, as with all legalise
> there is only one important issue:
> 
>      a) Who has the motivation, resources and standing to fuck with you?
> 
> Hint: it's not INRIA.
> 

But still (i have not looked at it) in the case of the str code, if it trully
uses GPLed code, which may be copyrigthed by the FSF, it may cause a problem,
since they would be much more willing to take actions, if it is ported to
their attention.

That said, i have not looked at this code directly, and it may not be a
problem.

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

Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane]

On Fri, 9 Nov 2001, Julian Assange wrote:

>
> All this legalise is very interesting, but in the end, as with all legalise
> there is only one important issue:
>
>      a) Who has the motivation, resources and standing to fuck with you?
>
> Hint: it's not INRIA.

The issue of morality is very important to me and cannot be ignored.
Besides, the FSF has plenty of motivation and resources.

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

Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane]

On Fri, 9 Nov 2001, Sven wrote:

> On Fri, Nov 09, 2001 at 12:58:30AM -0500, Patrick M Doane wrote:
> > It's section 6. I extracted two sections from it (that I labeled 1 and 2).
>
> But apparently without reading it indepth, or at least understanding what it
> trully says.

Making assumptions like this is really inappropriate. I have read the LGPL
carefully in hopes that it would not be so restrictive.

I believe there is legitimate confusion in the license as to whether
object code is sufficient. Either way, including object code is still too
much to ask for.

Patrick

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

Re: [Caml-list] License Conditions for OCaml

[Sven]

On Fri, Nov 09, 2001 at 12:35:11AM -0500, Patrick M Doane wrote:
> OCaml doesn't provide support for shared libraries (although 3.03 does
> provide some dynamic loading capabilities for bytecode only). So we
> need to consider the portions of the license that apply for static
> linking. The LGPL provides some rather contradictory statements in section
> 6 regarding that:
> 
>   1. 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.

And you didn't read the part about providing the object files instead of the
source, didn't you ?

The real problem is that the GPL and LGPL are long, with lot of legalese
things, and difficult to understand in a fast glance, maybe we should prepare
a small ocaml and LPGL faq or something such. That said, any legal document
would cause the same problems, i think.

> This clause is enough to throw out most commercial applications. It is
> standard industry practice to disallow reverse engineering. Most software
> companies are going to resist changing this - and for good reason too.

Sure, but there is another clause below which lift these problems.

> Note that the license terms must also permit "modification of the work for
> the customer's own use". I'm not sure of any way to comply with that
> without providing source code.  Object files are certainly not suitable
> for modification by customer use.

The work being the ocaml runtime system in this case.

And the object files provided permit you to relink the your app with the
modified ocaml runtime system.

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

Here is all you need to know about it, it says it quite clearly, you have to
provide the object files, so that your client can rebuild your app with a
modified version of the Library, that is the ocaml runtime.

What's the problem with that ?

> Here it suggests that object code is sufficient but this can't be modified
> for the customer's own use. Perhaps this contradiction invalidates this
> section of the license, I don't know. I'm not a lawyer. The only
> reasonable way I see to comply with these two points is to provide source
> code.  Do you have any suggestions on how a user can modify object code
> for their own use?


No, the customer need to be able to modify the ocaml runtime, not your code,
and he can do that if you provide the object files.

If you don't provide the object files, the user cannot modify the ocaml
runtime, as the LGPL allows him, and as thus you take this right from him.

> These issues aside, the LGPL is still a real pain to deal with.
> 
>   - The LGPL text must be included with the distribution.

Well, yes, this is normal, what is the problem with that ? It is just a
relatively small text file, and any commercial distribution comes with it's
licence and licence of their subparts, is that not so ?

That said, you could well move all the needed object files and this licence
into a subdirectory, and no more worry about it.

>   - All copyright notices for the product need to include the copyright
>     notice for Inria

mmm, don't know about this, but it is no more than a line saying that :

This sotware includes code from ocaml dcopyrighted by inria and licenced under
the LPGL.

Or something such, what is so difficult about it ? This is a standard legal
requirement for other stuff, or do you wish to not give proper credit to the
ocam lteam and inria ?

>   - All these notices must also direct the user to the LPGL license

Complied by the above small phrase.

>   - All source to the INRIA libraries and standard runtime must be
>     included in the distribution. This is particularly annoying for
>     Windows developers because that distribution doesn't come in source
>     form.

Huh ? Are you sure, i would have to read again, but i don't think it says
this, What you may need though, is to give a link to a place were it can be
downloaded, something like adding 'which can be downloaded from
ftp.inria.fr.' to the above phrase would be enough to comply with this, or
maybe just a redirection to the caml web pages.

>   - All source code (or perhaps object code) for my application must
>     be come with distributed.

Object code only, this you cannot avoid.

>   - Or, as an exception to the previous two, a written letter must be
>     included with the product to be able to get those two.

Yes, you must inform your client of their right, and this offer has to be up
for at least the next 3 years.

> This is a lot of hassle - nowhere near the suggestion that "the LGPL puts
> no restrictions at all on programs linked with LGPL-ed binaries."

Yes, a little FAQ could be written to clarify this, i would gladly do it, but
next week, when i have more time.

> There are other license problems as well. In particular, some of the
> libraries distributed with OCaml (like Str) are based on GPL code, but the
> manual does not mention this and it would be very easy for a developer to
> get into trouble because of that.

Only if the authors sue them.

Do you really think the ocaml team or xavier, or whoever will sue you for
using ocaml ?

> I'm sorry if this sounds like just a lot of complaining, but I'm sure
> folks in the commercial world would rather pay a small fee to avoid these
> issues entirely. Ideally, any OCaml executable (with the exception of this
> created with ocamlmktop) should be unencumbered from license issues. I
> believe this was the intent of the INRIA team, but this is not the current
> situation.

Please, do you still feel so with these clarifications, i am sure you can find
a compromise with INRIA, maybe against a small fee or a consortium membership,
and they can provide you with a version of ocaml licenced another way. It will
not solve the GPled str problem, if it really is so, though.

But then, maybe these clarificatiosn are enough ?

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

Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane]

On Fri, 9 Nov 2001, Sven wrote:

> On Fri, Nov 09, 2001 at 12:35:11AM -0500, Patrick M Doane wrote:
> > OCaml doesn't provide support for shared libraries (although 3.03 does
> > provide some dynamic loading capabilities for bytecode only). So we
> > need to consider the portions of the license that apply for static
> > linking. The LGPL provides some rather contradictory statements in section
> > 6 regarding that:
> >
> >   1. 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.
>
> And you didn't read the part about providing the object files instead of the
> source, didn't you ?

Yes, I refer to that below - and it is in contradiction with this
paragraph. It's not listed as an exception so I don't know what that means
in legal terms. The most conservative answer is that I must do what can
support both clauses - that is to provide source.

> The real problem is that the GPL and LGPL are long, with lot of legalese
> things, and difficult to understand in a fast glance, maybe we should prepare
> a small ocaml and LPGL faq or something such. That said, any legal document
> would cause the same problems, i think.

Hmm... I doubt anyone would be complaining if this were released with the
MIT License. That is much simpler to understand.

> > This clause is enough to throw out most commercial applications. It is
> > standard industry practice to disallow reverse engineering. Most software
> > companies are going to resist changing this - and for good reason too.
>
> Sure, but there is another clause below which lift these problems.

Where?

> > Note that the license terms must also permit "modification of the work for
> > the customer's own use". I'm not sure of any way to comply with that
> > without providing source code.  Object files are certainly not suitable
> > for modification by customer use.
>
> The work being the ocaml runtime system in this case.

No, that is the library. The first sentence of section 6 reads "you may
compile or a link a 'work that uses the Library'" so it is clear that
'work' refers to my application.

> >   2. 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.
>
> Here is all you need to know about it, it says it quite clearly, you have to
> provide the object files, so that your client can rebuild your app with a
> modified version of the Library, that is the ocaml runtime.
>
> What's the problem with that ?

It contradicts what is said earlier - that the user must be able to modify
the "work".

> > Here it suggests that object code is sufficient but this can't be modified
> > for the customer's own use. Perhaps this contradiction invalidates this
> > section of the license, I don't know. I'm not a lawyer. The only
> > reasonable way I see to comply with these two points is to provide source
> > code.  Do you have any suggestions on how a user can modify object code
> > for their own use?
>
>
> No, the customer need to be able to modify the ocaml runtime, not your code,
> and he can do that if you provide the object files.

This might very well be the intent of the LPGL but it clearly says that
the customer must be able to modify my work, not the ocaml runtime.

> If you don't provide the object files, the user cannot modify the ocaml
> runtime, as the LGPL allows him, and as thus you take this right from him.

Of course the user can modify the ocaml runtime - there is the question as
to whether the user can modify it and relink it with my application.

But the object files expose too much proprietary information. The .cmi
files include the names of identifiers plus their types. Even the
identifiers alone are too much.

> > These issues aside, the LGPL is still a real pain to deal with.
> >
> >   - The LGPL text must be included with the distribution.
>
> Well, yes, this is normal, what is the problem with that ? It is just a
> relatively small text file, and any commercial distribution comes with it's
> licence and licence of their subparts, is that not so ?
>
> That said, you could well move all the needed object files and this licence
> into a subdirectory, and no more worry about it.

Sure, this isn't unworkable, my point is that there are things that a user
of OCaml has to do when shipping an executable. Most compilers I've worked
with in the past don't have these kinds of restrictions. You build your
binary and ship it.

> >   - All copyright notices for the product need to include the copyright
> >     notice for Inria
>
> mmm, don't know about this, but it is no more than a line saying that :

>From section 6: "If the work during execution displays copyright notices,
you must include the copyright notice for the Library among them"

> This sotware includes code from ocaml dcopyrighted by inria and licenced under
> the LPGL.
>
> Or something such, what is so difficult about it ? This is a standard legal
> requirement for other stuff, or do you wish to not give proper credit to the
> ocam lteam and inria ?

I never said that it's difficult. I'm just listing what the requirements
of the LGPL are.


> >   - All source to the INRIA libraries and standard runtime must be
> >     included in the distribution. This is particularly annoying for
> >     Windows developers because that distribution doesn't come in source
> >     form.
>
> Huh ? Are you sure, i would have to read again, but i don't think it says
> this, What you may need though, is to give a link to a place were it can be
> downloaded, something like adding 'which can be downloaded from
> ftp.inria.fr.' to the above phrase would be enough to comply with this, or
> maybe just a redirection to the caml web pages.

>From section 6: "Accompany the work with the complete corresponding
machine-readable source code for the Library including whatever changes
were used in the work"

> >   - All source code (or perhaps object code) for my application must
> >     be come with distributed.
>
> Object code only, this you cannot avoid.

I can avoid this with another license - and this is the problem with the
LPGL.

> > There are other license problems as well. In particular, some of the
> > libraries distributed with OCaml (like Str) are based on GPL code, but the
> > manual does not mention this and it would be very easy for a developer to
> > get into trouble because of that.
>
> Only if the authors sue them.

They are still breaking a license regardless of whether the authors sue
them.

> Do you really think the ocaml team or xavier, or whoever will sue you for
> using ocaml ?

No, but they didn't write the regexp package. I certainly believe the FSF
would *love* to do this.

> Please, do you still feel so with these clarifications, i am sure you
> can find a compromise with INRIA, maybe against a small fee or a
> consortium membership, and they can provide you with a version of
> ocaml licenced another way. It will not solve the GPled str problem,
> if it really is so, though.
>
> But then, maybe these clarificatiosn are enough ?

The license is reasonable when delivering a stripped static binary is
sufficent. Additional clauses like giving credit to INRIA are perfectly
acceptable but it's very important to be able to take reasonable steps to
protecting proprietary information.

I can tell you that if I had access to the .cmi file for a competitors
product, it would be very easy to steal their code.  The implementation
hardly matters here. Giving away the names of identifiers and their
corresponding types is so much information. They are in no position to
protect their work because they must allow me to reverse engineer it.

Patrick

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

Re: [Caml-list] License Conditions for OCaml

[Tom]

> > >   1. 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.
> >
> Yes, I refer to that below - and it is in contradiction with this
> paragraph. It's not listed as an exception so I don't know what that means
> in legal terms. The most conservative answer is that I must do what can
> support both clauses - that is to provide source.

I believe in this case "supporting modifications" refers to letting end users
modify the binary; the way I understand it, it's not an obligation to provide
source.

Tom.


__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Sven]

On Fri, Nov 09, 2001 at 10:33:02AM -0500, Patrick M Doane wrote:
> > The real problem is that the GPL and LGPL are long, with lot of legalese
> > things, and difficult to understand in a fast glance, maybe we should prepare
> > a small ocaml and LPGL faq or something such. That said, any legal document
> > would cause the same problems, i think.
> 
> Hmm... I doubt anyone would be complaining if this were released with the
> MIT License. That is much simpler to understand.

I am not sure, in my opinion the GPL/LGPL is better, since it ensures that
people don't take the code without giving anything back.

I am sure it is nicer to people wanting to use it and sell things, but not to
people writing the code you use. In any case, i guess your company has enough
ressources, that they could negotiate a more traditionnaly licenced version of
ocaml if they whish to.

That said, you cannot link with other usefull GPL/LGPLed stuff then, and i
doubt you will ever convince the FSF or other such to relicence their code.

> > > This clause is enough to throw out most commercial applications. It is
> > > standard industry practice to disallow reverse engineering. Most software
> > > companies are going to resist changing this - and for good reason too.
> >
> > Sure, but there is another clause below which lift these problems.
> 
> Where?

The one you said was incompatible, it is not.

> > > Note that the license terms must also permit "modification of the work for
> > > the customer's own use". I'm not sure of any way to comply with that
> > > without providing source code.  Object files are certainly not suitable
> > > for modification by customer use.
> >
> > The work being the ocaml runtime system in this case.
> 
> No, that is the library. The first sentence of section 6 reads "you may
> compile or a link a 'work that uses the Library'" so it is clear that
> 'work' refers to my application.

I must look, but again, from previous discution on the debian-legal list, and
reading of the FSF GPL/LGPL FAQ, i belive this is not so.

> > >   2. 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.
> >
> > Here is all you need to know about it, it says it quite clearly, you have to
> > provide the object files, so that your client can rebuild your app with a
> > modified version of the Library, that is the ocaml runtime.
> >
> > What's the problem with that ?
> 
> It contradicts what is said earlier - that the user must be able to modify
> the "work".

In section 6, you read, at the end of the second paragraph :

directing the user to the copy of this License.  Also, you must do one
of these things:

followed by :

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

here, you clearly see that :

  o you need to acompany the complete machine readable source code for the
    library (ocaml runtime) => note, this can be a link to a place were you
    can find it.

  o  and, if the work (your programm) 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 (the ocaml runtime) and then relink to
    produce a modified executable containing the modified Library.

e > > Here it suggests that object code is sufficient but this can't be modified
> > > for the customer's own use. Perhaps this contradiction invalidates this
> > > section of the license, I don't know. I'm not a lawyer. The only
> > > reasonable way I see to comply with these two points is to provide source
> > > code.  Do you have any suggestions on how a user can modify object code
> > > for their own use?
> >
> >
> > No, the customer need to be able to modify the ocaml runtime, not your code,
> > and he can do that if you provide the object files.
> 
> This might very well be the intent of the LPGL but it clearly says that
> the customer must be able to modify my work, not the ocaml runtime.

Please consult your firm's lawyer about it, or search advice from the FSF, but
that is what is meant in legalese terms, and if it is not so, i am sure the
FSF may be very happy with you finding a problem with their licences and
modify it acordyingly.

> > If you don't provide the object files, the user cannot modify the ocaml
> > runtime, as the LGPL allows him, and as thus you take this right from him.
> 
> Of course the user can modify the ocaml runtime - there is the question as
> to whether the user can modify it and relink it with my application.

What good will it do him if he can correct a bug in the ocaml runtime, but not
in the version of the runtime that is already linked to your app ?

> But the object files expose too much proprietary information. The .cmi
> files include the names of identifiers plus their types. Even the
> identifiers alone are too much.

Mmm, this is something Xavier or others from the ocaml team should respond to,
But i think someone able to reverse engineer the .cmi, is also more than
likely to be able to reverse engineer the asm code as well. Maybe even more
likely ?

> > > These issues aside, the LGPL is still a real pain to deal with.
> > >
> > >   - The LGPL text must be included with the distribution.
> >
> > Well, yes, this is normal, what is the problem with that ? It is just a
> > relatively small text file, and any commercial distribution comes with it's
> > licence and licence of their subparts, is that not so ?
> >
> > That said, you could well move all the needed object files and this licence
> > into a subdirectory, and no more worry about it.
> 
> Sure, this isn't unworkable, my point is that there are things that a user
> of OCaml has to do when shipping an executable. Most compilers I've worked
> with in the past don't have these kinds of restrictions. You build your
> binary and ship it.

Well, the problem is not with the compilers, but with the support libraries, i
am sure you have the same problem when linking with the libc on linux systems,
which is also LGPLed, i think.

> > >   - All copyright notices for the product need to include the copyright
> > >     notice for Inria
> >
> > mmm, don't know about this, but it is no more than a line saying that :
> 
> >From section 6: "If the work during execution displays copyright notices,
> you must include the copyright notice for the Library among them"
> 
> > This sotware includes code from ocaml dcopyrighted by inria and licenced under
> > the LPGL.
> >
> > Or something such, what is so difficult about it ? This is a standard legal
> > requirement for other stuff, or do you wish to not give proper credit to the
> > ocam lteam and inria ?
> 
> I never said that it's difficult. I'm just listing what the requirements
> of the LGPL are.
> 
> 
> > >   - All source to the INRIA libraries and standard runtime must be
> > >     included in the distribution. This is particularly annoying for
> > >     Windows developers because that distribution doesn't come in source
> > >     form.
> >
> > Huh ? Are you sure, i would have to read again, but i don't think it says
> > this, What you may need though, is to give a link to a place were it can be
> > downloaded, something like adding 'which can be downloaded from
> > ftp.inria.fr.' to the above phrase would be enough to comply with this, or
> > maybe just a redirection to the caml web pages.
> 
> >From section 6: "Accompany the work with the complete corresponding
> machine-readable source code for the Library including whatever changes
> were used in the work"

Sur, but you could go also with :

    c) 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.
or
    d) 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.
or
    e) Verify that the user has already received a copy of these
    materials or that you have already sent this user a copy.

> > >   - All source code (or perhaps object code) for my application must
> > >     be come with distributed.
> >
> > Object code only, this you cannot avoid.
> 
> I can avoid this with another license - and this is the problem with the
> LPGL.

Yes, but is it really a problem, and you don't even need to provide it with
your app, just offer to make it available as per d) above for example ? Most
people would not care anyway.

> > > There are other license problems as well. In particular, some of the
> > > libraries distributed with OCaml (like Str) are based on GPL code, but the
> > > manual does not mention this and it would be very easy for a developer to
> > > get into trouble because of that.
> >
> > Only if the authors sue them.
> 
> They are still breaking a license regardless of whether the authors sue
> them.

Who is not breaking licences, how comes there are so many cross licencing
agreement all over the industry ? Because people are breaking licences all
over the place, and need to tidy up afterward.

> > Do you really think the ocaml team or xavier, or whoever will sue you for
> > using ocaml ?
> 
> No, but they didn't write the regexp package. I certainly believe the FSF
> would *love* to do this.

But, isn't the regexp code linked dynamically ?

> > Please, do you still feel so with these clarifications, i am sure you
> > can find a compromise with INRIA, maybe against a small fee or a
> > consortium membership, and they can provide you with a version of
> > ocaml licenced another way. It will not solve the GPled str problem,
> > if it really is so, though.
> >
> > But then, maybe these clarificatiosn are enough ?
> 
> The license is reasonable when delivering a stripped static binary is
> sufficent. Additional clauses like giving credit to INRIA are perfectly
> acceptable but it's very important to be able to take reasonable steps to
> protecting proprietary information.

And striping your client with the reasonable assurance of a bug free app, even
if your company goes broke or the source code is lost in a disk crash or a
terrorist attack on your firm ?

> I can tell you that if I had access to the .cmi file for a competitors
> product, it would be very easy to steal their code.  The implementation

and you can't from the plain asm code ?

> hardly matters here. Giving away the names of identifiers and their
> corresponding types is so much information. They are in no position to
> protect their work because they must allow me to reverse engineer it.

Again, if this is so important to you, your firm surely has the ressources to
reach another argument with INRIA and the ocaml team with regard to licences,
isn't it ?

I am still curious about what kind of code you really developp, the opensource
theory is that such protectionnism is only applicable to domains of very
leading edge technology, which are not all that numerous still today.

And that often you save more by having people with access to the source code
helping you debugging your products, than by doing it yourself. That said, i
am not sure this argument is as valid for ocaml than it is for C.

But i think we are repeating ourself here, and maybe we are boring a whole lot
of peoples on this list, so we may better take this offlist into personal mail
?

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

Re: [Caml-list] License Conditions for OCaml

[malc]

On Fri, 9 Nov 2001, Patrick M Doane wrote:

> On Thu, 8 Nov 2001, Will Benton wrote:
> 
> > Whoa, nelly!  I don't know that I'd characterize the LGPL as a
> > "problem", but your reading of it is completely off the mark.  The LGPL
> > requires that if you distribute an application linked to a library, that
> > you must allow users to re-link against newer versions of the library
> > that maintain interface compatibility, presumably by providing object
> > files, bytecodes -- OR you must distribute an application that uses
> > shared libraries.  It is C-centric, but I do not think it poses any
> > problems.  (You must also redistribute any changes you make to the
> > LGPLed library itself.)
> 
> OCaml doesn't provide support for shared libraries (although 3.03 does
> provide some dynamic loading capabilities for bytecode only). So we
> need to consider the portions of the license that apply for static
> linking. The LGPL provides some rather contradictory statements in section
> 6 regarding that:
While this is true for stock ocaml, there is a patch that adds shared
linking support to 3.03Alpha, with limited scope though - i386 ELF only.
(shameless plug) You can find it here http://algol.prosalg.no/~malc/scaml

> 
>   1. 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.
> 
> This clause is enough to throw out most commercial applications. It is
> standard industry practice to disallow reverse engineering. Most software
> companies are going to resist changing this - and for good reason too.
> 
> Note that the license terms must also permit "modification of the work for
> the customer's own use". I'm not sure of any way to comply with that
> without providing source code.  Object files are certainly not suitable
> for modification by customer use.
> 
>   2. 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.
> 
> Here it suggests that object code is sufficient but this can't be modified
> for the customer's own use. Perhaps this contradiction invalidates this
> section of the license, I don't know. I'm not a lawyer. The only
> reasonable way I see to comply with these two points is to provide source
> code.  Do you have any suggestions on how a user can modify object code
> for their own use?
> 
> These issues aside, the LGPL is still a real pain to deal with.
> 
>   - The LGPL text must be included with the distribution.
>   - All copyright notices for the product need to include the copyright
>     notice for Inria
>   - All these notices must also direct the user to the LPGL license
>   - All source to the INRIA libraries and standard runtime must be
>     included in the distribution. This is particularly annoying for
>     Windows developers because that distribution doesn't come in source
>     form.
>   - All source code (or perhaps object code) for my application must
>     be come with distributed.
>   - Or, as an exception to the previous two, a written letter must be
>     included with the product to be able to get those two.
> 
> This is a lot of hassle - nowhere near the suggestion that "the LGPL puts
> no restrictions at all on programs linked with LGPL-ed binaries."
> 
> There are other license problems as well. In particular, some of the
> libraries distributed with OCaml (like Str) are based on GPL code, but the
> manual does not mention this and it would be very easy for a developer to
> get into trouble because of that.
> 
> I'm sorry if this sounds like just a lot of complaining, but I'm sure
> folks in the commercial world would rather pay a small fee to avoid these
> issues entirely. Ideally, any OCaml executable (with the exception of this
> created with ocamlmktop) should be unencumbered from license issues. I
> believe this was the intent of the INRIA team, but this is not the current
> situation.
> 
> -------------------
> 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
> 
> 

-- 
mailto:malc@pulsesoft.com

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

[Caml-list] ELF i386 dynamic linking patch. was: License Conditions for OCaml

[Jeff Henrikson]

> > OCaml doesn't provide support for shared libraries (although 3.03 does
> > provide some dynamic loading capabilities for bytecode only). So we
> > need to consider the portions of the license that apply for static
> > linking. The LGPL provides some rather contradictory statements in section
> > 6 regarding that:
> While this is true for stock ocaml, there is a patch that adds shared
> linking support to 3.03Alpha, with limited scope though - i386 ELF only.
> (shameless plug) You can find it here http://algol.prosalg.no/~malc/scaml

Yes, but those pesky gensym integers lying around prevent exactly this thing.  That is, if I write a library, compile to an
.so/.cmxa pair, and link to it, all is apparently well in the world.  Then if I try to change the implementation of the library but
leave the interfaces alone, I find out all the symbol names will change randomly, eg

	myFunction243     to     myFunction247

Fixing this may be as simple as removing a %s from the source.  I don't know, as I didn't dig that deep.  I also have a suspicion
that entry points are sometimes not unique.  I periodically hear things about multiple optimized entry points and I don't know if
that affects their symbol names.  I would presume it would, which would be another screw case to work on.

The question is that if you provide an .mli, are multiple entry points ever generated.  Actually, the real question is a little
more strict: given an .mli file, are the symbols generated well-defined (except for the arbitrary integer), and will they still be
unique if the integer is deleted?  Does any kind guru care to comment?

Though you aren't defining a calling convention or symbol naming scheme from scratch, you are still, in a sense, defininig a binary
interface here.  IMHO extreme paranoia is warranted!  ;-)

BTW, if you can address these concerns to my satisfaction, (And I wish other people were commenting on this.  The list was
strangely silent when you posted this patch- Am I the only one thinking this is extremely important?)  I'm happy to port it to the
windows dynamic linker.  I already did this for another linking library whose limitations I don't like too much any more.  (dlopen)


Jeff Henrikson


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

[Caml-list] Re: ELF i386 dynamic linking patch. was: License Conditions for OCaml

[malc]

"Jeff Henrikson" <jehenrik@yahoo.com> writes:

> > > OCaml doesn't provide support for shared libraries (although
> > > 3.03 does provide some dynamic loading capabilities for bytecode
> > > only). So we need to consider the portions of the license that
> > > apply for static linking. The LGPL provides some rather
> > > contradictory statements in section 6 regarding that:
> > While this is true for stock ocaml, there is a patch that adds
> > shared linking support to 3.03Alpha, with limited scope though -
> > i386 ELF only.  (shameless plug) You can find it here
> > http://algol.prosalg.no/~malc/scaml
>  Yes, but those pesky gensym integers lying around prevent exactly
> this thing.  That is, if I write a library, compile to an .so/.cmxa
> pair, and link to it, all is apparently well in the world.  Then if
> I try to change the implementation of the library but leave the
> interfaces alone, I find out all the symbol names will change
> randomly, eg
>  myFunction243 to myFunction247
I consider it low priority for now. More interested to add unloading
support for native compiled modules first.

>  Fixing this may be as simple as removing a %s from the source.  I
> don't know, as I didn't dig that deep.  I also have a suspicion that
> entry points are sometimes not unique.  I periodically hear things
> about multiple optimized entry points and I don't know if that
> affects their symbol names.  I would presume it would, which would
> be another screw case to work on.
I dont know, i dont expect any problems here. But then again, havent 
looked closely at this.

>  The question is that if you provide an .mli, are multiple entry
> points ever generated.  Actually, the real question is a little more
> strict: given an .mli file, are the symbols generated well-defined
> (except for the arbitrary integer), and will they still be unique if
> the integer is deleted?  Does any kind guru care to comment?
.mli doesnt give you this information, .cmx does.

>  Though you aren't defining a calling convention or symbol naming
> scheme from scratch, you are still, in a sense, defininig a binary
> interface here.  IMHO extreme paranoia is warranted!  ;-)
Well, i posted very sketchy first patch here, to collect comments,
feature requests and so on. I guess you have seen how miserably i failed.
I _really_ dont want to set standards on my own, but since almost
nobody is interested im forced to implement things the way they suit me.

>  BTW, if you can address these concerns to my satisfaction, (And I
> wish other people were commenting on this.  The list was strangely
> silent when you posted this patch- Am I the only one thinking this
> is extremely important?)  I'm happy to port it to the windows
> dynamic linker.  I already did this for another linking library
> whose limitations I don't like too much any more.  (dlopen)
If i'm reading apache log's correctly, there where 12 downloads of
1_shared.patch and 8 of 2_shared.patch. Overwhelming success. Sigh. 
Plus Xavier expressed team's disinterest in native dynamic linking
(at least in forseeable feature)

On the bright side Fabrice Le Fessant put it into CDK, on the down
side, after Xaviers message about CDK and patches, he decided to
remove them all. If he will go for optional patched compiler, it will
screw shared patch because of .cmx .cmxa incompatibilities. And i bet
not many possible CDK users will tollerate two(or more) multimegabyte
trees.

As for windows port, id happily provide any support i can. However
i forsee many obstacles. Windows's PE isnt really as feature packed
as ELF, there will be all sorts of visibility, scope etc problems.
(Not that it cant be done or anything ;)

P.S. Answering this message was a huge pain in the ass, i had to visit
XEmacs to fight this horrible mess Outlook produced. Maybe you
can fix that?

-- 
mailto:malc@pulsesoft.com

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

Re: [Caml-list] License Conditions for OCaml

[Michael Welsh Duggan]

Patrick M Doane <patrick@watson.org> writes:

> Earlier this year there was a discussion about the problems of using LGPL
> for the OCaml run-time system and associated libraries.
>
> It was suggested that some of the constraints in the LGPL were not
> intended. To quote a page from the Caml website:
>
>   "The LGPL puts no restrictions at all on programs linked with LGPL-ed
> libraries. Thus, users are free to distribute (or not) OCaml-generated
> binaries under whatever conditions they like."
>
> From my reading of the LGPL, which seems to correspond with the
> opinions of others on the list, this just isn't true.

I agree.  The LGPL does put some conditions on the binaries.
For example, they must be accompanied by a copy of the LGPL license.
But this license is *for the Ocaml libraries linked in*, not for the
whole binary.

> If I develop an application with OCaml, I must distribute that
> application with source code.  This isn't acceptable for commercial
> development and I'd really hope that the intention is for OCaml to
> be used outside of academia.

I suggest you read section 6 of the LGPL a little more closely.  I
have to be able to produce on demand source code for ocaml and its
libraries, but not for the work itself.  I do have to distribute the
work in such a way that ocaml and its libraries could change and be
relinked.  

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

It should be sufficent to distibute all the precompiled *.cm* files
of the binary in the distribution.  These could be linked with a
modified set of ocaml libraries to create a new program, but the
source to the application need not be shipped.

-- 
Michael Duggan
(md5i@cs.cmu.edu)
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Sven]

On Thu, Nov 08, 2001 at 11:30:56PM -0500, Patrick M Doane wrote:
> Earlier this year there was a discussion about the problems of using LGPL
> for the OCaml run-time system and associated libraries.
> 
> It was suggested that some of the constraints in the LGPL were not
> intended. To quote a page from the Caml website:
> 
>   "The LGPL puts no restrictions at all on programs linked with LGPL-ed
> libraries. Thus, users are free to distribute (or not) OCaml-generated
> binaries under whatever conditions they like."
> 
> >From my reading of the LGPL, which seems to correspond with the opinions
> of others on the list, this just isn't true.  If I develop an application
> with OCaml, I must distribute that application with source code.  This

No, the worse that happens is that you must distribute the .cmo, .cmi, .cmx,
and possibly .o, hopefully with a working makefile, but this last one is not
demanded.

The reason for that, in the C context (you need the .o only), is so if you
link with a buggy version of the LGPLed library, your client, or whatever, can
correct the LGPLed library, or grab a fixed version from the net, and rebuild
your app without the bug.

I don't know if this is really possible in the ocaml case, but i am sure
Xavier or someone else from the ocaml team will clarify it for us. But anyway,
i don't think, need to check though, that it needs to be rebuildable with the
latest version of ocaml, just the one you build your app with, but that,
altough not written explicitly, must also be one of the information you
provide your clients.

This last point would be greatly simplified if the ocaml compiler suite
comprised a little tool to check for the versions of ocaml used to build an
object file.

Also you only need to distribute this object files to the persons you
distribute the files to, and you even can only offer for people to get them on
your web site, or offer them per mail on a request, charging no more than the
shipping fee, but you have to guarantee that this offer stays valid for at
least 3 years.

Is this still unaceptable, or do you think this clarification will be ok with
you ?

That said, another solution would be to distribute the runtime systeme under a
dual licence, but you could not link it with GPLed code if you choose the
other non-GPL compatible licence. This is what trolltech did for the Qt libs.

> Will this problem be fixed for the 3.03 release?

As said, it is not really a licence problem, more a perception problem of the
llicence.

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

Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane]

On Fri, 9 Nov 2001, Sven wrote:

> On Thu, Nov 08, 2001 at 11:30:56PM -0500, Patrick M Doane wrote:
>
> No, the worse that happens is that you must distribute the .cmo, .cmi, .cmx,
> and possibly .o, hopefully with a working makefile, but this last one is not
> demanded.

As mentioned before - I don't think this is true. The LGPL is very clear
that the user must be able to modify the work (i.e. the application and
not the library). This is not possible to do with .cm[iox] files.

Also, I still must permit users to reverse engineer my application.

It is standard practice to strip an executable of all symbols to prevent
users from snooping around in the code.  Even if all I had to do was
include object files, the names of identifiers would still be intact.

> The reason for that, in the C context (you need the .o only), is so if you
> link with a buggy version of the LGPLed library, your client, or whatever, can
> correct the LGPLed library, or grab a fixed version from the net, and rebuild
> your app without the bug.

This is a good goal - but it's not what the LPGL says.

> Is this still unaceptable, or do you think this clarification will be ok with
> you ?

It may be acceptable to me, but probably not for my employeer or clients
who work in vertical markets that are very sensitive about proprietary
information.

Patrick

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

Re: [Caml-list] License Conditions for OCaml

[Sven]

On Fri, Nov 09, 2001 at 10:13:41AM -0500, Patrick M Doane wrote:
> On Fri, 9 Nov 2001, Sven wrote:
> 
> > On Thu, Nov 08, 2001 at 11:30:56PM -0500, Patrick M Doane wrote:
> >
> > No, the worse that happens is that you must distribute the .cmo, .cmi, .cmx,
> > and possibly .o, hopefully with a working makefile, but this last one is not
> > demanded.
> 
> As mentioned before - I don't think this is true. The LGPL is very clear
> that the user must be able to modify the work (i.e. the application and
> not the library). This is not possible to do with .cm[iox] files.

Please reread the stuff carefully, or if you are not able to understand it,
search for legal advice, or ask the FSF or someone such who has knowledge in
open source licences about it.

In this case, the right that the LGPL gives to the user is to modify the work
(the LPGLed library) and to relink your app with it. Why would you want to
stripe us of that right ? And despite what Xavier does say, it is no a silly
restriction, it guarantees the user that they are ever able to correct bugs in
the LGPLed library, and that all the bugs in your app are originated from you,
and not the ocaml compiler suite.

> Also, I still must permit users to reverse engineer my application.
> It is standard practice to strip an executable of all symbols to prevent
> users from snooping around in the code.  Even if all I had to do was
> include object files, the names of identifiers would still be intact.


Reverse engineering is legal in many european countries, ...

And anyway, there is no way you can take to completely stop reverse
engineering, 

Tell me, what application do you want to write that you are so afraid people
will reverse engineer ?

Often it is less expensive to rewrite the program from scratch than to do
reverse engineering, and anyway, maybe it is even cheaper to buy it from you.

The only viable reason for reverse engineering would be if you don't provide
adequate support for your stuff, inspecial if you don't provide binaries that
are portable to the arch i am using, or if you don't bother to correct bugs or
other such stuff.

And in these cases, you get what you deserve, and if you want it for less
recomendable reasons, then you have no sympathy from me.

Please think again about it, and see if it really is that important for you,
and if yes, i am sure you can negotiate a proper arrangement with the ocaml
copyright holders.

> > The reason for that, in the C context (you need the .o only), is so if you
> > link with a buggy version of the LGPLed library, your client, or whatever, can
> > correct the LGPLed library, or grab a fixed version from the net, and rebuild
> > your app without the bug.
> 
> This is a good goal - but it's not what the LPGL says.

Yes, it is, the FSF has spent  a lot of ressource with lawyers to ensure that,
thus the seemingly obscure legalistic wordings, but it says that.

> > Is this still unaceptable, or do you think this clarification will be ok with
> > you ?
> 
> It may be acceptable to me, but probably not for my employeer or clients
> who work in vertical markets that are very sensitive about proprietary
> information.

Mmm, ...

Is it because there are real fears, or because they are just misinformed, as
clearly you are only, ...

Perhaps did they receive the visit from some of those MS FUd spreaders trying
to remove confidence into the opensource movement, and saying that in the end,
going opensource will be more expensive than paying millions to MS for
software licences ? The 20 Million US$ saving of amazon.com for going with
linux notwithstanding ?

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

Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane]

Hi Sven,

I agree that this discussion maybe getting a bit much for the list. Here
are responses to a few of those points that I think are relevant:

On Sun, 11 Nov 2001, Sven wrote:

> Tell me, what application do you want to write that you are so afraid people
> will reverse engineer ?

I'm not afraid of it - but those around me who pay the bills are. I'm
relating the opinions of what I see in the commercial world. It is very
common to strip binaries of all identifiers (or at least munge them beyond
comprehension), and to have copy protection code. People are taking
reasonable steps to protect their intellectual property.

I want to see Caml succeed in that world. Now, it seems that Xavier
indicates that these problems will be fixed which is great. We have had a
number of good suggestions posted to the list that should be acceptable.

> > Hmm... I doubt anyone would be complaining if this were released with
> > the MIT License. That is much simpler to understand.
>
> That said, you cannot link with other usefull GPL/LGPLed stuff then, and
> i doubt you will ever convince the FSF or other such to relicence their
> code.

Sure you can, it is perfectly acceptable to link non-LPGL code with LPGL
code provided that you follow the rules of the LGPL.

> > But the object files expose too much proprietary information. The .cmi
> > files include the names of identifiers plus their types. Even the
> > identifiers alone are too much.

> Mmm, this is something Xavier or others from the ocaml team should
> respond to, But i think someone able to reverse engineer the .cmi, is
> also more than likely to be able to reverse engineer the asm code as
> well. Maybe even more likely ?

There are already several tools included in the distribution to get you
started. Look under the tools directory at application like 'dumpapprox'.
Luckily, the .cmi files should not be needed to relink an application.
These would contain the most information.

It is relatively easy to reverse engineer assembly when identifiers are
still present in the code. Take these out and the problem get much harder.

Patrick

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

Re: [Caml-list] License Conditions for OCaml

[Fergus Henderson]

On 09-Nov-2001, Patrick M Doane <patrick@watson.org> wrote:
> On Fri, 9 Nov 2001, Sven wrote:
> 
> > On Thu, Nov 08, 2001 at 11:30:56PM -0500, Patrick M Doane wrote:
> >
> > No, the worse that happens is that you must distribute the .cmo, .cmi, .cmx,
> > and possibly .o, hopefully with a working makefile, but this last one is not
> > demanded.
> 
> As mentioned before - I don't think this is true. The LGPL is very clear
> that the user must be able to modify the work (i.e. the application and
> not the library).  This is not possible to do with .cm[iox] files.

The LGPL says that the derived work must be licensed under terms
which "permit" the user to modify the work.  "permit" does not mean
the same thing as "make possible", and it definitely does not mean
the same thing as "make easy"!

It is in fact *possible* to modify the application given just the binary
files, of course, just not *easy*.

> Also, I still must permit users to reverse engineer my application.

Yes, that's correct.  You must give users the legal permission to reverse
engineer your application.  However, you are under no obligation to make
it easy.

> It is standard practice to strip an executable of all symbols to prevent
> users from snooping around in the code.  Even if all I had to do was
> include object files, the names of identifiers would still be intact.

For C code, you can through various techniques (such as `ld -r'
and the `--retain-symbols-file' options of GNU ld) link your object
files into a single object file and strip out all of the symbols except
those undefined symbols that refer to the LGPL'd library or libraries
that you are linking with.  These techniques can also be used with other
programming language implementations that generate standard object files,
such as (my favourite example ;) Mercury.

I don't know if this is possible for Ocaml code, but if it is not, then
I think it might perhaps be more useful to ask for similar technical
features, rather than complaining about the license.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane]

On Tue, 27 Nov 2001, Fergus Henderson wrote:

> > Also, I still must permit users to reverse engineer my application.
>
> Yes, that's correct.  You must give users the legal permission to reverse
> engineer your application.  However, you are under no obligation to make
> it easy.

Okay, true enough. There is some loss of legal action a company can take,
but it is probably fine.

> For C code, you can through various techniques (such as `ld -r'
> and the `--retain-symbols-file' options of GNU ld) link your object
> files into a single object file and strip out all of the symbols except
> those undefined symbols that refer to the LGPL'd library or libraries
> that you are linking with.  These techniques can also be used with other
> programming language implementations that generate standard object files,
> such as (my favourite example ;) Mercury.
>
> I don't know if this is possible for Ocaml code, but if it is not, then
> I think it might perhaps be more useful to ask for similar technical
> features, rather than complaining about the license.

There are many ways to address the issue and this could be good
functionality to have. However, it's a lot less work to change the license
and let developers simply strip the binaries after compilation.

I brought up the topic of licensing as a status update. Xavier has said in
the past that the conditions in the LGPL are silly and I agree with him.
He also indicated that they would be looking into modifications in the
future. My intent was not to start a flamewar on license issues, although
they can be very hard to avoid with such a topic!

Patrick

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

Re: [Caml-list] License Conditions for OCaml

[Fergus Henderson]

On 26-Nov-2001, Patrick M Doane <patrick@watson.org> wrote:
> ... it's a lot less work to change the license ...

Well, maybe, maybe not...
you might be surprised at how difficult that often is ;-)

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Rafael 'Dido' Sevilla]

On Tue, Nov 27, 2001 at 09:28:59PM +1100, Fergus Henderson wrote:
> On 26-Nov-2001, Patrick M Doane <patrick@watson.org> wrote:
> > ... it's a lot less work to change the license ...
> 
> Well, maybe, maybe not...
> you might be surprised at how difficult that often is ;-)

Especially if not all the code is really yours.  I believe that's the
case with OCaml.  There have been whispers here and there that the OCaml
regular expression code contains code taken from a LGPLed regex library,
whose copyright is owned by the Free Software Foundation.  THEY
definitely are not going to agree with any sort of change away from the
(L)GPL, and will not look kindly on any violation.  The sort of code
sharing we usually see is encouraged, and very few projects of any great
magnitude can  say that their code is completely written by them.  It
isn't true of Linux (there's a lot of code 'stolen' from BSD in there)
and that certainly isn't true of the OCaml runtime and libraries.

And even if you owned all the code and decided to change its license,
especially to something less liberal than the GPL, people who don't like
it can just take your old GPLed version and use THAT instead and hack on
THAT instead.  Like what happened with Sistina and GFS.

Changing licenses of a major project, especially one that has been a
community effort is not something that can be done without the aid of a
lawyer experienced in the entanglements of copyright law...

-- 
Rafael R. Sevilla <sevillar@team.ph.inter.net>   +63(2)   8177746 ext. 8311
Programmer, Inter.Net Philippines                +63(917) 4458925
http://dido.engr.internet.org.ph/                OpenPGP Key ID: 0x5CDA17D8
            Heute die Welt und Morgen das Sonnensystem!
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Xavier Leroy]

> There have been whispers here and there that the OCaml
> regular expression code contains code taken from a LGPLed regex library,
> whose copyright is owned by the Free Software Foundation.

Yes, the "Str" library of OCaml is built on top of the "regexp"
library, which is owned by the FSF and distributed under the GPL.

> THEY definitely are not going to agree with any sort of change away from the
> (L)GPL, and will not look kindly on any violation.

Sure.  When we're talking about changing the OCaml licensing terms, it
really means changing the licensing terms of the code for which we are
the copyright owners.  (The LICENSE file in the OCaml distribution is
carefully worded to cover only the source files that are copyright INRIA.)

Fortunately, all of the OCaml code is copyright INRIA except this
lousy "regexp" library, which no-one is forced to use (the remainder
of the OCaml system doesn't depend on it), and which we'll replace
eventually by something more efficient.

> And even if you owned all the code and decided to change its license,
> especially to something less liberal than the GPL, people who don't like
> it can just take your old GPLed version and use THAT instead and hack on
> THAT instead.  Like what happened with Sistina and GFS.

We're talking about making the OCaml license *more* liberal, by
*removing* silly requirements of the LGPL.  I don't see users
objecting to this.

- Xavier Leroy
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Sven]

On Wed, Nov 28, 2001 at 07:00:38PM +0100, Xavier Leroy wrote:
> > There have been whispers here and there that the OCaml
> > regular expression code contains code taken from a LGPLed regex library,
> > whose copyright is owned by the Free Software Foundation.
> 
> Yes, the "Str" library of OCaml is built on top of the "regexp"
> library, which is owned by the FSF and distributed under the GPL.
> 
> > THEY definitely are not going to agree with any sort of change away from the
> > (L)GPL, and will not look kindly on any violation.
> 
> Sure.  When we're talking about changing the OCaml licensing terms, it
> really means changing the licensing terms of the code for which we are
> the copyright owners.  (The LICENSE file in the OCaml distribution is
> carefully worded to cover only the source files that are copyright INRIA.)
> 
> Fortunately, all of the OCaml code is copyright INRIA except this
> lousy "regexp" library, which no-one is forced to use (the remainder
> of the OCaml system doesn't depend on it), and which we'll replace
> eventually by something more efficient.
> 
> > And even if you owned all the code and decided to change its license,
> > especially to something less liberal than the GPL, people who don't like
> > it can just take your old GPLed version and use THAT instead and hack on
> > THAT instead.  Like what happened with Sistina and GFS.
> 
> We're talking about making the OCaml license *more* liberal, by
> *removing* silly requirements of the LGPL.  I don't see users
> objecting to this.

Well, you are the copyright owner, but going away from the LGPL is more
liberal for the user, but less liberal for others, so it is a compromise, a
subtle balance that must be met.

The current 'silly' requirement you object to is there to guarantee the right
of the user of a tool written in ocaml to use with the latest bug fixed
version of the ocaml runtime libs even if the producer of the product don't
care about it.

This may be an important issue, especially if ocaml gets used in more
security-conscious stuff.

Also there is the fact that some may want to produce only the i386 native code
and distribute this to their clients, which ties them to use i386 hardware,
and is a restriction of their liberty to use whatever they want.

Sure, true arch indepent bytecode as we will soon have may well solve this
problem.

You may think that this is not a real problem, and it is not, provided the
provider of the product is conscious enough to provide a rebuild or something
like it when it is needed, but this is not something you can guarantee, and it
may have repercussions on the perception of ocaml in some ways.

Anyway, this is a hairy discution, which we should maybe port to a specialized
list or something like that ?


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

Re: [Caml-list] License Conditions for OCaml

[Vitaly Lugovsky]

On Thu, 8 Nov 2001, Patrick M Doane wrote:

>   "The LGPL puts no restrictions at all on programs linked with LGPL-ed
> libraries. Thus, users are free to distribute (or not) OCaml-generated
> binaries under whatever conditions they like."
> 
> >From my reading of the LGPL, which seems to correspond with the opinions
> of others on the list, this just isn't true. 

 Please, read it again. Carefully.

> If I develop an application
> with OCaml, I must distribute that application with source code. 

 No. You must distribute a runtime source or just put a link how to get
it. Nothing more. There are a lot of commercial, closed source 
applications linked with LGPL libraries - e.g. any Linux commercial
apps linked with GNU Libc.

> This isn't acceptable for commercial development

 It IS acceptable. But here, I think, it's offtopic. Read slashdot, and so 
on. Look at WineX, for example: open source, commercial binaries.

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

Re: [Caml-list] License Conditions for OCaml

[Patrick M Doane]

On Fri, 9 Nov 2001, Vitaly Lugovsky wrote:

> On Thu, 8 Nov 2001, Patrick M Doane wrote:
>
> >   "The LGPL puts no restrictions at all on programs linked with LGPL-ed
> > libraries. Thus, users are free to distribute (or not) OCaml-generated
> > binaries under whatever conditions they like."
> >
> > >From my reading of the LGPL, which seems to correspond with the opinions
> > of others on the list, this just isn't true.
>
>  Please, read it again. Carefully.

I have read it again today, carefully, and still come to the same
conclusions:

  1. Users are allowed to reverse engineer the application

  2. Source (or possibly object files) for my application must be included
     in the distribution.

I could probably be convinced that object files are sufficient for
purposes of satisfying the license, but that just exposes the next major
problem (i.e. point #1).

> > If I develop an application
> > with OCaml, I must distribute that application with source code.
>
>  No. You must distribute a runtime source or just put a link how to get
> it. Nothing more. There are a lot of commercial, closed source
> applications linked with LGPL libraries - e.g. any Linux commercial
> apps linked with GNU Libc.

The runtime source for OCaml must be included or a "written letter" must
be provided. That's quite a bit different than a link.

You also need to include either source (or again maybe object files) of
the application that uses the library.

It's not sufficient to simply ship a static executable and include a
notice where one can get the OCaml source code.

> > This isn't acceptable for commercial development
>
>  It IS acceptable. But here, I think, it's offtopic. Read slashdot, and so
> on. Look at WineX, for example: open source, commercial binaries.

I agree that for open source commercial software, there are no problems.
This hardly represents the majority of commercial development though.

If this isn't an appropriate place to discuss issues with the Caml
license, where else is?

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

Re: [Caml-list] License Conditions for OCaml

[Sven]

On Fri, Nov 09, 2001 at 04:39:13PM -0500, Patrick M Doane wrote:
> On Fri, 9 Nov 2001, Vitaly Lugovsky wrote:
> 
> > On Thu, 8 Nov 2001, Patrick M Doane wrote:
> >
> > >   "The LGPL puts no restrictions at all on programs linked with LGPL-ed
> > > libraries. Thus, users are free to distribute (or not) OCaml-generated
> > > binaries under whatever conditions they like."
> > >
> > > >From my reading of the LGPL, which seems to correspond with the opinions
> > > of others on the list, this just isn't true.
> >
> >  Please, read it again. Carefully.
> 
> I have read it again today, carefully, and still come to the same
> conclusions:
> 
>   1. Users are allowed to reverse engineer the application
> 
>   2. Source (or possibly object files) for my application must be included
>      in the distribution.
> 
> I could probably be convinced that object files are sufficient for
> purposes of satisfying the license, but that just exposes the next major
> problem (i.e. point #1).
> 

Yes, this is the real problem for you, why not say it from the begining and
explain a bit ?

> > > If I develop an application
> > > with OCaml, I must distribute that application with source code.
> >
> >  No. You must distribute a runtime source or just put a link how to get
> > it. Nothing more. There are a lot of commercial, closed source
> > applications linked with LGPL libraries - e.g. any Linux commercial
> > apps linked with GNU Libc.
> 
> The runtime source for OCaml must be included or a "written letter" must
> be provided. That's quite a bit different than a link.

Well, you have :

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

That is, if you offer your app as downloadeable, you just need to offer the
object code from the same place.

In the other case, you probably ship a CD or something such, and probably
acompany it by a documentation, in this case, just add a page to the
documentation to comply with the LGPL.

> You also need to include either source (or again maybe object files) of
> the application that uses the library.

No, it is the source you need to provide for the LGPLed library.

but again, either a letter or a downloadable version would be ok.

> It's not sufficient to simply ship a static executable and include a
> notice where one can get the OCaml source code.

Well, not sure, the reasoning here is that you must agree to make the object
and library source available for at least 3 years. You cannot guarantee that
the ocaml team will be doing this for the next 3 years, altough it certainly
would. Now if you were a member of the consortium, then this may be
legailistically sufficient, but again, i am no lawyer.

That said, if you modify the ocaml compiler suite to build your app, then you
have to make these modifications available, maybe it is this that is required
?

> > > This isn't acceptable for commercial development
> >
> >  It IS acceptable. But here, I think, it's offtopic. Read slashdot, and so
> > on. Look at WineX, for example: open source, commercial binaries.
> 
> I agree that for open source commercial software, there are no problems.
> This hardly represents the majority of commercial development though.

But study have said that this represent a big share of those commercial
software that will still exist in the next few years, you have been warned
:)))

> If this isn't an appropriate place to discuss issues with the Caml
> license, where else is?

Don't know, is this of interrest to the other list participants ? If yes, we
can continue here, users bored with it can easily send it to /dev/null with a
proper mail filter. If not, then we could continue privately, or create a new
list ocaml-legalese, or something such ? What do the other mailing list member
say about this, and in particular the ocaml team ?

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

Re: [Caml-list] License Conditions for OCaml

[Tom]

> >   1. Users are allowed to reverse engineer the application
> > 
> >   that just exposes the next major problem (i.e. point #1).

You cannot realistically protect yourself from reverse engineering.
In many countries, you cannot even prohibit reverse engineering in your
license.  Reverse engineering for the purpose of building a work-alike
solution is an important part of a free market in software.

I suspect many businesses that have concerns about reverse engineering
are more concerned about having some dirty secrets exposed (like
GPL violations or the unlicensed use of commercial software) than about
a realistic expectation of anybody cloning their product by reverse
engineering.

Tom


__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
-------------------
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

RE: [Caml-list] License Conditions for OCaml

[Dave Berry]

I believe the intent of the section of the LGPL that Patrick is quoting
is to prevent unscrupulous people from incorporating an LGPL'd library
into a library of their own and distributing it free from the terms of
the LGPL.  Clearly this scenario would be a way of breaking the intent
of the licence.  I don't believe this section is intended to cover
applications.

Why does intent matter?  Three reasons:

1. The issue of morality.
2. The likelihood (or otherwise) of the FSF to sue.
3. Possibly even law, in some countries.

The underlying problem is that the LGPL is designed for
dynamically-linked libraries, and O'Caml is statically linked.  It's a
square peg and a round hole.  IM(limited)O, the best way to fix it is to
make OCaml use dynamic linking.

Dave.

-----Original Message-----
From: Patrick M Doane [mailto:patrick@watson.org]
Sent: 09 November 2001 15:40
To: Julian Assange
Cc: Sven; Michael Welsh Duggan; Caml-list
Subject: Re: [Caml-list] License Conditions for OCaml


On Fri, 9 Nov 2001, Julian Assange wrote:

>
> All this legalise is very interesting, but in the end, as with all
legalise
> there is only one important issue:
>
>      a) Who has the motivation, resources and standing to fuck with
you?
>
> Hint: it's not INRIA.

The issue of morality is very important to me and cannot be ignored.
Besides, the FSF has plenty of motivation and resources.

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

Re: [Caml-list] License Conditions for OCaml

[John Field]

Xavier Leroy wrote:

> Let me just state again what we'd like to achieve concerning the
> licensing of the OCaml runtime and libraries:
> 
> 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.

All of these look great to me.

> Now the problem is that apparently there is no existing license that
> matches these three criteria.  The LGPL was chosen before we realized
> all its implications w.r.t. static linking.  But popular licenses such
> as BSD or X don't meet criterion 2.  Our current hope is that the LGPL
> with a special exception to paragraph 6 saying "you can link with our
> code any way you like" would fulfill all three requirements.

This would certainly appear to meet the objections IBM's lawyers had.

> > ... However,
> > the license provisions are so ambiguously worded (as ample discussion
> > on this list has demonstrated) that the requirements it imposes on an
> > implementer and the rights it grants to a user are very unclear.

> Clearly, we want to allow "modifications" to the OCaml code itself
> (otherwise it's not open source), but not impose this requirement on
> the user code.  Are you saying that the LGPL is sufficiently ambiguous
> not to distinguish clearly between library code and user code?

No, I don't think the distinction between library and user code was
ambiguous.  The ambiguities I was referring to relate to the requirements
imposed on implementers to accommodate re-linking, and to the rights
it grants to users of the re-linked code.

> As for "reverse engineering", I don't really care.  If we void
> paragraph 6 of the LGPL, the user isn't required to allow reverse
> engineering.  Still, commercial licenses that prevent reverse
> engineering are silly -- here in the European Union (and in other
> countries as well), reverse engineering is explicitly allowed by law
> in certain circumstances, so putting such a provision in your license
> is just calling for the whole license to be invalidated by a EU court.

Personally, I agree that prohibitions on reverse-engineering are a
waste of time.  On the other hand, the lawyers seem to regard the LGPL
clause that _explictly_ allows reverse-engineering as sort of an
open-ended invitation to mischief.

> > As a result of the issues above, IBM's general response to
> > applications that use LGPL libraries is to require that the
> > libraries be dynamically-linked.  Since this wasn't feasible with
> > OCaml, we had to distribute the application in bytecode, rather than
> > opt-compiled form.

> Suppose we remove the re-linking requirement.  Would that be enough to
> allow distribution of an ocamlopt-compiled executable in IBM's
> lawyers' opinion?

All of their objections were related to the re-linking requirement, so
unless its removal somehow introduced new issues, I would _think_ that
the result would be acceptable.

> As I said above, the other standard licenses (e.g. BSD, X) don't offer
> enough guarantees about the OCaml libraries and runtime themselves
> remaining open source.

FWIW, I will ask some of my colleagues who have more experience with
open source licenses than I do to see if there might be any other
licenses around (obviously not as commonly-used as the ones above)
that avoid LGPL re-linking problem.

-John

John Field
IBM T.J. Watson Research Center
http://www.research.ibm.com/people/j/jfield

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

Re: [Caml-list] License Conditions for OCaml

[Al Christians]

John Field wrote:
> 
> FWIW, I will ask some of my colleagues who have more experience with
> open source licenses than I do to see if there might be any other
> licenses around (obviously not as commonly-used as the ones above)
> that avoid LGPL re-linking problem.
> 

The license for GNAT (gcc Ada compiler) is GPL with an exception that
distribution of binaries compiled using the compiler and supplied 
libraries does not require that the GPL applies.   Many other libraries
for Ada use this same license. There are very few complaints about 
this license.  


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

Re: [Caml-list] License Conditions for OCaml

[james woodyatt]

On Wednesday, November 28, 2001, at 12:29 , John Field wrote:
> Xavier Leroy wrote:
>>
>> Let me just state again what we'd like to achieve concerning the
>> licensing of the OCaml runtime and libraries:
>>
>> 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.
>
> All of these look great to me.
>
>> As I said above, the other standard licenses (e.g. BSD, X) don't offer
>> enough guarantees about the OCaml libraries and runtime themselves
>> remaining open source.
>
> FWIW, I will ask some of my colleagues who have more experience with
> open source licenses than I do to see if there might be any other
> licenses around (obviously not as commonly-used as the ones above)
> that avoid LGPL re-linking problem.

There are many to choose from, but all of them will place some 
restrictions on the user executables developed with the covered code.  
Whether you think those restrictions are insignificant or desirable in 
some way, is a matter to be resolved.

The two licenses that spring to mind most readily to me are the Artistic 
License, and the Apple Public Source License.  Both of them would 
require tweaking to INRIA's purposes, but I think either one could 
easily be made to work, depending on how you wanted to trade off between 
protecting INRIA's investment and protecting users' freedoms.  They're 
both meet the OSI definition, and *generally* do what you want in 1 and 
2.

These licenses are just the ones I'm most familiar with (aside from the 
BSD, MIT and GPL licenses), because 1) I'm a long time Perl hacker (gave 
it up mostly for Caml); and, 2) I'm a Macintosh user and an Apple 
developer.  (Perhaps, I should also disclose that I work for Apple 
Computer, but my work there does not involve Caml...)

Anyway, it sounds like you're looking for a license that would be 
compatible with the APSL, i.e. it would permit OCaml to be integrated 
into the Darwin distribution, should that ever seem like a good idea to 
the people who manage that sort of thing.  As a personal matter, I would 
like to see that happen someday.

Good luck sorting out the license issue.


--
j h woodyatt <jhw@wetware.com>
"...the antidote to misinformation is more information, not less."
                                                      --vinton cerf

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

Re: [Caml-list] License Conditions for OCaml

[Florian Hars]

On Wed, Nov 28, 2001 at 05:25:23PM -0800, james woodyatt wrote:
> The two licenses that spring to mind most readily to me are the Artistic 
> License, and the Apple Public Source License.

But if you consider using these, you might want to take the FSF's
stance on these license into account:

Artistic:
  We cannot say that this is a free software license because it is too
  vague ... We urge you to avoid using it, except as part of the 
  disjunctive license of Perl.

APSL:
  Please don't use this license, and we urge you to avoid any software 
  that has been released under it.

http://www.gnu.org/licenses/license-list.html#NonFreeSoftwareLicense

Yours, Florian
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[james woodyatt]

On Thursday, November 29, 2001, at 12:47 , Florian Hars wrote:
> On Wed, Nov 28, 2001 at 05:25:23PM -0800, james woodyatt wrote:
>> The two licenses that spring to mind most readily to me are the 
>> Artistic
>> License, and the Apple Public Source License.
>
> But if you consider using these, you might want to take the FSF's
> stance on these license into account: [...]

M. Leroy expressed an interest in licenses that meet the OSI definition 
of an "open source" license.  Both of these licenses are certified by 
the OSI, and INRIA would probably meet little resistance if they 
introduced a license for OCaml that says essentially the same things.

For reasons you should be able to infer from my previous post on this 
subject, I am probably less concerned with the stance taken by the FSF 
than you.  All I will say on that subject is that you quoted the parts 
of their page in which the FSF criticizes older, now-superseded versions 
of both the Artistic and the Apple Public Source licenses.

In the case of the Artistic license, the FSF says the newer "clarified" 
version is compatible with the GPL.  In the case of the APSL, all their 
complaints but one (i.e. the freedom to deploy modifications to the 
software "in private" not being quite as absolute as they would like) is 
addressed by the latest version.  An argument can be made that the FSF 
is holding to this one predicate primarily to further a narrow political 
agenda.  No, I don't feel like making that case.

So yeah, if compatibility with the GPL and achieving the blessings of 
the FSF is a concern: go with the "clarified" Artistic license, or 
something like it.  Everyone should be happy.  On the other hand, if any 
of these licenses are ever tested in court, I think the odds favor the 
APSL being found more enforceable than any of the ones the FSF 
approves.  I would think INRIA might be interested in the protections 
against patent abuse found in the APSL, which is why I mentioned it as 
an alternative.

I will now shut up about licensing issues.  It's a dull, tedious 
subject, and M. Leroy has already said enough to reassure me INRIA will 
not be changing the license for OCaml to something I would find a 
disappointment.


--
j h woodyatt <jhw@wetware.com>
"...the antidote to misinformation is more information, not less."
                                                      --vinton cerf

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

Re: [Caml-list] License Conditions for OCaml

[Ohad Rodeh]

There is one long standing issue that I've had with the Caml license. I
have a BSD licensed
system (Ensemble) that uses a non-standard, Caml derived, Unix library. We
call our library "Unix" library Socket,
and it contains various performance hacks and a port to winsock2. The issue
is simple, what is
the license for Socket?  On the one hand, it should be BSD, because we
wrote it, and it is part of
a BSD system. On the other  hand, since it uses some (little) of the Caml
code, it should have an LGPL license.

I really think that that Socket should have a BSD license. One way to solve
this problem would be to make the inner
Unix header file public (i.e., copied to lib/caml/*.h). Our use of the Unix
library sources is to the extent (almost entirely)
of using the header files.

   Any thoughts?
     Ohad.



Xavier Leroy <xavier.leroy@inria.fr>@pauillac.inria.fr on 28/11/2001
20:22:39

Sent by:  owner-caml-list@pauillac.inria.fr


To:   John Field/Watson/IBM@IBMUS
cc:   caml-list@inria.fr
Subject:  Re: [Caml-list] License Conditions for OCaml



John,

Thank you for your feedback -- it's very interesting to hear from an
industrial user who got the opinions of competent lawyers.

Let me just state again what we'd like to achieve concerning the
licensing of the OCaml runtime and libraries:

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.

All three items are easy to justify: for 1, we don't want to bother
anyone who uses OCaml; for 2, we'd like OCaml to remain open
source, meaning that everyone should be able to benefit from the
modifications on OCaml itself that someone did; and for 3, we're not
competent for inventing yet another license and get it recognized as
open source compliant.

Now the problem is that apparently there is no existing license that
matches these three criteria.  The LGPL was chosen before we realized
all its implications w.r.t. static linking.  But popular licenses such
as BSD or X don't meet criterion 2.  Our current hope is that the LGPL
with a special exception to paragraph 6 saying "you can link with our
code any way you like" would fulfill all three requirements.

> IBM's lawyers have lots of experience dissecting the innards of
> various open- and quasi-open source licenses.  They are _very_ wary
> of the LGPL.  I won't attempt to explain or justify all of
> their concerns, some of which I don't fully understand.  However,
> their principal objections were to the clauses of the LGPL allowing
> "reverse engineering" of and "modifications" to the code.  The lawyers
> realize that the _intent_ of these clauses is probably benign.  However,
> the license provisions are so ambiguously worded (as ample discussion
> on this list has demonstrated) that the requirements it imposes on an
> implementer and the rights it grants to a user are very unclear.

Clearly, we want to allow "modifications" to the OCaml code itself
(otherwise it's not open source), but not impose this requirement on
the user code.  Are you saying that the LGPL is sufficiently ambiguous
not to distinguish clearly between library code and user code?

As for "reverse engineering", I don't really care.  If we void
paragraph 6 of the LGPL, the user isn't required to allow reverse
engineering.  Still, commercial licenses that prevent reverse
engineering are silly -- here in the European Union (and in other
countries as well), reverse engineering is explicitly allowed by law
in certain circumstances, so putting such a provision in your license
is just calling for the whole license to be invalidated by a EU court.

(Besides, if I buy, say, a TV set, I can open it and reverse-engineer the
circuit board to my heart's content; I might void the warranty this
way, but I'm not doing anything illegal.  I find it hard to understand
why it should be any different with software.)

> In addition to the legal ambiguities, the provision requiring
> that the code be distributed in a way that allows re-linking of
> the libraries is a major administrative hassle

I fully agree with this.  My proposal is basically to remove this
requirement for the OCaml libraries.

> As a result of the issues above, IBM's general response to
> applications that use LGPL libraries is to require that the
> libraries be dynamically-linked.  Since this wasn't feasible with
> OCaml, we had to distribute the application in bytecode, rather than
> opt-compiled form.

Suppose we remove the re-linking requirement.  Would that be enough to
allow distribution of an ocamlopt-compiled executable in IBM's
lawyers' opinion?

> If the OCaml developers don't feel that the relinking provisions of
> LGPL are important, I would strongly advise adopting an alternative
> license that unambiguously allows static linking of OCaml libraries
> without imposing any additional requirements on the application.

As I said above, the other standard licenses (e.g. BSD, X) don't offer
enough guarantees about the OCaml libraries and runtime themselves
remaining open source.

- Xavier Leroy
-------------------
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



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

Re: [Caml-list] License Conditions for OCaml

[David Gurr]

Xavier Leroy:
> Let me just state again what we'd like to achieve concerning the
> licensing of the OCaml runtime and libraries:
> 
> 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.
 
 
Hi, could you give a similar description for your aims on licensing the
compiler code?  Thanks.  -D
-------------------
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

RE: [Caml-list] License Conditions for OCaml

[Don Syme]

And what if the OCaml modification to the LGPL gave you an opt-out from
this clause as well?

Just poking legal fun...

;-)

-----Original Message-----
From: Greg Bacon [mailto:gbacon@fly.hiwaay.net] 
Sent: 29 November 2001 23:13
To: Julian Assange
Cc: Xavier Leroy; John Field; caml-list@inria.fr
Subject: Re: [Caml-list] License Conditions for OCaml 


In message <20011129230153.55D4D259D2@suburbia.net>,
    Julian Assange writes:

: > For a well-known counterexample, the Perl Kit is distributed either
: > under the terms of the Artistic License or the GPL.
: 
: This is not a counter example. "all of the work, or none of the work".
: 
: 
:                Code
:               /    \
:             /        \
:        GPLisation   Artification
: 
: At no stage does the Artistic License modify the GPL.

Dual licensing is an implicit modification of the GPL:

      5. You are not required to accept [the GPL], since you have not
    signed it.  However, nothing else grants you permission to modify or
    distribute the Program or its derivative works.  These actions are
    prohibited by law if you do not accept this License.  Therefore, by
    modifying or distributing the Program (or any work based on the
    Program), you indicate your acceptance of this License to do so, and
    all its terms and conditions for copying, distributing or modifying
    the Program or works based on it.

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

Re: [Caml-list] License Conditions for OCaml

[Julian Assange]

> :                Code
> :               /    \
> :             /        \
> :        GPLisation   Artification
> : 
> : At no stage does the Artistic License modify the GPL.
> 
> Dual licensing is an implicit modification of the GPL:
> 
>       5. You are not required to accept [the GPL], since you have not
>     signed it.  However, nothing else grants you permission to modify or
> [etc]

No. The GPL is not retrospective. Consequently it can't climb the
deriviation tree to get at the Artistic code. Thus this is not a
modification of the GPL.

In any event, copyrights can only be held by individuals and or
registered organisations. The GPL itself is not such an entity.
The FSF is, but (in this argument) only as far as the GPL is
concerned.  Provided all authors agree, copyright restrictions can
be changed to anything thing they want at anytime. However, if they
do not agree, that portion which falls under the malcontents'
copyright must be completely excised.  The FSF is the copyright
holder of the GPL ("COPYING") and has not granted permission for
it to be modified or used in another in a non-GPL setting (including
by appending clauses).

--
 Julian Assange        |If you want to build a ship, don't drum up people
                       |together to collect wood or assign them tasks and
 proff@iq.org          |work, but rather teach them to long for the endless
 proff@gnu.ai.mit.edu  |immensity of the sea. -- Antoine de Saint Exupery
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Richard Stallman]

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

Re: [Caml-list] License Conditions for OCaml

[Sven]

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

Re: [Caml-list] License Conditions for OCaml

[Richard Stallman]

    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

Re: [Caml-list] License Conditions for OCaml

[John Field]

Our group at IBM recently used OCaml to implement a compiler-like
utility for migration of database applications (part of a larger
suite of tools available for free download at
http://www-4.ibm.com/software/data/db2/migration/mtk/).
I thought our experiences might be relevant to the discussion about
OCaml licensing conditions.

IBM's lawyers have lots of experience dissecting the innards of
various open- and quasi-open source licenses.  They are _very_ wary
of the LGPL.  I won't attempt to explain or justify all of
their concerns, some of which I don't fully understand.  However,
their principal objections were to the clauses of the LGPL allowing
"reverse engineering" of and "modifications" to the code.  The lawyers
realize that the _intent_ of these clauses is probably benign.  However,
the license provisions are so ambiguously worded (as ample discussion
on this list has demonstrated) that the requirements it imposes on an
implementer and the rights it grants to a user are very unclear.

In addition to the legal ambiguities, the provision requiring
that the code be distributed in a way that allows re-linking of
the libraries is a major administrative hassle (e.g., does IBM have
to redistribute the MS linker if someone decides they want
to relink the application?  Do they have to get a license from
MS to do this?...)

As a result of the issues above, IBM's general response to
applications that use LGPL libraries is to require that the
libraries be dynamically-linked.  Since this wasn't feasible with
OCaml, we had to distribute the application in bytecode, rather than
opt-compiled form.  This resulted in a significant (but acceptable)
loss of performance that we would have preferred to avoid.  It is
certainly possible that the IBM lawyers are being unnecessarily
cautious, but since they are the gatekeepers for getting applications
out the door, their perceptions become reality.

If the OCaml developers don't feel that the relinking provisions of
LGPL are important, I would strongly advise adopting an alternative
license that unambiguously allows static linking of OCaml libraries
without imposing any additional requirements on the application.

-John

John Field
IBM T.J. Watson Research Center
http://www.research.ibm.com/people/j/jfield

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

Re: [Caml-list] License Conditions for OCaml

[Xavier Leroy]

John,

Thank you for your feedback -- it's very interesting to hear from an
industrial user who got the opinions of competent lawyers.

Let me just state again what we'd like to achieve concerning the
licensing of the OCaml runtime and libraries:

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.

All three items are easy to justify: for 1, we don't want to bother
anyone who uses OCaml; for 2, we'd like OCaml to remain open
source, meaning that everyone should be able to benefit from the
modifications on OCaml itself that someone did; and for 3, we're not
competent for inventing yet another license and get it recognized as
open source compliant.

Now the problem is that apparently there is no existing license that
matches these three criteria.  The LGPL was chosen before we realized
all its implications w.r.t. static linking.  But popular licenses such
as BSD or X don't meet criterion 2.  Our current hope is that the LGPL
with a special exception to paragraph 6 saying "you can link with our
code any way you like" would fulfill all three requirements.

> IBM's lawyers have lots of experience dissecting the innards of
> various open- and quasi-open source licenses.  They are _very_ wary
> of the LGPL.  I won't attempt to explain or justify all of
> their concerns, some of which I don't fully understand.  However,
> their principal objections were to the clauses of the LGPL allowing
> "reverse engineering" of and "modifications" to the code.  The lawyers
> realize that the _intent_ of these clauses is probably benign.  However,
> the license provisions are so ambiguously worded (as ample discussion
> on this list has demonstrated) that the requirements it imposes on an
> implementer and the rights it grants to a user are very unclear.

Clearly, we want to allow "modifications" to the OCaml code itself
(otherwise it's not open source), but not impose this requirement on
the user code.  Are you saying that the LGPL is sufficiently ambiguous
not to distinguish clearly between library code and user code?

As for "reverse engineering", I don't really care.  If we void
paragraph 6 of the LGPL, the user isn't required to allow reverse
engineering.  Still, commercial licenses that prevent reverse
engineering are silly -- here in the European Union (and in other
countries as well), reverse engineering is explicitly allowed by law
in certain circumstances, so putting such a provision in your license
is just calling for the whole license to be invalidated by a EU court.

(Besides, if I buy, say, a TV set, I can open it and reverse-engineer the
circuit board to my heart's content; I might void the warranty this
way, but I'm not doing anything illegal.  I find it hard to understand
why it should be any different with software.)

> In addition to the legal ambiguities, the provision requiring
> that the code be distributed in a way that allows re-linking of
> the libraries is a major administrative hassle

I fully agree with this.  My proposal is basically to remove this
requirement for the OCaml libraries.

> As a result of the issues above, IBM's general response to
> applications that use LGPL libraries is to require that the
> libraries be dynamically-linked.  Since this wasn't feasible with
> OCaml, we had to distribute the application in bytecode, rather than
> opt-compiled form.

Suppose we remove the re-linking requirement.  Would that be enough to
allow distribution of an ocamlopt-compiled executable in IBM's
lawyers' opinion?

> If the OCaml developers don't feel that the relinking provisions of
> LGPL are important, I would strongly advise adopting an alternative
> license that unambiguously allows static linking of OCaml libraries
> without imposing any additional requirements on the application.

As I said above, the other standard licenses (e.g. BSD, X) don't offer
enough guarantees about the OCaml libraries and runtime themselves
remaining open source.

- Xavier Leroy
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Ronald Kuehn]

Xavier Leroy wrote:

> Now the problem is that apparently there is no existing license that
> matches these three criteria.  The LGPL was chosen before we realized
> all its implications w.r.t. static linking.  But popular licenses such
> as BSD or X don't meet criterion 2.  Our current hope is that the LGPL
> with a special exception to paragraph 6 saying "you can link with our
> code any way you like" would fulfill all three requirements.

> As I said above, the other standard licenses (e.g. BSD, X) don't offer
> enough guarantees about the OCaml libraries and runtime themselves
> remaining open source.

Well,

nobody can "hide" the already existing code if it is under a BSD license.
X11, NetBSD, FreeBSD, OpenBSD ... still exist and are "Open Source"
although anyone is allowed to take the code, add features and
sell binary only versions. All those projects will live as long
as somebody cares about them and maintains them. Even if this
is not the case, the latest code will still remain "Open Source".
Even binary only versions will only succeed if the features added
are so overwhelmingly good that customers will buy it and accept
the fact that they won't get the source. If it is just "take the
source, modify it somewhat, compile it, and sell the binaries" -
nobody will buy that since there is always the Open Source implementation
available for free which can be easily modified to the needs.
Nobody can take away the original source anyway. So I can't see
any negative impact of using a BSD style license. But that is
of course the decision of the people owning the copyright.

Bye,
  Ronald
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Julian Assange]

> as BSD or X don't meet criterion 2.  Our current hope is that the LGPL
> with a special exception to paragraph 6 saying "you can link with our
> code any way you like" would fulfill all three requirements.

The {L,}GPL is itself copyright, and not under the {L,GPL}, so you can't do
this.

--
 Julian Assange        |If you want to build a ship, don't drum up people
                       |together to collect wood or assign them tasks and
 proff@iq.org          |work, but rather teach them to long for the endless
 proff@gnu.ai.mit.edu  |immensity of the sea. -- Antoine de Saint Exupery
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Xavier Leroy]

> > as BSD or X don't meet criterion 2.  Our current hope is that the LGPL
> > with a special exception to paragraph 6 saying "you can link with our
> > code any way you like" would fulfill all three requirements.
> 
> The {L,}GPL is itself copyright, and not under the {L,GPL}, so you can't do
> this.

Don't pull my leg.  Of course, the copyright owner can say "this code
is distributed under the conditions of the LGPL (quoted below in extenso),
with the special exception that ...".

Sheesh.  What next?  I can't shave because the FSF advocates beards?

- Xavier Leroy
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Xavier Leroy]

> I'm not pulling your leg. The LGPL does not accept modifications,
> and you can't take the Ocaml "distribute with patch" (to the license)
> approach, because the LGPL states the LGPL must cover the whole
> work or none of the work.

This last claim seems to be an excessive simplification of what's in
the LGPL.  At any rate, I maintain that what I'm proposing ("this is
distributed under the conditions of the LGPL with the special
exception that ...") is perfectly OK.  The GNAT project does exactly
this: GPL + special exception listed separately.

- Xavier Leroy
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Jérôme Marant]

Xavier Leroy wrote:

> This last claim seems to be an excessive simplification of what's in
> the LGPL.  At any rate, I maintain that what I'm proposing ("this is
> distributed under the conditions of the LGPL with the special
> exception that ...") is perfectly OK.  The GNAT project does exactly

Yes, you have perfectly the right to do that. Of course, the license
can no longer be called LGPL since it has been modified.

-- 
Jérôme Marant
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Greg Bacon]

In message <20011129093210.A19619@pauillac.inria.fr>,
    Xavier Leroy writes:

: > The {L,}GPL is itself copyright, and not under the {L,GPL}, so you can't do
: > this.
: 
: Don't pull my leg.  Of course, the copyright owner can say "this code
: is distributed under the conditions of the LGPL (quoted below in extenso),
: with the special exception that ...".
: 
: Sheesh.  What next?  I can't shave because the FSF advocates beards?

For a well-known counterexample, the Perl Kit is distributed either
under the terms of the Artistic License or the GPL.

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

Re: [Caml-list] License Conditions for OCaml

[Julian Assange]

> In message <20011129093210.A19619@pauillac.inria.fr>,
>     Xavier Leroy writes:
> 
> : > The {L,}GPL is itself copyright, and not under the {L,GPL}, so you can't do
> : > this.
> : 
> : Don't pull my leg.  Of course, the copyright owner can say "this code
> : is distributed under the conditions of the LGPL (quoted below in extenso),
> : with the special exception that ...".
> : 
> : Sheesh.  What next?  I can't shave because the FSF advocates beards?
> 
> For a well-known counterexample, the Perl Kit is distributed either
> under the terms of the Artistic License or the GPL.

This is not a counter example. "all of the work, or none of the work".


               Code
              /    \
            /        \
       GPLisation   Artification

At no stage does the Artistic License modify the GPL.

--
 Julian Assange        |If you want to build a ship, don't drum up people
                       |together to collect wood or assign them tasks and
 proff@iq.org          |work, but rather teach them to long for the endless
 proff@gnu.ai.mit.edu  |immensity of the sea. -- Antoine de Saint Exupery
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Greg Bacon]

In message <20011129230153.55D4D259D2@suburbia.net>,
    Julian Assange writes:

: > For a well-known counterexample, the Perl Kit is distributed either
: > under the terms of the Artistic License or the GPL.
: 
: This is not a counter example. "all of the work, or none of the work".
: 
: 
:                Code
:               /    \
:             /        \
:        GPLisation   Artification
: 
: At no stage does the Artistic License modify the GPL.

Dual licensing is an implicit modification of the GPL:

      5. You are not required to accept [the GPL], since you have not
    signed it.  However, nothing else grants you permission to modify or
    distribute the Program or its derivative works.  These actions are
    prohibited by law if you do not accept this License.  Therefore, by
    modifying or distributing the Program (or any work based on the
    Program), you indicate your acceptance of this License to do so, and
    all its terms and conditions for copying, distributing or modifying
    the Program or works based on it.

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

Re: [Caml-list] License Conditions for OCaml

[Florian Hars]

On Wed, Nov 28, 2001 at 07:22:39PM +0100, Xavier Leroy wrote:
> 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.

Be careful, this requirement, at least in the way it is worded here,
is in contradiction to the definition of free as used by the FSF and
adopting a licence the implements it would make OCaml incompatible 
with the GPL.

See http://www.gnu.org/philosophy/free-sw.html:
   "You should also have the freedom to make modifications and use them 
    privately in your own work or play, without even mentioning that 
    they exist."

Yours, Florian Hars.
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Daniel de Rauglaudre]

On Thu, Nov 29, 2001 at 09:31:58AM +0100, Florian Hars wrote:

> Be careful, this requirement, at least in the way it is worded here,
> is in contradiction to the definition of free as used by the FSF and
> adopting a licence the implements it would make OCaml incompatible 
> with the GPL.

The point is the LGPL, not the GPL. We don't want the GPL to contaminate
users programs.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Jérôme Marant]

Hi everyone,

  I've just subscribed to the list and I'm entering this interesting
  discussion. I'm sorry, I may have missed the previous messages.

  I know that OCaml is distributed under the QPL and this license
  is not GPL-compatible. This means that people (Ocaml program
  writers) cannot redistribute their programs under the GPL
  (they have to choose LGPL instead, for example).
  
  Some people came up with a dual-licensing solution. The most
  obvious examples are Perl and Qt.
  A dual QPL/GPL license for OCaml could solve the problem
  that is mentioned.

Daniel de Rauglaudre wrote:

> The point is the LGPL, not the GPL. We don't want the GPL to contaminate
> users programs.

  I think that freedom is the right to choose the licence for the
  software you write.

Cheers,

-- 
Jérôme Marant
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Xavier Leroy]

>   I've just subscribed to the list and I'm entering this interesting
>   discussion. I'm sorry, I may have missed the previous messages.
> 
>   I know that OCaml is distributed under the QPL and this license
>   is not GPL-compatible. This means that people (Ocaml program
>   writers) cannot redistribute their programs under the GPL
>   (they have to choose LGPL instead, for example).
>   
>   Some people came up with a dual-licensing solution. The most
>   obvious examples are Perl and Qt.
>   A dual QPL/GPL license for OCaml could solve the problem
>   that is mentioned.

Please read the licensing conditions for OCaml.  All parts that can be
linked with user's code (runtime, libraries) are distributed under the
LGPL, possibly with a future exception to clause 6 so that users can
link with this code without any additional requirements on their code.

The QPL covers only the OCaml compilers themselves -- and of course
not the code they generate.

> Daniel de Rauglaudre wrote:
> 
> > The point is the LGPL, not the GPL. We don't want the GPL to contaminate
> > users programs.
> 
>   I think that freedom is the right to choose the licence for the
>   software you write.

Precisely.  That's why, say, putting the libraries under the GPL would
be unacceptable; and even putting them under the LGPL (without
exceptions) isn't quite enough to achieve this goal.

- Xavier Leroy
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Jérôme Marant]

Xavier Leroy wrote:

> Please read the licensing conditions for OCaml.  All parts that can be
> linked with user's code (runtime, libraries) are distributed under the
> LGPL, possibly with a future exception to clause 6 so that users can
> link with this code without any additional requirements on their code.

You're correct.
So, you can confirm that I can ship my ocaml under the GPL?
 
> The QPL covers only the OCaml compilers themselves -- and of course
> not the code they generate.

  No offence but, what was the reason that made you choose the QPL
  for compilers?

> >   I think that freedom is the right to choose the licence for the
> >   software you write.
> 
> Precisely.  That's why, say, putting the libraries under the GPL would
> be unacceptable; and even putting them under the LGPL (without
> exceptions) isn't quite enough to achieve this goal.

  Because you would have forced people to use a GPL-compatible license.
  I can understand.

-- 
Jérôme Marant
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Daniel de Rauglaudre]

Hi,

On Thu, Nov 29, 2001 at 10:04:49AM +0100, Jérôme Marant wrote:

>   I know that OCaml is distributed under the QPL and this license
>   is not GPL-compatible. This means that people (Ocaml program
>   writers) cannot redistribute their programs under the GPL
>   (they have to choose LGPL instead, for example).

Not at all. I distribute GeneWeb (100% pure OCaml) under the GPL.
If you compile a C program with gcc, you are not obliged to distribute
it under the GPL. Compiler and user program are two different things.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Jérôme Marant]

Daniel de Rauglaudre wrote:
> 

> 
> Not at all. I distribute GeneWeb (100% pure OCaml) under the GPL.
> If you compile a C program with gcc, you are not obliged to distribute
> it under the GPL. Compiler and user program are two different things.

  This is not about compiling. This is about interpreting, i.e. when
  you need to run a program through an interpreter. This case is
  considered as dynamic linking and both the interpreter and the
  interpreted program must have compatible licenses.
  But as Xavier said, runtime programs are distributed under GPL,
  so this is no more problematic for me.

  Regards,

-- 
Jérôme Marant
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Xavier Leroy]

> On Wed, Nov 28, 2001 at 07:22:39PM +0100, Xavier Leroy wrote:
> > 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.
> 
> Be careful, this requirement, at least in the way it is worded here,
> is in contradiction to the definition of free as used by the FSF and
> adopting a licence the implements it would make OCaml incompatible 
> with the GPL.

I wasn't trying to draft a license, just getting the ideas across.  Of
course, private modifications are OK.  What I meant is a (L)GPL-like
condition: if you distribute (something that includes) the modified
runtime or libraries, the modifications themselves are free software
and distributed under the same conditions as the original.

- Xavier "awaiting the next hair to split" Leroy
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Sven]

On Wed, Nov 28, 2001 at 07:22:39PM +0100, Xavier Leroy wrote:
> John,
> 
> Thank you for your feedback -- it's very interesting to hear from an
> industrial user who got the opinions of competent lawyers.
> 
> Let me just state again what we'd like to achieve concerning the
> licensing of the OCaml runtime and libraries:
> 
> 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.
> 
> All three items are easy to justify: for 1, we don't want to bother
> anyone who uses OCaml; for 2, we'd like OCaml to remain open
> source, meaning that everyone should be able to benefit from the
> modifications on OCaml itself that someone did; and for 3, we're not
> competent for inventing yet another license and get it recognized as
> open source compliant.

Well, a 4th way would be to take the technical steps which would allow the
current licence to fullfill the 2 first requirements. Also i think it will be
very welcome for other purposes also ...

Also please consider all the implications before going ahead with it ...

> Now the problem is that apparently there is no existing license that
> matches these three criteria.  The LGPL was chosen before we realized
> all its implications w.r.t. static linking.  But popular licenses such
> as BSD or X don't meet criterion 2.  Our current hope is that the LGPL

Well, it is the silly requirement that guarantee's criterion 2, under other
things.

I have to go now, maybe we ca nfollow up on this discution at a later time ?

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

Re: [Caml-list] License Conditions for OCaml

[YAMAGATA yoriyuki]

I am not a member of the ocaml team also, nor the participants of
discussion you saw, but since I am planning to distribute something
under LGPL, how LGPL is interpreted is my concern.  So I would like to
add a point to Sven's summary.  (Sorry, I guess you are very busy, but
you may be concerned with interpretation of LGPL too.)

Many of the discussion you saw, is, it seems for me, related to
alleged ambiguity of the statement "provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications" in the beginning of the
section 6. of LGPL.  People are afraid that, in the end, this clause
forces developer to provide the source of their "work that uses the
Library", or something making reverse engineering easy (like unstriped
executable.)

How IBM lawyers think about this problem, is reported in
    http://caml.inria.fr/archives/200111/msg00440.html
as

From: "John Field" <jfield@us.ibm.com>
Subject: Re: [Caml-list] License Conditions for OCaml
Date: Tue, 27 Nov 2001 14:10:12 -0500

> IBM's lawyers have lots of experience dissecting the innards of
> various open- and quasi-open source licenses.  They are _very_ wary
> of the LGPL.  I won't attempt to explain or justify all of
> their concerns, some of which I don't fully understand.  However,
> their principal objections were to the clauses of the LGPL allowing
> "reverse engineering" of and "modifications" to the code.  The lawyers
> realize that the _intent_ of these clauses is probably benign.  However,
> the license provisions are so ambiguously worded (as ample discussion
> on this list has demonstrated) that the requirements it imposes on an
> implementer and the rights it grants to a user are very unclear.

May I ask you to clarify this problem?  Is it FAQ?

--
YAMAGATA, yoriyuki (doctoral student)
Department of Mathematical Science, University of Tokyo.
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Richard Stallman]

    Many of the discussion you saw, is, it seems for me, related to
    alleged ambiguity of the statement "provided that the terms permit
    modification of the work for the customer's own use and reverse
    engineering for debugging such modifications" in the beginning of the
    section 6. of LGPL.  People are afraid that, in the end, this clause
    forces developer to provide the source of their "work that uses the
    Library", or something making reverse engineering easy (like unstriped
    executable.)

I think this is much ado about nothing, since the LGPL explicitly says
it is sufficient to provide object files to the customer.  A court
would hardly adopt a strained interpretation of "modification for the
customer's own use" against that explicit statement.

But I will take a look at this--some day when I have time.
Unfortunately it can't be soon.  Other higher-priority issues
are ahead of it.
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Sven]

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

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.

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

Re: [Caml-list] License Conditions for OCaml

[Richard Stallman]

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

I thought the point was whether the requirements of the LGPL on
application developers were impractical to fulfill.  I'm explaining
that they are not impractical.

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

Exactly.  To get object files for one machine only is no more limiting
than to get the executable for one machine only.  Of course, it is a
bad thing if the application is non-free, and not just in a practical
sense.  But if the OCAML developers have already decided to allow
non-free applications to use the library--a decision I might agree
with--then we need not argue about whether these non-free applications
are good or bad.

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

Correct--it has a different license.  They might want to take a look
at that license.  Many variations on it can be made.
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Sven]

On Thu, Dec 06, 2001 at 08:12:06PM -0700, Richard Stallman wrote:
>     > 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 ? 
> 
> Correct--it has a different license.  They might want to take a look
> at that license.  Many variations on it can be made.

Is this licence acesible from somewhere apart the full gcc code ?

BTW, i suppose it is fully GPL/LGPL compatible and well recognized as free
software licence ?

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

Re: [Caml-list] License Conditions for OCaml

[Jacques Garrigue]

From: Sven <luther@dpt-info.u-strasbg.fr>

> Is [the libgcc] licence acesible from somewhere apart the full gcc code ?
> 
> BTW, i suppose it is fully GPL/LGPL compatible and well recognized as free
> software licence ?

It is just an exception to the GPL.

Here it is (from gcc-3.0.1/gcc/libgcc2.c):
GNU CC is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.

In addition to the permissions in the GNU General Public License, the
Free Software Foundation gives you unlimited permission to link the
compiled version of this file into combinations with other programs,
and to distribute those combinations without any restriction coming
from the use of this file.  (The General Public License restrictions
do apply in other respects; for example, they cover modification of
the file, and distribution when not linked into a combine
executable.)

This clause is often known as "modified GPL", and allows in fact more
than the LGPL.
But it looks like we made a different choice for ocaml, applying a
similar clause to the LGPL rather than the GPL. It avoids to have to
prove to everybody that the "modified GPL" is liberal enough...
Also, I wonder whether you can relicense under LGPL code released under
"modified GPL"? The wording does not say so, but the constraints are
similar.

Jacques Garrigue
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[hooh pxw]

The best thing in software/hardware, it is free & "technology-independent" just like my
body/soul/brain.

actually, if i don't need your help, it's the very pleasure/happiness to me.
but i dont need your help. i am stand alone.
now(19??~2001),i don't think computer seriously. 
computer is not more serious than liveness/eating/breathing/sleeping. 

if we help together for Right-thing. it also good, but the fear(try for un-free-things) is BAD.

after 4~5 days, we download vault, just like win95/win98/win2000.
anyway, humanity is devil.  
http://research.microsoft.com/vault/

computer is $ ware. computer do people think computer-way.
naked..
but i am not naked, i wear cloth that other ppl MADE.
i want my own hardware/software, i do not want /com-pu-ter/(their $, their ego, their destroy,
their silly fame, their stupidity ).......


__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com
-------------------
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

Re: [Caml-list] License Conditions for OCaml

[Sven]

On Tue, Dec 11, 2001 at 08:24:05AM +0900, Jacques Garrigue wrote:
> 
> This clause is often known as "modified GPL", and allows in fact more
> than the LGPL.
> But it looks like we made a different choice for ocaml, applying a
> similar clause to the LGPL rather than the GPL. It avoids to have to
> prove to everybody that the "modified GPL" is liberal enough...
> Also, I wonder whether you can relicense under LGPL code released under
> "modified GPL"? The wording does not say so, but the constraints are
> similar.

One could imagine simply dual licencing it under both the LGPL and the
modified GPL.

Anyway, i guess now the choice is for xavier and the rest of the ocaml team to
make, ...

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

Re: [Caml-list] License Conditions for OCaml

[Richard Stallman]

    > Correct--it has a different license.  They might want to take a look
    > at that license.  Many variations on it can be made.

    Is this licence acesible from somewhere apart the full gcc code ?

Sorry, you have to look in GCC.  I don't have the GCC source here.

    BTW, i suppose it is fully GPL/LGPL compatible and well recognized as free
    software licence ?

Yes, it is.
-------------------
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

RE: [Caml-list] License Conditions for OCaml

[Gregory Morrisett]

Why not make it illegal for a lawyer to read and/or interpret
the license?  That should solve most of the problems...

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