pure-gen: README and readline
Michel Salim
When packaging pure-gen for Fedora (might take a while to get in;
Haskell's language-c also has to be peer-reviewed), I noticed the
following:
pure-gen's README still states that it needs llvm-gcc to compile,
which is no longer the case. It should probably be updated.
Also, more importantly, it appears that compiling pure-gen (with pure)
results in it having a dependency on readline, even though surely it
does not use it:
$ ldd ./pure-gen
linux-vdso.so.1 => (0x00007fff71ca1000)
libpure.so.5 => /usr/lib64/libpure.so.5 (0x00007f7ef2c7d000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6
(0x00007f7ef296c000)
libm.so.6 => /lib64/libm.so.6 (0x00007f7ef26e8000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f7ef24d2000)
libc.so.6 => /lib64/libc.so.6 (0x00007f7ef2152000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7ef1f35000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f7ef1d31000)
libgsl.so.0 => /usr/lib64/libgsl.so.0 (0x00007f7ef193a000)
libgslcblas.so.0 => /usr/lib64/libgslcblas.so.0
(0x00007f7ef1703000)
libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x00007f7ef14a7000)
libreadline.so.6 => /lib64/libreadline.so.6
(0x00007f7ef1264000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7ef380d000)
libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000003519c00000)
This could be a problem, especially if it also holds for any Pure-
compiled binary: readline is GPLv3+, while pure-gen is BSD-licensed;
because of the linkage with readline, the binaries could only be
distributed as GPLv3+ !
From compiling Pure's hello.pure example, it does look like this is
the case:
$ ldd ./hello
linux-vdso.so.1 => (0x00007fffd7153000)
libpure.so.5 => /usr/lib64/libpure.so.5 (0x00007fff54522000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6
(0x00007fff54211000)
libm.so.6 => /lib64/libm.so.6 (0x00007fff53f8d000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fff53d77000)
libc.so.6 => /lib64/libc.so.6 (0x00007fff539f7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fff537da000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fff535d6000)
libgsl.so.0 => /usr/lib64/libgsl.so.0 (0x00007fff531df000)
libgslcblas.so.0 => /usr/lib64/libgslcblas.so.0
(0x00007fff52fa8000)
libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x00007fff52d4c000)
libreadline.so.6 => /lib64/libreadline.so.6
(0x00007fff52b09000)
/lib64/ld-linux-x86-64.so.2 (0x00007fff550b2000)
libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000003519c00000)
A way to fix this might be to split Pure into a core that is more
liberally licensed (e.g. LGPLv3+), and keep the frontend interpreter,
linked against readline, GPLv3+. The LGPL core can then be embedded
into Pure-compiled binaries without dictating their licence choice.
Regards,
--
Michel
Albert Graef
> pure-gen's README still states that it needs llvm-gcc to compile,
> which is no longer the case. It should probably be updated.
Thanks for pointing that out, it's fixed in r2466.
> Also, more importantly, it appears that compiling pure-gen (with pure)
> results in it having a dependency on readline, even though surely it
> does not use it:
Yes, there are a bunch of libraries that apparently get pulled in by
linking to the Pure runtime.
> This could be a problem, especially if it also holds for any Pure-
> compiled binary: readline is GPLv3+, while pure-gen is BSD-licensed;
> because of the linkage with readline, the binaries could only be
> distributed as GPLv3+ !
The problem is even worse. Because Pure's standard library is under GPL
right now and virtually every Pure program uses it, according to the GPL
FAQ all Pure programs effectively become GPL when published/distributed
anyway. That's not really my intention and won't help to spur adoption
of Pure by a wider audience.
I agree that the LGPL is the only reasonable solution to this. (That
still doesn't solve the issue with linking GPLv2-only code against the
runtime, but I've already added an exception clause for that specific
case.) Of course, I'll have to contact a few people who donated code for
the standard library and/or the runtime, before I can make this change.
> A way to fix this might be to split Pure into a core that is more
> liberally licensed (e.g. LGPLv3+), and keep the frontend interpreter,
> linked against readline, GPLv3+. The LGPL core can then be embedded
> into Pure-compiled binaries without dictating their licence choice.
The problem is that the runtime is linked against readline, too, and the
system module, part of the standard library, provides an interface to
it. The easiest way to work around this would be to get rid of readline
entirely and use one of the compatible BSD/MIT-licensed replacements
instead. I'll have to look into this.
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.G...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Albert Graef
> I agree that the LGPL is the only reasonable solution to this.
Scratch that. GSL is GPL, too, so switching Pure to LGPL isn't really
feasible right now. While the interpreter can be built without GSL
support, this severely limits some of Pure's capabilities, so I don't
want to go there.
Michel, to answer your original question, AFAICT this means that
pure-gen (at least the compiled version) is effectively under the GPL
right now. dump-ast isn't affected by that, however, and pure-gen being
GPL doesn't have any dire consequences by itself either, as the Pure
code generated by pure-gen isn't affected.
However, that doesn't help much. Due to the libraries linked into the
interpreter and compiled executables, for all practical purposes Pure
programs can only be distributed under GPLv3+ right now. To make the
switch to LGPL, it seems that I'd have to replace both readline and gsl.
The former is easy, but not the latter. Any ideas?
Albert Graef
> Scratch that. GSL is GPL, too, so switching Pure to LGPL isn't really
> feasible right now. While the interpreter can be built without GSL
> support, this severely limits some of Pure's capabilities, so I don't
> want to go there.
I've taken another look at this, and it seems that I only use a few data
types and basic allocation routines from GSL in the interpreter, which
could easily be replaced by homegrown versions while maintaining GSL
compatibility. This would even be useful from a technical POV, as it
would make the basic matrix functionality in the interpreter work
without depending on GSL. (The pure-gsl interface is another story, but
programmers can avoid it if they have to for licensing reasons.)
So moving Pure (i.e., the runtime, standard library, and maybe some of
the addons) to the LGPL seems feasible after all. The question is, would
it be a useful or welcome change? Would anyone even care? Your opinions,
please. :)
John Cowan
> So moving Pure (i.e., the runtime, standard library, and maybe some of
> the addons) to the LGPL seems feasible after all. The question is, would
> it be a useful or welcome change? Would anyone even care? Your opinions,
> please. :)
I'd love to see Pure moved to the LGPL or even to Apache 2.0, my personal
favorite license (it's a cleaned-up BSD license with explicit patent
grant and so on).
--
John Cowan co...@ccil.org http://ccil.org/~cowan
In computer science, we stand on each other's feet.
--Brian K. Reid
Kay-Uwe
I would welcome a BSD-style license (like Apache 2.0).
I use Pure at work and so far I am limited in using it for a "product
firmware".
Greetings,
Kay-Uwe
> WWW: http://www.musikinformatik.uni-mainz.de/ag
Albert Graef
> I'd love to see Pure moved to the LGPL or even to Apache 2.0, my personal
> favorite license (it's a cleaned-up BSD license with explicit patent
> grant and so on).
John, as much as I understand the desire to get rid of as many strings
as possible, I'd also like to see that improvements and bugfixes to the
interpreter and the library are contributed back for the benefit of the
community. I don't see that happening with a BSD-style license. That's
why I prefer the LGPL over an even more permissive license.
Note that with Pure going LGPL there's not much customization that you
can't do in a proprietary setting, as you can create your custom
frontends and extensions and distribute them under the license
conditions that you want. It's only if you need to modify the core of
the interpreter itself (or the library, but you can always work around
that by writing your own library modules, it's not that difficult) that
you will still be bound by the terms of the GPL. I'd rather have people
contribute such changes, or at least discuss and help with the changes
needed to make the interpreter work with such proprietary applications.
We can discuss this, though. I don't see how an even more permissive
license might benefit the project right now, but I'm willing to hear the
arguments. :)
Albert Graef
> I would welcome a BSD-style license (like Apache 2.0).
>
> I use Pure at work and so far I am limited in using it for a "product
> firmware".
Kay-Uwe, does your application need some customization of the
interpreter core? If not, then the LGPL should give you enough leeway to
distribute your software under your own license conditions, as explained
in my previous post. Otherwise I'd be happy to discuss the necessary
changes in the interpreter with you. If you can't disclose the details,
maybe it's still possible to design some customization interface that
would allow you to do what you need without touching the interpreter source.
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Albert Graef
> So moving Pure (i.e., the runtime, standard library, and maybe some of
> the addons) to the LGPL seems feasible after all.
I've discussed this with my fellow developers and they all support the
license change. So here's the plan as it stands now:
- The Pure core package will become LGPLv3+, as soon as I have removed
the current dependencies on GPL'ed libraries (readline, gsl). Moreover,
pure.cc, the interpreter main, will become public-domain (it's a rather
trivial wrapper around the runtime anyway) so that programmers can just
take it and create their own custom frontends from it if they need that.
- The following addons will be relicensed under the LGPLv3+: pure-ffi,
pure-gtk, pure-liblo, pure-odbc, pure-xml.
- The following addons will be relicensed under the revised BSD license:
pd-pure, pure-csv, pure-gl. (Note that pure-gen is already under the
revised BSD license and will stay that way.)
- pure-gsl and pure-glpk will stay under the GPLv3+ as the corresponding
GNU libraries use the GPLv3+. Similarly, gnumeric-pure will stay under
GPLv2+ as Gnumeric is GPLv2 (only).
- faust2pd and pure-doc I will keep under the GPLv3+ as they are
programs, not libraries, and the license choice has no dire consequences
for the user anyway.
I hope that everyone will be happy with that. :)
Cheers,
Kay-Uwe
interpreter, but on pure's libs.
I was just spreading a kind of "maximum wish" when calling for BSD-
license ;-)
Kay-Uwe
On 26 Okt., 13:04, Albert Graef <Dr.Gr...@t-online.de> wrote:
> Kay-Uwe wrote:
> > I would welcome a BSD-style license (like Apache 2.0).
>
> > I use Pure at work and so far I am limited in using it for a "product
> > firmware".
>
> Kay-Uwe, does your application need some customization of the
> interpreter core? If not, then the LGPL should give you enough leeway to
> distribute your software under your own license conditions, as explained
> in my previous post. Otherwise I'd be happy to discuss the necessary
> changes in the interpreter with you. If you can't disclose the details,
> maybe it's still possible to design some customization interface that
> would allow you to do what you need without touching the interpreter source.
>
> Albert
>
> --
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
Kay-Uwe
issues on WinXP (non-US keyboard layout)
see also http://groups.google.com/group/pure-lang/browse_thread/thread/b3950568f10819a7
Kay-Uwe
On 25 Okt., 00:09, Albert Graef <Dr.Gr...@t-online.de> wrote:
> However, that doesn't help much. Due to the libraries linked into the
> interpreter and compiled executables, for all practical purposes Pure
> programs can only be distributed under GPLv3+ right now. To make the
> switch to LGPL, it seems that I'd have to replace both readline and gsl.
> The former is easy, but not the latter. Any ideas?
>
> Albert
>
> --
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
Kay-Uwe
issues on WinXP (non-US keyboard layout)
see also http://groups.google.com/group/pure-lang/browse_thread/thread/b3950568f10819a7
Kay-Uwe
On 25 Okt., 00:09, Albert Graef <Dr.Gr...@t-online.de> wrote:
> interpreter and compiled executables, for all practical purposes Pure
> programs can only be distributed under GPLv3+ right now. To make the
> switch to LGPL, it seems that I'd have to replace both readline and gsl.
> The former is easy, but not the latter. Any ideas?
>
> Albert
>
> --
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
Kay-Uwe
issues on WinXP (non-US keyboard layout)
see also http://groups.google.com/group/pure-lang/browse_thread/thread/b3950568f10819a7
Kay-Uwe
On 25 Okt., 00:09, Albert Graef <Dr.Gr...@t-online.de> wrote:
> interpreter and compiled executables, for all practical purposes Pure
> programs can only be distributed under GPLv3+ right now. To make the
> switch to LGPL, it seems that I'd have to replace both readline and gsl.
> The former is easy, but not the latter. Any ideas?
>
> Albert
>
> --
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
John Cowan
> pure.cc, the interpreter main, will become public-domain (it's a rather
> trivial wrapper around the runtime anyway) so that programmers can just
> take it and create their own custom frontends from it if they need that.
For the avoidance of all doubt (as the lawyers say), can you put pure.cc
under the BSD license too? There is some question whether explicit
dedications to the public domain (as by saying "This work is in the
public domain") are actually effective in U.S. law. So far no court
has ruled one way or the other.
For this reason, the Creative Commons license that tries to put works in
the public domain ("CC0") has a fallback provision licensing everybody
to do everything if the waiver of copyright fails. But the BSD license
is much simpler.
> I hope that everyone will be happy with that. :)
Otherwise, I'm very happy with it.
--
John Cowan co...@ccil.org http://www.ccil.org/~cowan
Statistics don't help a great deal in making important decisions.
Most people have more than the average number of feet, but I'm not about
to start a company selling shoes in threes. --Ross Gardler
me22
>
> For the avoidance of all doubt (as the lawyers say), can you put pure.cc
> under the BSD license too? There is some question whether explicit
> dedications to the public domain (as by saying "This work is in the
> public domain") are actually effective in U.S. law. So far no court
> has ruled one way or the other.
>
For anyone interested in further elaboration, see
http://rosenlaw.com/lj16.htm ("there is no mechanism in the law by
which an owner of software can simply elect to place it in the public
domain")
John Cowan
> For anyone interested in further elaboration, see
> http://rosenlaw.com/lj16.htm ("there is no mechanism in the law by
> which an owner of software can simply elect to place it in the public
> domain")
Larry's very knowledgeable and competent, but his answers aren't always
those of the majority. Other people argue that copyright, like any right,
can be abandoned by an appropriate act of the owner (when you throw out
something, it is no longer your property, at least by Anglo-American law,
and in fact belongs to no one until someone appropriates it).
Still, it's better to be sure, and the warranty disclaimer is a feel-good
feature.
--
Dream projects long deferred John Cowan <co...@ccil.org>
usually bite the wax tadpole. http://www.ccil.org/~cowan
--James Lileks
me22
>
> Larry's very knowledgeable and competent, but his answers aren't always
> those of the majority. Other people argue that copyright, like any right,
> can be abandoned by an appropriate act of the owner (when you throw out
> something, it is no longer your property, at least by Anglo-American law,
> and in fact belongs to no one until someone appropriates it).
>
On the other hand, here in Quebec there are rights considered
necessary for "public order" that cannot be contracted away.
> Still, it's better to be sure, and the warranty disclaimer is a feel-good
> feature.
>
So absolutely, a BSD/MIT/Boost/LLVM/etc license is a good idea.
John Cowan
> On the other hand, here in Quebec there are rights considered
> necessary for "public order" that cannot be contracted away.
Civil law. Common-law countries are big on the theory that if the
private order is maintained, the public order will take care of itself.
We've all seen lately just how well that works.
Of course, sometimes civil law jurisdictions over-regulate.
--
Winter: MIT, John Cowan
Keio, INRIA, co...@ccil.org
Issue lots of Drafts. http://www.ccil.org/~cowan
So much more to understand!
Might simplicity return? (A "tanka", or extended haiku)
Eddie Rucker
> - The Pure core package will become LGPLv3+, as soon as I have removed
> the current dependencies on GPL'ed libraries (readline, gsl). Moreover,
> trivial wrapper around the runtime anyway) so that programmers can just
> take it and create their own custom frontends from it if they need
> that.
> pure-gtk, pure-liblo, pure-odbc, pure-xml.
>
> - The following addons will be relicensed under the revised BSD
> license:pd-pure, pure-csv, pure-gl. (Note that pure-gen is already under the
> revised BSD license and will stay that way.)
>
> - pure-gsl and pure-glpk will stay under the GPLv3+ as the
> GPLv2+ as Gnumeric is GPLv2 (only).
>
> - faust2pd and pure-doc I will keep under the GPLv3+ as they are
> programs, not libraries, and the license choice has no dire
> consequencesfor the user anyway.
>
+1
e.r.
Albert Graef
> replacing readline would be nice, if that fixes the known keyboard
> issues on WinXP (non-US keyboard layout)
Well, the problem is that there seems to be *no* readline replacement
that works with mingw. OTOH, the Windows command window already gives
simple command editing capabilities, so this might be a minor issue.
Has anyone here worked with editline/libedit? Is there a way to
configure completion? It's not in the documentation, but I see that
there's a fn_complete function in the source, so the basic capability
should be there.
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Ryan Schmidt
On Oct 26, 2009, at 12:30, Albert Graef wrote:
> Well, the problem is that there seems to be *no* readline replacement
> that works with mingw. OTOH, the Windows command window already gives
> simple command editing capabilities, so this might be a minor issue.
>
> Has anyone here worked with editline/libedit? Is there a way to
> configure completion? It's not in the documentation, but I see that
> there's a fn_complete function in the source, so the basic capability
> should be there.
One could also just leave readline-like functionality to the user
(which he would provide by using rlwrap to call pure or whatever).
Albert Graef
> For the avoidance of all doubt (as the lawyers say), can you put pure.cc
> under the BSD license too?
Sure.
Albert Graef
> One could also just leave readline-like functionality to the user
> (which he would provide by using rlwrap to call pure or whatever).
rlwrap is a kludge (they even say that in the manpage). It doesn't
support custom completion, and it needs pty support so there's no native
Windows implementation either. (Not that I worry too much about the
Windows support; readline didn't really work there either, at least for
people with international keyboards.)
I think that editline/libedit is the way to go. It's fairly popular and
readily available on Linux, *BSD and in MacPorts. Custom completion
seems to be supported, at least in recent versions. That's all I need.
Albert Graef
> I think that editline/libedit is the way to go. It's fairly popular and
> readily available on Linux, *BSD and in MacPorts. Custom completion
> seems to be supported, at least in recent versions. That's all I need.
Well, I got Pure to work with libedit (actually it can be used as a
drop-in replacement), but I'm rather disappointed with it. Most notably,
it doesn't support utf-8, which pretty much makes it unusable for me.
So the only workable solution I see is to build Pure with libedit by
default, but also leave the option to build with the real readline
(which would have to be explicitly enabled, e.g., with a --with-readline
switch at configure time). As far as I can see, a programmer who then
links his program/extension against an unmodified, readline-free (and
LGPL'ed) Pure runtime, would still be free to pick his own license terms
for distributing the binary, right?
Jiri Spitz
>
> Well, I got Pure to work with libedit (actually it can be used as a
> drop-in replacement), but I'm rather disappointed with it. Most notably,
> it doesn't support utf-8, which pretty much makes it unusable for me.
>
>
And what about libtecla (http://www.astro.caltech.edu/~mcs/tecla/).
Jiri
Albert Graef
> And what about libtecla (http://www.astro.caltech.edu/~mcs/tecla/).
No unicode support either, so I don't see how this would help. At least
libedit can be used as a drop-in replacement for readline, libtecla
doesn't even offer that much.
Albert Graef
> So the only workable solution I see is to build Pure with libedit by
> default, but also leave the option to build with the real readline
Thinking about this some more, I think that the cleanest solution is
what Michel originally suggested. That means that I'll have to unbundle
readline support from the standard library and provide it as a separate,
GPL'ed module. Then only pure.cc needs to be linked against readline
(and thus GPL), while the runtime and the standard library don't depend
on readline and can be LGPL (and thus commercial Pure programs and
extensions will be fine).
Does anyone see a flaw in this scheme? John, I know that you're active
on the OSI ml, what do you think about it? I'd really appreciate an
informed opinion (not legal advice, of course) on this matter.
John Cowan
> Does anyone see a flaw in this scheme? John, I know that you're active
> on the OSI ml, what do you think about it? I'd really appreciate an
> informed opinion (not legal advice, of course) on this matter.
My approach (and I grant that it's annoying) would be to have two separate
files, pure.cc with readline support (and so GPL) and basic-pure.cc
without readline support (and BSD license).
--
It was dreary and wearisome. Cold clammy winter still held way in this
forsaken country. The only green was the scum of livid weed on the dark
greasy surfaces of the sullen waters. Dead grasses and rotting reeds loomed
up in the mists like ragged shadows of long-forgotten summers.
--"The Passage of the Marshes" http://www.ccil.org/~cowan
Albert Graef
> My approach (and I grant that it's annoying) would be to have two separate
> files, pure.cc with readline support (and so GPL) and basic-pure.cc
> without readline support (and BSD license).
Does that offer an advantage over just having pure.cc dual-licensed as
GPL+BSDL? In that case a prospective commercial user could just rip out
the readline support himself and use the rest of pure.cc for his
purposes, no?
Anyway, I don't think that pure.cc itself is a big issue. The important
thing is to avoid tainting the license of the runtime and the library.
There must be some way to do this, otherwise how could Python, GHC,
Postgres and countless other programs be distributed under permissive
licenses, while they still use readline in their interactive main loops?
John Cowan
> Does that offer an advantage over just having pure.cc dual-licensed as
> GPL+BSDL? In that case a prospective commercial user could just rip out
> the readline support himself and use the rest of pure.cc for his
> purposes, no?
Unfortunately not. If you write "foo", which must be GPL because it
intimately depends on "bar" which is GPL, then if I create "no-bar-foo"
from "foo", even if it removes the dependency on "bar", it is still a
derivative work of "foo" -- and therefore must be under the GPL. *You*
on the other hand as the copyright holder of "foo" can safely publish
"no-bar-foo" using a permissive license, since the copyright owner is not
bound by his own license.
It's stuff like this that makes people not like the GPL.
> Anyway, I don't think that pure.cc itself is a big issue. The important
> thing is to avoid tainting the license of the runtime and the library.
That should be no problem, since they don't depend on readline.
--
Samuel Johnson on playing the violin: John Cowan
"Difficult do you call it, Sir? co...@ccil.org
I wish it were impossible." http://www.ccil.org/~cowan
Albert Graef
> Unfortunately not. If you write "foo", which must be GPL because it
> intimately depends on "bar" which is GPL, then if I create "no-bar-foo"
> from "foo", even if it removes the dependency on "bar", it is still a
> derivative work of "foo" -- and therefore must be under the GPL. *You*
> on the other hand as the copyright holder of "foo" can safely publish
> "no-bar-foo" using a permissive license, since the copyright owner is not
> bound by his own license.
Ok, I understand. Well, I can add a suitably hacked pure-noreadline.cc
to the sources, that's not a big deal.
Albert
Albert Graef
>> Anyway, I don't think that pure.cc itself is a big issue. The important
>> thing is to avoid tainting the license of the runtime and the library.
>
> That should be no problem, since they don't depend on readline.
Well, I got it down to a single function pointer in the lexer (which is
part of the runtime library). This enables the main program to install a
hook for reading input via readline (or any other "gimme more input"
function) if needed, but it's by no means required for the operation of
the lexer (if the function pointer is NULL, the lexer still works). Does
that taint the lexer's license?
John Cowan
> Well, I got it down to a single function pointer in the lexer (which is
> part of the runtime library). This enables the main program to install a
> hook for reading input via readline (or any other "gimme more input"
> function) if needed, but it's by no means required for the operation of
> the lexer (if the function pointer is NULL, the lexer still works). Does
> that taint the lexer's license?
I'd say no: after all, fgets would do the job fine, no?
--
John Cowan <co...@ccil.org>
Yakka foob mog. Grug pubbawup zink wattoom gazork. Chumble spuzz.
--Calvin, giving Newton's First Law "in his own words"
Albert Graef
> I'd say no: after all, fgets would do the job fine, no?
Well, the actual declaration of the function pointer in lexer.ll is:
char *(*command_input)(const char *prompt);
That pointer gets set in pure.cc only. Even if the pointer is NULL, the
lexer works fine (it just uses fgets instead).
My take is that just the existence of this pointer declaration and a
conditional call using that pointer by itself can't possibly be in
violation of the GPL; you can't copyright a trivial C prototype like
that. It's only if you link with pure.cc, which sets that pointer to the
readline function (or some compatible replacement), that linking with
readline actually happens and the GPL comes into play.
John Cowan
> char *(*command_input)(const char *prompt);
Close enough.
> My take is that just the existence of this pointer declaration and a
> conditional call using that pointer by itself can't possibly be in
> violation of the GPL; you can't copyright a trivial C prototype like
> that. It's only if you link with pure.cc, which sets that pointer to the
> readline function (or some compatible replacement), that linking with
> readline actually happens and the GPL comes into play.
I think you're absolutely right.
--
John Cowan co...@ccil.org http://ccil.org/~cowan
Linguistics is arguably the most hotly contested property in the academic
realm. It is soaked with the blood of poets, theologians, philosophers,
philologists, psychologists, biologists and neurologists, along with
whatever blood can be got out of grammarians. - Russ Rymer
Albert Graef
> I think you're absolutely right.
Ok, I committed the necessary changes in r2468. I still have to get rid
of the GSL dependency before I can change the license, though.