Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#313 External GPL interactive frontend

None
closed-out-of-date
None
5
2013-05-14
2006-12-21
No

There is something like a problem with the distribution of gnuplot built against GNU readline : the latter is powerful but GPL, whereas the latter's license isn't GPL-compatible because of the patch restiction).

I offer here to implement an external program that would act as an interactive interface to gnuplot. The goal is to have it:
- GPLed,
- with the same features as gnuplot current builtin interface

The first goal can only be reached if the this external program is talking to gnuplot in a straightforward way (in FSF, the "semantics of the communication" must not be
"intimate"), and if it written with code not coming from gnuplot.

The design idea:
- use readline to handle all the interesting features (command-line editing, history),
- read its input from stdin,
- send commands to and receive answers from gnuplot by piping gnuplot stdin and stdout,
- display messages coming from gnuplot through its stdout,
- knows that gnuplot has finished processing a command.

As far as I can tell, an external program driving gnuplot through a pipe has no way to know it has processed a command. However, I think this can be implemented using ASCII control characters (originally designed to talk to printers, as the whole ASCII set), such as character number 6, which means "acknowledged".

I will post patches here to implement this idea.
Please do not hesitate to comment.

Discussion

1 2 > >> (Page 1 of 2)
  • Logged In: YES
    user_id=1333817
    Originator: YES

    The attached asciifeedback.diff is a patch that will make gnuplot put "ACK" (i.e. \OO6) to stdout when it has successfully executed a command or encountered an error trying to execute it.

    \006 is a "control" character, it is not printable, so it does not appear when using gnuplot.
    File Added: asciifeedback.diff

     
    • assigned_to: nobody --> tlecomte
     
  • Logged In: YES
    user_id=1333817
    Originator: YES

    The attached frontend.c is a first proof-of-concept of what the external interface program could be.

    I have used GLib for its "spawning process" feature, which is basically a high level fork+exec, which makes it easy to fork a process and to have access to the child's stdin&stdout file descriptors (I don't know to get the stdout using popen). So the program first starts gnuplot that way.
    Then it uses GNU readline to handle its input from stdin, and sends lines to gnuplot through the piped stdin. It waits for gnuplot to answer "ACK" thanks to the previous patch, and then prompts again.
    When it gets EOF on gnuplot piped stdout, it exits.

    It's working quite well, except for one case: when gnuplot asks for extra-input after a command. For example:
    - when the builtin help pager asks: "Press return for more:"
    - when the help system asks: "Subtopic of <something>:"
    - when you use inline data input, such as: "plot '-'"
    I am quite sure those can be adressed, maybe by sending an additional "ACK". We would also need a way to change the prompt. I was thinking about the ShiftOut/ShiftIn (14/15) characters as a way to signal that we are sending a new prompt.

    To compile and test frontend.c, you may want to use:

    gcc frontend.c -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -lglib-2.0 -lreadline -o ./frontend

    (or something similar if your path to glib is different)

    Comments are very welcome !
    File Added: frontend.c

     
  • Petr Mikulik
    Petr Mikulik
    2006-12-21

    Logged In: YES
    user_id=31505
    Originator: NO

    Isn't this just a "paranoid debianish" patch? I don't think this does not bring anything new to all other users. I think about much more versatile solutions which should support all platforms:
    - (text mode): use BSD readline as someone else already contributed
    - (graphics mode): implement a graphical wx terminal, which could be used also in the restricted (line width for example) Windows executable

     
  • Petr Mikulik
    Petr Mikulik
    2006-12-21

    Logged In: YES
    user_id=31505
    Originator: NO

    Note: see patch #1504831 "support for NetBSDs editline".

     
  • Ethan Merritt
    Ethan Merritt
    2006-12-21

    • status: open --> open-wont-fix
     
  • Ethan Merritt
    Ethan Merritt
    2006-12-21

    Logged In: YES
    user_id=235620
    Originator: NO

    Unless there is some non-Debian related reason for doing this, i.e. a technical superiority rather than license paranoia, I don't think this is worth pursuing.

    There is no license incompatibility with linking against gnu libreadline as a shared library. This is true for any of several reasons. I give my spin on three of them here:

    (1) gnuplot is in no way shape or form a derivative work of gnu libreadline, hence the GPL terms are simply irrelevant

    (2) linking against libreadline is done by the user, and therefore is an instance of "use", not "distribution", and hence the GPL would not restrict it anyhow

    (3) use of a GPL library via its published interface is exactly what the GPL gives you the right to do, so unless there is some separate question of derivative work, there is not a problem. This is what the LGPL wording makes clear, but in fact it is true for the GPL. As several people have noted, the existence of the LGPL is a clever bit of FUD that by mis-direction implies that it grants some right not already granted by the GPL itself.

    For recent discussion of these points, see for example:

    http://www.ussg.iu.edu/hypermail/linux/kernel/0612.1/2067.html
    http://www.ussg.iu.edu/hypermail/linux/kernel/0612.1/2154.html
    http://www.ussg.iu.edu/hypermail/linux/kernel/0612.2/0536.html

    I realize that some people (mostly from the Debian community) argue endlessly about this issue, but in the rest of the world life goes on. I don't think we should waste our effort on it, although I also echo Petr's comment that it would be nice to polish up patch #1504831 so that instead of arguing with Debian we could just point people at the BSD equivalent library.

     
  • Logged In: YES
    user_id=27517
    Originator: NO

    Ethan, I'm afraid you're basing your arguments on a single, incorrect assumption: that words means the same thing in Legalese as they do in normal, common-sense English. Anyone who ever talked to a person involved with jurisprudence must be aware that's not the case.

    > (1) gnuplot is in no way shape or form a derivative work of gnu
    > libreadline, hence the GPL terms are simply irrelevant

    This is quite certainly wrong. "Derivative work" is a term defined by copyright law, and by that definition incorporating parts of existing work in a new one *does* make the new one a derivative work. If a song contains a significant sequence of notes from another, or even a sample of the actual piece, it's a derivative, no matter how much else there is.

    The only point that's even open for discussion regarding this issue is which types of connecting two pieces of software should be counted as "incorporation". Static linking rather obviously is incorporation, talking to a stream interface (pipe, socket, ...) equally obviously is not. It's quite unclear how dynamic linking fits into this spectrum. Do *we* want to be the people who get to find out the hard way, in court?

    > (2) linking against libreadline is done by the user,

    ... not in the case under discussion: a Linux distributor.

    > and therefore is an instance of "use", not "distribution", and hence the
    > GPL would not restrict it anyhow

    It's not distribution for individuals who compile their own gnuplot --- but it clear as sunshine is "distribution" if a Linux distributor distributes pre-compiled binaries. If what Debian or Fedora do isn't distribution, nothing possibly could be.

     
    • status: open-wont-fix --> open
     
  • Logged In: YES
    user_id=1333817
    Originator: YES

    Well, I am glad to see warm reactions ;)

    Ethan wrote:
    >There is no license incompatibility with linking against gnu libreadline
    >as a shared library.

    You read lkml too much :)
    There is no license incompatibility with linking, but with distributing the linked binary. It's the same with linux kernel modules: it is not forbidden to link against some binary crap, but it's forbidden to distribute the whole thing.

    GNU readline is technically superior to the builtin readline and I suspect it to be much more maintained than the BSD readline, though I have no proof about that.

    Petr wrote:
    >Isn't this just a "paranoid debianish" patch?

    I do not use Debian. I am not paranoid.

    I suffer from having to contemplate gnuplot dumb license (I personally think each release is going against since it is impossible to have the blessing of all copyright holders, but that's a different problem) and its incompatilibities with a powerful peace of software such as GNU readline so I am trying to do something.

    Parts of my strategy are:
    -moving problematic parts to independant modules,
    -slowly rewriting gnuplot parts that I touch with dual-licensed code so that it can be free from its suicidal license.

    Besides those issued, there are still a couple of technical issues that I am blocking on: "Press return for more:", "Subtopic of <something>:", "plot '-'" ... If you have ideas, please share !

     
1 2 > >> (Page 1 of 2)