[Caml-list] Announce: Schoca-0.2.3 released

[Caml-list] Announce: Schoca-0.2.3 released

[Christoph Bauer]

Hi Caml-list,

Schoca is an implementation of the Scheme language. The primary
purpose of Schoca is the use as an embedded extension language in
OCaml applications.

The new release 0.2.3 fixes a lot of bugs and the interpreter is
now faster. scmTypes.mli lists all scheme-data specific functions.

An init file for slib is included (example/schoca.init). (slib:report)
works but not much more. This will be improved.

The new location of Schoca's  homepage is

http://home.arcor.de/chr_bauer/schoca.html

Have fun with functional programming,
Christoph Bauer

P.S.:

Changes for 0.2.3
   o (define (f) 1)-Bug is fixed
   o wrong parsing of a the string like "...\\" is fixed
   o no termination of schoca shell when an exception occurs
   o getenv returns #f on unset vars
   o a lot of string functions (which uses string_of_datum instead od string_of_scm_string) are fixed
   o (load (...)) is fixed (missing eval)
   o parsing of symbols (or numbers) starting with a dot (`.') is fixed
   o examples/schoca.init for slib is included 
           (install slib 3a1, 
            setenv SCHEME_LIBRARY_PATH
            run (load "schoca.init"))
   o cond bugs are fixed
   o scm_eval (evaluation of arguments) is fixed

Changes for 0.2.2:
   o much faster function calls (ack.scm 8.3s -> 5.9s)

Changes for 0.2.1 (not released)

   o Fix for eq? on numbers.
   o `truncate' is added
   o documentation for ScmTypes
   o some functions are renamed




-- 
let () = let rec f a w i j = Printf.printf "%.20f\r" a; let a1 = a *. i /. j in
if w then f a1 false (i +. 2.0) j else f a1 true i (j +. 2.0) in f 2.0 false 2.0 1.0


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

Re: [Caml-list] Announce: Schoca-0.2.3 released

[skaller]

On Sun, 2004-10-24 at 19:03, Christoph Bauer wrote:
> Hi Caml-list,
> 
> Schoca is an implementation of the Scheme language. The primary
> purpose of Schoca is the use as an embedded extension language in
> OCaml applications.

It would be useful when making an anouncement if you could
specify the licence. This saves wasting time. 

On the home page it says:

"This software is free for free software. It is released under the GPL."

Hmm. So if I link it against the Ocaml standard libraries,
they have to be GPL'd too. But they're not ..

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



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

Re: [Caml-list] Announce: Schoca-0.2.3 released

[David Brown]

On Mon, Oct 25, 2004 at 04:29:59AM +1000, skaller wrote:

> It would be useful when making an anouncement if you could
> specify the licence. This saves wasting time. 
> 
> On the home page it says:
> 
> "This software is free for free software. It is released under the GPL."
> 
> Hmm. So if I link it against the Ocaml standard libraries,
> they have to be GPL'd too. But they're not ..

What???  I know your distaste for the GPL, but there is no incompatibility
between the Ocaml standard libraries and a GPL'd program.  The Ocaml
libraries are LGPL with a special exception that lets you build executibles
using them, unrestricted.

The GPL is not an infectious agent.  It may be incompatible with some
libraries, but it doesn't contaminate other code, other than encouraging
people to put their own code under the GPL.

Or are you referring to some other "standard libraries"?

BTW, Christoph, the GPL seems to fit well with your stated goals.

Dave

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

Re: [Caml-list] Announce: Schoca-0.2.3 released

[Jacques Garrigue]

From: David Brown <caml-list@davidb.org>
> On Mon, Oct 25, 2004 at 04:29:59AM +1000, skaller wrote:
> 
> > It would be useful when making an anouncement if you could
> > specify the licence. This saves wasting time. 
> > 
> > On the home page it says:
> > 
> > "This software is free for free software. It is released under the GPL."
> > 
> > Hmm. So if I link it against the Ocaml standard libraries,
> > they have to be GPL'd too. But they're not ..
> 
> What???  I know your distaste for the GPL, but there is no incompatibility
> between the Ocaml standard libraries and a GPL'd program.  The Ocaml
> libraries are LGPL with a special exception that lets you build executibles
> using them, unrestricted.

I was going to make the same answer...

However, when releasing libraries for ocaml, it may be useful to
remember that while ocaml's runtime and libraries are
LGPL(+exception),  the compiler, and as a result the toplevel, is QPL,
and that the QPL happens to be incompatible with the GPL.
In practice, this means that you cannot distribute a toplevel
including a GPL library.

On the other hand, there should be no problem loading manually a
GPL library in the toplevel, or building such a toplevel privately.
(At least I believe so, but questions of dynamic loading are the
muddiest part of the GPL and the QPL.)

Jacques Garrigue

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

Re: [Caml-list] Announce: Schoca-0.2.3 released

[David Brown]

On Mon, Oct 25, 2004 at 12:38:34PM +0900, Jacques Garrigue wrote:

> On the other hand, there should be no problem loading manually a
> GPL library in the toplevel, or building such a toplevel privately.
> (At least I believe so, but questions of dynamic loading are the
> muddiest part of the GPL and the QPL.)

The GPL only coveres distribution, not execution.  GPL code can be linked
with even proprietary code as long as the result isn't distributed at all.

Dave

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

Re: [Caml-list] Announce: Schoca-0.2.3 released

[skaller]

On Mon, 2004-10-25 at 12:58, David Brown wrote:
> On Mon, Oct 25, 2004 at 04:29:59AM +1000, skaller wrote:
> 
> > It would be useful when making an anouncement if you could
> > specify the licence. This saves wasting time. 
> > 
> > On the home page it says:
> > 
> > "This software is free for free software. It is released under the GPL."
> > 
> > Hmm. So if I link it against the Ocaml standard libraries,
> > they have to be GPL'd too. But they're not ..
> 
> What???  

I'm wrong, LGPL specifically allows change of licence to GPL.
Sorry.

> The GPL is not an infectious agent. 

Read this, taken from the OSI hosted copy of GPL:

"b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any part
thereof, to be licensed as a whole at no charge to all third parties
under the terms of this License."

In addition, the binary is GPL no matter how you package things,
and then:

"c) If the modified program normally reads commands interactively when
run, you must cause it, when started running for such interactive use in
the most ordinary way, to print or display an announcement including an
appropriate copyright notice ...." [meaning, GPL]


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



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

Re: [Caml-list] Announce: Schoca-0.2.3 released

[David Brown]

On Mon, Oct 25, 2004 at 03:18:09PM +1000, skaller wrote:

> I'm wrong, LGPL specifically allows change of licence to GPL.
> Sorry.

Allows, but not requires.

> > The GPL is not an infectious agent. 
> 
> Read this, taken from the OSI hosted copy of GPL:
> 
> "b) You must cause any work that you distribute or publish, that in
> whole or in part contains or is derived from the Program or any part
> thereof, to be licensed as a whole at no charge to all third parties
> under the terms of this License."

If the other files are already under a license that is more liberal than
the GPL, the license of those files does not have to change in order for
the whole to be licensed.  I've not, until now ever heard that this was the
case.  The authors of the GPL certainly do not intend this.

If I receive a GPL'd program, I must be able to at least do all of the
things that the GPL requires I be able to do.  However, some of the files
in the GPL may be covered under more liberal license, and I am free to take
those modules and do these more liberal things with them.

> In addition, the binary is GPL no matter how you package things,
> and then:

Yes.  That is the point.  That you find the GPL annoying for the reasons
you do does mean it has made its point.

Dave

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

Re: [Caml-list] licence stuff again

[skaller]

On Mon, 2004-10-25 at 13:38, Jacques Garrigue wrote:

> On the other hand, there should be no problem loading manually a
> GPL library in the toplevel, or building such a toplevel privately.

This may be so (you can surely do anything you like privately,
since licences based on Copyright only apply to redistribution).

However, it is a pain that legal matters interfere 
with the technical design of software. The very same
program that is fine when you use dynamic linkage
may be be not fine when you statically link, for example.

The problem here is that we have a community of amateurs,
hobbyists, acadamics, and a couple of specialist commerical
companies and we all like different licences but don't
really care because either (a) we're not deriving income
from our effort, we're doing it for fun or academic
brownie points, and/or (b) our income is secure, and
we have no need to actually sell our product.

On the other hand the C++ community is mainly composed
of commerical programmers -- people making a living
out of cutting code. And even the vendors of libraries
and compilers have a vested interest in uniformity
both technical and legal. So right from the start,
Boost required software to be unencumbered, and now
there is a movement to formalise that with a single
licence.

So despite the inferior quality of the C++ platform,
C++ people have large benefit from free exchange of
reusable components which the Ocaml community continually
denies itself because everyone seems to have some pointless
political statement to make (including me :)

We're *never* going to agree on a common restrictive licence,
so there's only one possible way forward: an unrestrictive one.

Most Ocaml people have no reason to fear being generous --
they're not going to lose any income. The people with
most to lose -- commercial C++ programmers -- have shown
that being generous actually works. Everyone benefits.

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



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

Re: [Caml-list] Announce: Schoca-0.2.3 released

[skaller]

On Mon, 2004-10-25 at 15:29, David Brown wrote:

> Yes.  That is the point.  That you find the GPL annoying for the reasons
> you do does mean it has made its point.

What, that dividing a small community and discouraging
reuse is a good thing?

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



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

Re: [Caml-list] Announce: Schoca-0.2.3 released

[Jacques Garrigue]

From: David Brown <caml-list@davidb.org>
> > On the other hand, there should be no problem loading manually a
> > GPL library in the toplevel, or building such a toplevel privately.
> > (At least I believe so, but questions of dynamic loading are the
> > muddiest part of the GPL and the QPL.)
> 
> The GPL only coveres distribution, not execution.  GPL code can be linked
> with even proprietary code as long as the result isn't distributed at all.

That's why I call it muddy. The FSF (who wrote the GPL) insists that
dynamic linking creates a derivative work, while in that case the
linking only occurs at execution. And this makes sense, because
otherwise the GPL would say nothing more than the LGPL.
Now, it could be argued that when you load code into the toplevel,
this is not the toplevel that is using the code (it has no dependency
on it). But this kind of argument can turn very subjective.

Note also that the above problem is between the GPL and the QPL, which
includes its own requirements.
If you distribute a small modification of a GPLed library that uses some
functions of the toplevel, but only when you link it with the
toplevel, then (incompatible) requirements of both the GPL and the QPL
will apply to this code. Confusing.

Jacques Garrigue

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

Re: [Caml-list] Announce: Schoca-0.2.3 released

[skaller]

On Mon, 2004-10-25 at 16:08, Jacques Garrigue wrote:

> That's why I call it muddy. The FSF (who wrote the GPL) insists that
> dynamic linking creates a derivative work, while in that case the
> linking only occurs at execution. And this makes sense, because
> otherwise the GPL would say nothing more than the LGPL.
> Now, it could be argued that when you load code into the toplevel,
> this is not the toplevel that is using the code (it has no dependency
> on it). But this kind of argument can turn very subjective.

Of course. As can any attempt for law, legislation, or authority
to try to make distinctions between things that no sane programmer
would distinguish.

It's like trying to teach people the difference between a 
compiler, translator and interpreter. In the end the good teacher
knows it's only a vague distinction to help thinking, and the
good student soon learns the teacher was telling a white lie.
They're just all programs.

So too, trying to distinguish 'source code' from 'binary'
and even say specifically what 'linking' means is all 
plainly power politics with no technical merit.

Mathematically, it's all just coding.

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



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

Re: [Caml-list] Announce: Schoca-0.2.3 released

[Ville-Pertti Keinonen]

David Brown wrote:

>The GPL only coveres distribution, not execution.  GPL code can be linked
>with even proprietary code as long as the result isn't distributed at all.
>  
>
This is getting fairly offtopic, but I thought it might be worth 
mentioning that this is not quite so clear-cut.

While you're essentially correct, the above could also be interpreted to 
mean that you can get around the GPL by having the end-user link 
GPL-incompatible software against a GPL component.  According to RMS, 
this is not acceptable, even for a minor, optional component (he 
demanded that CLISP change its licensing due to the optional ability to 
link against GNU readline; the author changed to GPL).

On the other hand, a similar practice is commonly accepted for Linux 
kernel modules.

Consider a situation where someone created a compatible but non-GPL 
replacement for some major GPL library, and GPL-incompatible software 
that could be linked against that library...or the original GPL 
library.  Lets say the original GPL library is sufficiently better that 
most users link against it.

The above could be extended to turn any GPL program into a library 
first, then create a crappy compatible library...

I really don't know what the legal interpretation of that would be.

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

Re: Announce: Schoca-0.2.3 released

[Stefan Monnier]

>> The GPL only coveres distribution, not execution.  GPL code can be linked
>> with even proprietary code as long as the result isn't distributed at all.
> This is getting fairly offtopic, but I thought it might be worth mentioning
> that this is not quite so clear-cut.

Indeed.  The issue is that if you use functions which can only be provided
by GPL'd code, then you've basically linked your code to GPL'd code, whether
the linking happens before or after distribution.
Basically, it's like the GPL extends to the API.

> On the other hand, a similar practice is commonly accepted for Linux
> kernel modules.

But that's only because Linus expressly said so publically (which has legal
significance similar to annotating the COPYING file in the distribution to
make an explicit exception).  And note that Linus's position on this has
evolved over time and nowadays the kernel has introduced a distinction
between GPL'd and non-GPL'd modules (where some functions are only made
available to GPL'd modules), because non-GPL'd modules were useful to Linux
in the past, but now that Linux's market position is sufficiently strong it
can require GPL'd modules.

> Consider a situation where someone created a compatible but non-GPL
> replacement for some major GPL library, and GPL-incompatible software that
> could be linked against that library...or the original GPL library.
> Lets say the original GPL library is sufficiently better that most users
> link against it.

> The above could be extended to turn any GPL program into a library first,
> then create a crappy compatible library...

> I really don't know what the legal interpretation of that would be.

Following the GMP precedent (GMP was a GPL library and someone wanted to use
it in a non-GPL product), the FSF managed to require the company to write
the crappy implementation "fgmp" but was then satisfied.
I.e. there's a clear precedent that shows you *can* indeed use the trick of
writing a crappy compatible library.  Note that writing crappy compatible
library can be a non-negligible amount of work, tho, because it has to be at
least somewhat functional to be of any significance.  At that point most
people prefer to write a custom-made library without the need to stick to
a preexisting API, or else they change the license on their code to be
compatible with the GPL.


        Stefan

Re: [Caml-list] Announce: Schoca-0.2.3 released

[skaller]

On Mon, 2004-10-25 at 18:00, Ville-Pertti Keinonen wrote:

> I really don't know what the legal interpretation of that would be.

I do: creating a compatible component without actually
deriving from GPL sources doesn't breach copyright. In particular,
complying to an interface just by itself cannot breach copyright.

So, for example, a program which was able to accept
readline -- and is able to do so *without* reading any
GPL headers and *without* reading a header derived from
it -- doesn't have to be GPL.

This has nothing to do with what Stallman wants, it's
a universal property of Copyright.

So the code *before* linkage against readline doesn't
need to be GPL. Once linked against readline the result
probably does have to be GPL.

There is actually an example of this: Python. 
The top level interpreter does use readline.
Yet Python sources definitely aren't GPL.

The actual binary, when linked against readline,
probably is. So if you install Python with an RPM,
its a GPL version you have installed. If you use
the tarball the source isn't GPL, but as with the RPM
the binary is.

I don't see that linking statically or dynamically
makes a difference .. except for the amusing situation
that if you actually used dlopen and a shared library,
the licence would change dynamically as you loaded
and unloaded the library . :)))

Oh .. Python doesn't display the GPL licence interactively .. 
even with readline linked in .. (which is probably a breach
of the GPL of readline)

If you have Python installed, type 'license()' in the top
level .. it's quite interesting.

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

Re: [Caml-list] Re: Announce: Schoca-0.2.3 released

[skaller]

On Tue, 2004-10-26 at 00:35, Stefan Monnier wrote:

> Following the GMP precedent (GMP was a GPL library and someone wanted to use
> it in a non-GPL product), the FSF managed to require the company to write
> the crappy implementation "fgmp" but was then satisfied.

Sounds like a con job. I can write code that requires
a GMP compatible library and FSF can't do anything about
how I licence my code -- provided I don't actually
derive any of my code from GPL'd code.

> I.e. there's a clear precedent that shows you *can* indeed use the trick of
> writing a crappy compatible library. 

The real problem is that to make your
code work properly with GMP or other library you need to
provide an interface. It isn't so easy to do that without
'deriving' from a published specification -- either the actual
headers or the documentation. You have to use the same
function names and equivalent types, and to get that right
you pretty much have to derive from the spec.

I have no idea how to do that without coming under
the control of the licence for the spec .. but if you
do manage to do so, the ability to link to the implementation
can't possibly be relevant .. unless perhaps you test
your code against it, and make bug fixes, in which case
those fixed codes just might be deemed derived works.

As it happens, Felix has a wrapper for the C++ wrapper
for GMP, and it is FFAU and not GPL because the interface
is 'the usual math operators'. I also ship a wrapper
generator that can wrap code like GMP to make it available
under Felix. Those wrappers are derived, and so they're
GPL .. but I don't ship them, only the tool that creates them.

It's not clear including such wrappers in a Felix program
requires it to be GPL either. That's because Felix has
an advanced source code linker that only instantiates
used code .. so you can have the capability there,
and perhaps your whole source is infected .. but if you
don't actually call GMP the resultant program is
no longer GPL :) Umm . what .. lol!

Which all comes back to the stupidity of trying to define
what using/linking/combining/distributing/ etc etc actually
mean. The answer is -- nothing at all, outside of existing
practice used for C programs. Interscript/Felix/Flxcc (the latter
is the wrapper generator) approach the problem in such a 
novel way that the terms of the GPL are meaningless.

For example .. the wrapper generator creates a derived
work .. but it fails to include the licence of the original
work in the generated wrappers. Is it breaching GPL?
Of course not -- its the *client* who uses it that is at risk.

Well, perhaps your /usr/include contains some code licenced
with a license incompatible with GPL .. but flxcc wraps
the *whole* of /usr/include in one go. The resultant
product is derived from all of it simultaneously.
So is it actually legal to run the tool at all??

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

Re: [Caml-list] Re: Announce: Schoca-0.2.3 released

[Stefan Monnier]

> Which all comes back to the stupidity of trying to define what
> using/linking/combining/distributing/ etc etc actually mean.

Laws are not a formal system.  Inconsistency and interpretation is the whole
reason why there are lawyers and lawsuits.

The *intent* of the GPL is quite relevant in court,


        Stefan

Re: [Caml-list] Announce: Schoca-0.2.3 released

[David Brown]

On Mon, Oct 25, 2004 at 11:00:09AM +0300, Ville-Pertti Keinonen wrote:

> While you're essentially correct, the above could also be interpreted to 
> mean that you can get around the GPL by having the end-user link 
> GPL-incompatible software against a GPL component.  According to RMS, 
> this is not acceptable, even for a minor, optional component (he 
> demanded that CLISP change its licensing due to the optional ability to 
> link against GNU readline; the author changed to GPL).

RMS has changed his position on this, and, I believe, is going beyond what
the GPL states to apply pressure for others to change their license.

Dave

Re: [Caml-list] Announce: Schoca-0.2.3 released

[Hartmann Schaffer]

Ville-Pertti Keinonen wrote:

> While you're essentially correct, the above could also be interpreted 
> to mean that you can get around the GPL by having the end-user link 
> GPL-incompatible software against a GPL component.  According to RMS, 
> this is not acceptable, even for a minor, optional component (he 
> demanded that CLISP change its licensing due to the optional ability 
> to link against GNU readline; the author changed to GPL).


iirc (haible had the history on one of his websites, it probably is 
still there, but i don't remember the URL) you could chose whether to 
include readline when you built clisp (from sources).  so he was 
distributing something that, based on build options was linked with a 
gpled library.  it had nothing to do with dynamic linking

>
> ...

hs

Re: [Caml-list] Announce: Schoca-0.2.3 released

[Sven Luther]

On Mon, Oct 25, 2004 at 03:18:09PM +1000, skaller wrote:
> On Mon, 2004-10-25 at 12:58, David Brown wrote:
> > On Mon, Oct 25, 2004 at 04:29:59AM +1000, skaller wrote:
> > 
> > > It would be useful when making an anouncement if you could
> > > specify the licence. This saves wasting time. 
> > > 
> > > On the home page it says:
> > > 
> > > "This software is free for free software. It is released under the GPL."
> > > 
> > > Hmm. So if I link it against the Ocaml standard libraries,
> > > they have to be GPL'd too. But they're not ..
> > 
> > What???  
> 
> I'm wrong, LGPL specifically allows change of licence to GPL.
> Sorry.

Well, i personally was under the impression that when you link a LGPLed and a
GPLed work together, the result needs to be under the more restricive licence,
namely the GPL. This is indeed what you can read in point 3 of the LGPL, which
is the one you seem to mention : 

    3. You may opt to apply the terms of the ordinary GNU General Public
    License instead of this License to a given copy of the Library.  To do
    this, you must alter all the notices that refer to this License, so
    that they refer to the ordinary GNU General Public License, version 2,
    instead of to this License.  (If a newer version than version 2 of the
    ordinary GNU General Public License has appeared, then you can specify
    that version instead if you wish.)  Do not make any other change in
    these notices.
    ^L
    Once this change is made in a given copy, it is irreversible for
    that copy, so the ordinary GNU General Public License applies to all
    subsequent copies and derivative works made from that copy.

    This option is useful when you wish to copy part of the code of
    the Library into a program that is not a library.

This basically says, that you are allowed to use LGPLed code, and integrate it
into GPLed code. I doubt that the ocaml runtime library exception is
compatible with the GPL though, not really sure.

Anyway, this kind of compatbility is not the same as merely linking with
LGPLed code, and the resulting binary is under the GPL, which may or may not
have been your intentions.

Friendly,

Sven Luther
	

Re: [Caml-list] Announce: Schoca-0.2.3 released

[Sven Luther]

On Mon, Oct 25, 2004 at 04:07:15PM +1000, skaller wrote:
> On Mon, 2004-10-25 at 15:29, David Brown wrote:
> 
> > Yes.  That is the point.  That you find the GPL annoying for the reasons
> > you do does mean it has made its point.
> 
> What, that dividing a small community and discouraging
> reuse is a good thing?

Well, only because you chose not to reuse it, because you want to keep a
proprietary version of your code.

The above code is freely offered, but if the GPLed doesn't agre with you,
nothing is stoping others from benefiting from it. Your lose really, but it is
a result of your choice.

Friendly,

Sven Luther

Re: [Caml-list] Announce: Schoca-0.2.3 released

[skaller]

On Thu, 2004-10-28 at 00:40, Sven Luther wrote:

> This basically says, that you are allowed to use LGPLed code, and integrate it
> into GPLed code. I doubt that the ocaml runtime library exception is
> compatible with the GPL though, not really sure.
> 
> Anyway, this kind of compatbility is not the same as merely linking with
> LGPLed code, and the resulting binary is under the GPL, which may or may not
> have been your intentions.

My intention is to supply, free of cost and free for any
use whatsoever, openly published source code.


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

Re: [Caml-list] Announce: Schoca-0.2.3 released

[David Brown]

On Wed, Oct 27, 2004 at 04:40:06PM +0200, Sven Luther wrote:

> Well, i personally was under the impression that when you link a LGPLed and a
> GPLed work together, the result needs to be under the more restricive licence,
> namely the GPL. This is indeed what you can read in point 3 of the LGPL, which
> is the one you seem to mention : 

The resultant binary must be distributed under terms that are compatible
with all of the licenses.  In this case (GPL and LGPL), the terms of the
GPL are sufficient.  If I include BSD-licensed source in my GPL'd program,
I am not required to change the license of the BSD source in order to make
a GPL executable (if it isn't my code, I probably can't change the license
anyway).  The resultant work as a whole is still distributed under the
terms of the GPL.  Someone could extract the BSD code and build a different
"work" that was not under the GPL.

The FSF has a rather large list of various licenses and whether or not you
can legally build a single work, distributed under the GPL, that includes
code under these licenses: <http://www.fsf.org/licenses/license-list.html>.
Generally, this means that these other licenses do not contain restrictions
that the GPL forbids.

Dave