[Caml-list] CDK license

[Caml-list] CDK license

[Brian Rogoff]

I notice that the CDK license is GPL, rather than LGPL. I've read the 
discussions of GPL vs LGPL, and I'm not unsympathetic to the Free 
Software cause, but (speaking for myself here) as a commercial OCaml user 
I won't be able to use the CDK for this reason. So, for instance, I'll end
up grabbing lablgtk and PCRE directly from the source where their authors
chose to release it under LGPL, rather than using the CDK.

Was this a conscientious choice on the part of the CDK developers? If so, 
then perhaps Caml Consortium members should think about creating a less 
encumbered "standard" library. It would be a pity to have to duplicate 
this effort. 

-- Brian


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

Re: [Caml-list] CDK license

[rbw3]

If my understanding is correct, the CDK library being under GPL is
different then what you think. All that means it that the tools that they
use to put the library together are GPL, not that the software you develop
with the CDK is GPL.

A huge example of this is the GCC suite.

--Brock

On Wed, 30 May 2001, Brian Rogoff wrote:

| I notice that the CDK license is GPL, rather than LGPL. I've read the 
...
| -- Brian
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] CDK license

[Jacques Garrigue]

> I notice that the CDK license is GPL, rather than LGPL. I've read the 
> discussions of GPL vs LGPL, and I'm not unsympathetic to the Free 
> Software cause, but (speaking for myself here) as a commercial OCaml user 
> I won't be able to use the CDK for this reason. So, for instance, I'll end
> up grabbing lablgtk and PCRE directly from the source where their authors
> chose to release it under LGPL, rather than using the CDK.

On the same line of thought, the ocaml compiler is released under the
QPL, which is not compatible with the GPL.
This means that you cannot build a toplevel including any library
under the GPL, since it would be in contradiction with either of the
two licenses.
At the very least, it seems necessary to add a clause to the GPL,
saying that linking to QPLed libraries is allowed, just as RMS himself
suggested for KDE software.

Another remark is that lablgtk-1.2.0 contains a COPYING file, saying
that the library itself is LGPL, examples are more or less public
domain, and applications are _not_ open source. Claiming that all this
is GPL is clearly wrong. This COPYING is not there, and no README file
either, which is the only documentation for lablgtk :-)

(This is not a rant: I am the one who didn't check)

Best regards,

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

Re: [Caml-list] CDK license

[Brian Rogoff]

On Thu, 31 May 2001, Jacques Garrigue wrote:
> On the same line of thought, the ocaml compiler is released under the
> QPL, which is not compatible with the GPL.
> This means that you cannot build a toplevel including any library
> under the GPL, since it would be in contradiction with either of the
> two licenses.
> At the very least, it seems necessary to add a clause to the GPL,
> saying that linking to QPLed libraries is allowed, just as RMS himself
> suggested for KDE software.

At this point, I'd suggest that we _really_ need to consult a lawyer who
is familiar with intellectual property law and the GPL. 

As far as libraries go, I think the LGPL is a fair compromise between the 
really dedicated RMS followers (once affectionately referred to as
"license ayatollahs" on this very list :) and those who are willing to
tolerate a variety of kinds of software, including proprietary. I
understand the reasons for going GPL instead of LGPL ("resistance is
futile, prepare to be assimilated, or don't use this code") but if it's 
going to be that way then I don't want my Consortium dues to fund work
on the CDK. 

> Another remark is that lablgtk-1.2.0 contains a COPYING file, saying
> that the library itself is LGPL, examples are more or less public
> domain, and applications are _not_ open source. Claiming that all this
> is GPL is clearly wrong. This COPYING is not there, and no README file
> either, which is the only documentation for lablgtk :-)
> 
> (This is not a rant: I am the one who didn't check)

It's a tricky business, this license stuff, and a lot less fun than coding ;-).

-- Brian

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

Re: [Caml-list] CDK license

[Fabrice Le Fessant]

I didn't care a lot about the COPYING file when releasing the
CDK. However, the COPYING file included in the CDK root directory
contains a header specifying that it only applies to directories where
no other LICENCE/COPYING file is present. I will try to add to all
directories their previous LICENCE file if different from the root
one, so that everyone is happy. Maybe we will also move the root one
to LGPL if it is really a problem.

Best regards,

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

Re: [Caml-list] CDK license

[John Max Skaller]

Brian Rogoff wrote:
> 
> I notice that the CDK license is GPL, rather than LGPL.

I imagine this constraint was forced upon CDK because
some of the components of the CDK are GPL.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] CDK license

[Sven LUTHER]

On Thu, May 31, 2001 at 01:05:00AM +0000, rbw3@cet.nau.edu wrote:
> 
> If my understanding is correct, the CDK library being under GPL is
> different then what you think. All that means it that the tools that they
> use to put the library together are GPL, not that the software you develop
> with the CDK is GPL.
> 
> A huge example of this is the GCC suite.

No, it is not, since the CDK contains a bunch of libraries, which have to be
linked with the code, and as thus make the final product GPled also.

While gcc does not such thing, only process the code.

There could be an analogy with glibc though, which is GPLed.

Friendly,

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

Re: [Caml-list] CDK license

[Sven LUTHER]

On Wed, May 30, 2001 at 08:11:56PM -0700, Brian Rogoff wrote:
> On Thu, 31 May 2001, Jacques Garrigue wrote:
> > On the same line of thought, the ocaml compiler is released under the
> > QPL, which is not compatible with the GPL.
> > This means that you cannot build a toplevel including any library
> > under the GPL, since it would be in contradiction with either of the
> > two licenses.
> > At the very least, it seems necessary to add a clause to the GPL,
> > saying that linking to QPLed libraries is allowed, just as RMS himself
> > suggested for KDE software.
> 
> At this point, I'd suggest that we _really_ need to consult a lawyer who
> is familiar with intellectual property law and the GPL. 

First, i am no lawyer, but as debian developper, and packager of ocaml and
some other ocaml stuff for debian, i have been exposed to this kind of stuff a
lot, so here is my opinion on it.

> As far as libraries go, I think the LGPL is a fair compromise between the 
> really dedicated RMS followers (once affectionately referred to as
> "license ayatollahs" on this very list :) and those who are willing to
> tolerate a variety of kinds of software, including proprietary. I
> understand the reasons for going GPL instead of LGPL ("resistance is
> futile, prepare to be assimilated, or don't use this code") but if it's 
> going to be that way then I don't want my Consortium dues to fund work
> on the CDK. 

Yes, the LGPL is a good choice, but still it has some problems with regard to
ocaml programs/libraries.

I think the important part is article 5. of the LGPL :

------------------------------------------------------------------
  5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library".  Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.

  However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library".  The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.

  When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library.  The
threshold for this to be true is not precisely defined by law.

  If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object
file is unrestricted, regardless of whether it is legally a derivative
work.  (Executables containing this object code plus portions of the
Library will still fall under Section 6.)

  Otherwise, if the work is a derivative of the Library, you may
distribute the object code for the work under the terms of Section 6.
Any executables containing that work also fall under Section 6,
whether or not they are linked directly with the Library itself.
------------------------------------------------------------------

What all this is about is that you can do dynamic linking with the library and
not release your program source code.

That said, ocaml is not a dynamic linking language yet, and as such i don't
know up to what point the :

  only numerical parameters, data structure layouts and accessors, and small
  macros and small inline functions (ten lines or less in length).

Could be related to the way ocaml uses modules and do linking. Could someone
more familiar with the ocaml binaries internal give more light here ?

Now, there are 2 possibilities :

  1) We consider that the ocaml modules and linking stuff is considered such as
     Article 5 requires. Then there is no problem, and we can use the LGPL
     without major problem. But it would be nicer, when giving a LGPL license
     to your code, to make it clear that we consider it as such, saying for
     example :

     "This code is covered by the LGPL. Notice that we consider the ocaml
     linking and modules hadnling as consisting of only numerical ..."

   2) Ocaml linking is more than just the above. Then you can still solve it
      by :

     2.1) state in the license that you make an exception for ocaml linking,
     something like :

     "This code is covered by the LGPL with the additional permision that you
     may use the object file in an unrestricted manner, when linking to other
     ocaml objects."
     
     2.2) comply with article 6 a), which says that you must also provide a
     complete machine readeable version of your program (the .cm* files) so
     that the user can modify the library and relink the program with the
     modified library. Now you don't need to distribute the files, you can
     resort to make them available (for at least 3 years) in either a
     downloadeable place, or in sending it for a cgharge no more than the cost
     of distirbution to anyone who request it. 


And naturaly, don't forget that you can issue any code with any number of
licences that you want, provided _all_ the authors agree on it. If you plan to
do so, best is to check with the consent of anyone who makes contributions to
your work, before integrating the patches. Or keep a dual source tree, as was
done with mozilla/netscape and some others.

Ok, that is most of what i have read from the LGPL stuff, and which applies to
ocaml. 

> > Another remark is that lablgtk-1.2.0 contains a COPYING file, saying
> > that the library itself is LGPL, examples are more or less public
> > domain, and applications are _not_ open source. Claiming that all this
> > is GPL is clearly wrong. This COPYING is not there, and no README file
> > either, which is the only documentation for lablgtk :-)
> > 
> > (This is not a rant: I am the one who didn't check)

erm, ...

1) about the public domain examples, best would be to add a COPYING file there
stating it, because public domain is less restrictive than the LGPL.

2) about the application not being open source, what are they. I cannot
possibly continue to include them in the debian package if their license
situation is not clarified. Will they come under a closed source licence ? If
yes, why, does it make any sense to do so ?

3) IANAL, but it seems to me that since you shipped lablgtk claiming that all
of it is LGPLed, at least the versions that where such released are released
under the LGPL, you cannot go back. You can change the licence though, but i
guess anyone could continue work on the LGPLed version of it. I could be
speaking nonsense though, i did not check the exact wording of it.

Friendly,

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

Re: [Caml-list] CDK license

[Sven LUTHER]

On Wed, Jun 06, 2001 at 09:05:26AM +0200, Sven LUTHER wrote:
> On Thu, May 31, 2001 at 01:05:00AM +0000, rbw3@cet.nau.edu wrote:
> > 
> > If my understanding is correct, the CDK library being under GPL is
> > different then what you think. All that means it that the tools that they
> > use to put the library together are GPL, not that the software you develop
> > with the CDK is GPL.
> > 
> > A huge example of this is the GCC suite.
> 
> No, it is not, since the CDK contains a bunch of libraries, which have to be
> linked with the code, and as thus make the final product GPled also.
> 
> While gcc does not such thing, only process the code.
> 
> There could be an analogy with glibc though, which is GPLed.

Err sorry, the glibc is naturally LGPLed. the LGPL was coined for it after
all, but later on, RMS changed the name of it from GNU Library Public Licence
to Leaser GNU Public Licence, and discourages it's use.

Friendly,

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

Re: [Caml-list] CDK license

[reig]

There is now a FAQ list about the GNU licences.

http://www.gnu.org/copyleft/gpl-faq.html

Fermin

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

Re: [Caml-list] CDK license

[Sven LUTHER]

On Wed, Jun 06, 2001 at 09:36:58AM +0100, reig@dcs.gla.ac.uk wrote:
> There is now a FAQ list about the GNU licences.
> 
> http://www.gnu.org/copyleft/gpl-faq.html
> 

Sure, i know about it, altough i have not read it fully.

Does it say anything which may be usefull to the LGPL + ocaml question ?

 From a quick glance, it appears that this is not the case.

Friendly,

Sven Luther


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

[Caml-list] question about modules

[Mark Wotton]

Hello,

I'm using the translation of Chris Okasaki's code that Markus Mottl has
provided, and I've got a question about the way modules work. I had
assumed that it worked in a similar way to lists: ie, i write "int list",
i'd assumed I'd do something similar with Deques, "int Deque" for
instance. Obviously this doesn't work: I understand that once I've added
an element to a Deque, the polymorphic type is fixed, so there's no
worries about type safety there; however, I had something like this:


type tree = CompTree of tree list * tree list;;

before I realised that I needed deques. It would seem that the translation
is to

type tree = CompTree of Deque * Deque;;

but it worries me a little that I'm no longer explicitly showing the
recursive structure of my tree in my data type. Am I worrying
unnecessarily? Is there a way around this problem, if it is a problem?

Regards,

Mark



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

Re: [Caml-list] question about modules

[Markus Mottl]

On Wed, 06 Jun 2001, Mark Wotton wrote:
> I'm using the translation of Chris Okasaki's code that Markus Mottl has
> provided, and I've got a question about the way modules work. I had
> assumed that it worked in a similar way to lists: ie, i write "int list",
> i'd assumed I'd do something similar with Deques, "int Deque" for
> instance. Obviously this doesn't work: I understand that once I've added
> an element to a Deque, the polymorphic type is fixed, so there's no
> worries about type safety there; however, I had something like this:

I assume you have created a module "Deque" using one of the functors in
chapter 8, e.g.:

  module Deque = RealTimeDeque (struct let c = 3 end)

As you can see from the signature restrictions used in the functor head of
"RealTimeDeque", this functor generates modules that match the signature
"DEQUE":

  module RealTimeDeque (C : sig val c : int end) : DEQUE

Therefore, we have to look at this signature to see, what options we
have to use deques:

---------------------------------------------------------------------------
module type DEQUE = sig
  type 'a queue

  val empty : 'a queue
  val is_empty : 'a queue -> bool

  (* insert, inspect, and remove the front element *)
  val cons : 'a -> 'a queue -> 'a queue
  val head : 'a queue -> 'a        (* raises Empty if queue is empty *)
  val tail : 'a queue -> 'a queue  (* raises Empty if queue is empty *)

  (* insert, inspect, and remove the rear element *)
  val snoc : 'a queue -> 'a -> 'a queue
  val last : 'a queue -> 'a        (* raises Empty if queue is empty *)
  val init : 'a queue -> 'a queue  (* raises Empty if queue is empty *)
end
---------------------------------------------------------------------------

Obviously, the type used to refer to deques must be:

  'a Deque.queue

> type tree = CompTree of tree list * tree list;;
> 
> before I realised that I needed deques. It would seem that the translation
> is to
> 
> type tree = CompTree of Deque * Deque;;

Thus, you'll have to write:

  type tree = CompTree of tree Deque.queue * tree Deque.queue

If it bothers you to write so much, you can also define a type synonym
for deques:

  type 'a deque = 'a Deque.queue

and use it instead:

  type tree = CompTree of tree deque * tree deque

This is probably the most intuitive version.

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] question about modules

[Mark Wotton]

Thank you very much for your informative replies. I understand more
clearly now, I think.

I have one more question to do with patternmatching on modules.

Currently, I have this:

module Deque = RealTimeDeque(struct let c = 3 end);;
type 'a deque = 'a Deque.queue

type tree = CompTree of tree deque * tree deque;;

let dcons = Deque.cons;;
let dhead = Deque.head;;
let dtail = Deque.tail;;

let dsnoc = Deque.snoc;;
let dlast = Deque.last;;
let dinit = Deque.init;;

...

let rec lastTree t acc = 
        match t with 
(*              CompTree(Deque.empty, d2) -> acc *)
        
                CompTree(d1,d2) ->
                        let newTree = CompTree(dinit d1,
                                               dcons (dhead d1) d2)
                        in lastTree newTree (newTree::acc)


I'd like to match the empty Deque, but this gives me a syntax error when i
uncomment the third line. What should I be doing here?

Apologies for asking so many simple/silly questions. I'm still coming to
grips with Ocaml.

Regards,
Mark


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