gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Finally: 4.0 tagged, tarred and ready to test.

[Hans-Bernhard B. <br...@ph...>]

On Tue, 13 Apr 2004, Ethan Merritt wrote:

> Building on Tru64 using DEC cc generates a large number of
> compiler warnings due to the re-definition of TBOOLEAN.

Not of TBOOLEAN itself, I trust it, but of the system datatype __Bool or
similar.  What were the results of configure tests on __Bool and
<stdbool.h>?  Was DEC cc successfully turned into ANSI-accepting (but
*not* strictly-ANSI-only) mode?

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

OK, here's the updated "version" splash text

[Hans-Bernhard B. <br...@ph...>]

Ok, then,

I've modified show.c:show_version() and version.c, and the splash screen
now looks like this:

        G N U P L O T
        Version 4.0 patchlevel 0
        last modified Wed Apr 14 14:46:24 CEST 2004
        System: Linux 2.4.20-4GB-athlon

        Copyright (C) 1986 - 1993, 1998, 2004
        Thomas Williams, Colin Kelley and many others

        This is gnuplot version 4.0.  Please refer to the documentation
        for command syntax changes. The old syntax will be accepted throughout
        the 4.0 series, but all save files use the new syntax.

        Type `help` to access the on-line reference manual
        The gnuplot FAQ is available from
                http://www.gnuplot.info/faq/

        Send comments and requests for help to
                <gnu...@li...>
        Send bugs, suggestions and mods to
                <gnu...@li...>


I.e. the "pre-release of version 4.0" is revised, and the mailing lists
shown are now the release-version ones, and they're wrapped over to a line
for themselves to keep the whole display withing 80 columns.  I could have
used the sf.net alias instead, but think it looks better this way.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: cygwin build report (was Re: Finally: 4.0 tagged, tarred and ready to test.)

[Hans-Bernhard B. <br...@ph...>]

On Tue, 13 Apr 2004, John A. Turner wrote:

> - couldn't get it to build with PDF support, even though PDFlib Lite
>    is installed and I set --with-pdf=...

How/why did it fail?  config.log should help to reveal the reason for this
failure.

> - went ahead and build w/o pdf, but interactive help isn't working
>    (looks possibly related to line endings)

"Isn't working" how?  Is wgnuplot.hlp not built at all?  Or not found
by wgnuplot.exe?

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: cygwin build report (was Re: Finally: 4.0 tagged, tarred and ready to test.)

[Petr M. <mi...@ph...>]

Ok for OS/2 emx/gcc, and MSW Mingw, Cygwin/X11.

> bottom line is that I ran into problems building and running
> under cygwin - quick list of problems:
>
> - went ahead and build w/o pdf, but interactive help isn't working
>    (looks possibly related to line endings)

For me, it works.

If you experience problems with CRLFs, then look at cygwin's setup -- there
you configure this feature.

---
PM

Re: non-critical problem...

[Lars H. <lhe...@us...>]

Daniel J Sebald writes:
> Rather than doing a full install, I built the latest tarball and decided 
> to just test it within the "src" subdirectory.  I realize "you're not 
> supposed to do that", but I ran across something a bit strange with the 
> "gnuplot_x11" terminal.  Here is the message I get:
> 
> gnuplot> plot sin(x)
> Expected X11 driver: /usr/local/libexec/gnuplot/4.0/gnuplot_x11
> Exec failed: No such file or directory
> See 'help x11' for more details
 
 See demo/Makefile.am.in, check-interactive target.

Re: PDFlib Lite vs. the gnuplot Copyright license

[Lars H. <lhe...@us...>]

Daniel J Sebald writes:
> No "set term pdf" then?  Bummer.  At the OSI site are a couple dozen 
> licenses that could be chosen and applied without further review; at 
> least, I think that is what they are saying.  When you speak of an 
> actual lawyer reviewing the license, you mean because Gnuplot's is not 
> any of the OSI confirmed it would have to be reviewed, right?  And for 
> Gnuplot, the "license" is the file "Copyright"?  But that file is 
> somewhat skimpy in legalese compared to the example licenses at OSI.
 
 This discussion pops up every few years ...

 The license cannot be changed by us, only by the Copyright holders.
 That's Thomas Williams and Colin Kelley. The whereabouts of Mr. Kelley
 are unknown, so I usually contact Thomas Williams if a new release is
 about to happen.

 I contacted Thomas Williams in February 2002 to inquire about a further
 license change, explaining the reasons why we would want such a change.
 Got no reply, so I presume he wasn't too impressed.

 It would make sense for gnuplot to adopt a BSD-style license, as the
 current license is already sufficiently similar. I don't see this happening
 in the near future, though, and I'm currently not willing to pursue the
 issue.

Re: web page mirroring

[Petr M. <mi...@ph...>]

> I have mirrored the current sf page to http://sf.gnuplot.info/ for your
> testing pleasure.  I've identified the following files with non-relative
> internal links (some of these may be legitimate; most should be changed):
>
> (badger)/home/httpd/htdocs/gnuplot/sf > find . -name \*.htm\* -exec grep -l
> gnuplot.sourceforge.net {} \;
> ./index.html
> ./docs/gnuplot.html
> ./screenshots/index.html
> ./faq/faq.html
> ./development/index.html
> ./demo/index.html
>
> I've edited the files on the mirror to have relative links; check it out and
> see if I broke anything.
> At this time, this is a static mirror.  Once we are happy with the process,
> I can cron it.

It seems OK.

Those hard links in gnuplot.html and faq.html are hardcoded in cvs version
of these files gnuplot.doc and faq.tex. Changes to relate links would break
things if someone "Save as" these files for local use, so I would rather let
them intact.

---
PM

Re: non-critical problem...

[Ethan A M. <merritt@u.washington.edu>]

On Tuesday 13 April 2004 08:55 pm, Daniel J Sebald wrote:
> It can't get back to the terminal.  It is stuck at "gnuplot>".
>  Actually, the sequence is stranger than I originally thought.  After
> the Exec failure, the screen will respond to keyboard hits but not
> process anything, i.e.,
>
> Then from there, CNTRL-C will bring back "gnuplot>", but the terminal is
> then unresponsive to any keyboard hits... except for a CNTRL-C which
> then displays another "gnuplot>" prompt as though CR was hit.

Right.  It's stuck in term->waitforinput().

> I get two process IDs showing up attributed to "gnuplot"
>
>  1081 pts/4    00:00:00 gnuplot
>  1082 pts/4    00:00:00 gnuplot <defunct>

gnuplot forks inside x11.trm, and the daughter process tries to
execv("gnuplot_x11").  If the execv() had succeeded, that daughter
process would have become "gnuplot_x11". But it failed, so it's still
reported as being "gnuplot".

> >Could be.  Ethan, I guess this one's in your ballbark --- I'm almost
> >willing to bet it's caused by the mouse or font feedback stuff, so
> >please see if you can do something about it.

I see it.  If the piped closes unexpectly, one of the lock flags
needs to be reset so that the waitforinput() loop doesn't continue
forever.  Fixed in cvs.

	Ethan  


-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

web page mirroring

[Clark G. <ga...@di...>]

I have mirrored the current sf page to http://sf.gnuplot.info/ for your 
testing pleasure.  I've identified the following files with non-relative 
internal links (some of these may be legitimate; most should be changed):

(badger)/home/httpd/htdocs/gnuplot/sf > find . -name \*.htm\* -exec grep -l 
gnuplot.sourceforge.net {} \;
./index.html
./docs/gnuplot.html
./screenshots/index.html
./faq/faq.html
./development/index.html
./demo/index.html

I've edited the files on the mirror to have relative links; check it out and 
see if I broke anything.

At this time, this is a static mirror.  Once we are happy with the process, 
I can cron it.

--ckg

cygwin build report (was Re: Finally: 4.0 tagged, tarred and ready to test.)

[John A. T. <tu...@la...>]

Hans-Bernhard Broeker wrote:

> So: last-minute compilation and other tests should take place *now*.

ok, so unfortunately I don't have time to give a detailed report
right now, but can tomorrow (Wed.) afternoon

bottom line is that I ran into problems building and running
under cygwin - quick list of problems:

- couldn't get it to build with PDF support, even though PDFlib Lite
   is installed and I set --with-pdf=...

- went ahead and build w/o pdf, but interactive help isn't working
   (looks possibly related to line endings)

sorry I can't do more now - if whoever has been packaging up the
cygwin build doesn't see these problems, then maybe it's just
something I'm doing...

-John Turner

Re: non-critical problem...

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Tue, 13 Apr 2004, Daniel J Sebald wrote:
>
>  
>
>>Rather than doing a full install, I built the latest tarball and decided 
>>to just test it within the "src" subdirectory.  I realize "you're not 
>>supposed to do that", but I ran across something a bit strange with the 
>>"gnuplot_x11" terminal.  
>>    
>>
>
>That's exactly the reason you're not supposed to do that.  It's explained
>in the INSTALL file (under "How to test gnuplot"), too.
>
>  
>
>>A couple things.  First, it might be nice if gnuplot would check the 
>>current active directory, i.e., the directory from which gnuplot is 
>>launched if it can't find gnuplot_x11 in the expected place.  
>>    
>>
>
>No way.  The security guys would immediately hang us by the toes for such
>a thing.  They're nervous enough about the setuid install if the libvga
>terminal is compiled in as it is.
>

OK, no argument there.

>>If nobody likes that idea, fine.  However, the second thing is that
>>after running gnuplot without "gnuplot_x11" present, the command line
>>hung.  
>>    
>>
>
>Which one: the gnuplot prompt or the shell, after you returned from
>gnuplot?
>
>  
>
>>CNTRL-C broke from the hang, 
>>    
>>
>
>Broke to where?
>

It broke back to the gnuplot prompt, i.e.,

gnuplot>

>>but afterward typing any keyboard keys no longer produces a response at
>>the command line.
>>    
>>
>
>Which command line? Did you try to clean up the terminal's state typing
>"stty sane" blindly?
>

It can't get back to the terminal.  It is stuck at "gnuplot>". 
 Actually, the sequence is stranger than I originally thought.  After 
the Exec failure, the screen will respond to keyboard hits but not 
process anything, i.e.,

Expected X11 driver: /usr/local/libexec/gnuplot/4.0/gnuplot_x11
Exec failed: No such file or directory
See 'help x11' for more details

asdfasdf

asd
asf


Then from there, CNTRL-C will bring back "gnuplot>", but the terminal is 
then unresponsive to any keyboard hits... except for a CNTRL-C which 
then displays another "gnuplot>" prompt as though CR was hit.

I get two process IDs showing up attributed to "gnuplot"

 1081 pts/4    00:00:00 gnuplot
 1082 pts/4    00:00:00 gnuplot <defunct>

You know, it's similar to what happens when "gnuplot_x11" gets killed 
externally and "gnuplot" relaunches a new "gnuplot_x11".  Could there be 
confusion in the code that handles relaunching processes?

>>That may be a bug.
>>    
>>
>
>Could be.  Ethan, I guess this one's in your ballbark --- I'm almost
>willing to bet it's caused by the mouse or font feedback stuff, so
>please see if you can do something about it.
>

I will write a bug report for it.  If the user comes across this 
situation, they have bigger problems to deal with.

>I seriously got to get some sleep now.
>

8:35 + 6:00 or 7:00 = screen hypnosis.

Dan

Re: non-critical problem...

[Hans-Bernhard B. <br...@ph...>]

On Tue, 13 Apr 2004, Daniel J Sebald wrote:

> Rather than doing a full install, I built the latest tarball and decided 
> to just test it within the "src" subdirectory.  I realize "you're not 
> supposed to do that", but I ran across something a bit strange with the 
> "gnuplot_x11" terminal.  

That's exactly the reason you're not supposed to do that.  It's explained
in the INSTALL file (under "How to test gnuplot"), too.

> A couple things.  First, it might be nice if gnuplot would check the 
> current active directory, i.e., the directory from which gnuplot is 
> launched if it can't find gnuplot_x11 in the expected place.  

No way.  The security guys would immediately hang us by the toes for such
a thing.  They're nervous enough about the setuid install if the libvga
terminal is compiled in as it is.

> If nobody likes that idea, fine.  However, the second thing is that
> after running gnuplot without "gnuplot_x11" present, the command line
> hung.  

Which one: the gnuplot prompt or the shell, after you returned from
gnuplot?

> CNTRL-C broke from the hang, 

Broke to where?

> but afterward typing any keyboard keys no longer produces a response at
> the command line.

Which command line? Did you try to clean up the terminal's state typing
"stty sane" blindly?

> That may be a bug.

Could be.  Ethan, I guess this one's in your ballbark --- I'm almost
willing to bet it's caused by the mouse or font feedback stuff, so
please see if you can do something about it.

I seriously got to get some sleep now.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Finally: 4.0 tagged, tarred and ready to test.

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 13 April 2004 11:24 am, Hans-Bernhard Broeker wrote:
>
> So: last-minute compilation and other tests should take place *now*.

Building on Tru64 using DEC cc generates a large number of
compiler warnings due to the re-definition of TBOOLEAN.
But as far as I can tell the resulting code work OK.
So, not a show-stopper but it would be nice to have the build complete
with no compiler warnings.

jarlsberg [95] grep -i Warn make.log
cc: Warning: axis.c, line 188: In the definition of the function "axis_unlog_interval", the promoted type of checkrange is incompatible with the type of the corresponding parameter in a prior declaration.
cc: Warning: axis.c, line 747: In the definition of the function "round_outward", the promoted type of upwards is incompatible with the type of the corresponding parameter in a prior declaration.
cc: Warning: command.c, line 1034: In the definition of the function "print_set_output", the promoted type of append_p is incompatible with the type of the corresponding parameter in a prior declaration.
cc: Warning: contour.c, line 431: In the definition of the function "trace_contour", the promoted type of contr_isclosed is incompatible with the type of the corresponding parameter in a prior declaration.
cc: Warning: contour.c, line 843: In the definition of the function "put_contour", the promoted type of contr_isclosed is incompatible with the type of the corresponding parameter in a prior declaration.
cc: Warning: contour.c, line 890: In the definition of the function "chk_contour_kind", the promoted type of contr_isclosed is incompatible with the type of the corresponding parameter in a prior declaration.
cc: Warning: contour.c, line 919: In the definition of the function "put_contour_cubic", the promoted type of contr_isclosed is incompatible with the type of the corresponding parameter in a prior declaration.
cc: Warning: contour.c, line 1007: In the definition of the function "put_contour_bspline", the promoted type of contr_isclosed is incompatible with the type of the corresponding parameter in a prior declaration.
cc: Warning: contour.c, line 1067: In the definition of the function "gen_cubic_spline", the promoted type of contr_isclosed is incompatible with the type of the corresponding parameter in a prior declaration.
cc: Warning: contour.c, line 1365: In the definition of the function "gen_bspline_approx", the promoted type of contr_isclosed is incompatible with the type of the corresponding parameter in a prior declaration.
cc: Warning: contour.c, line 1436: In the definition of the function "eval_bspline", the promoted type of contr_isclosed is incompatible with the type of the corresponding parameter in a prior declaration.
cc: Warning: contour.c, line 1481: In the definition of the function "fetch_knot", the promoted type of contr_isclosed is incompatible with the type of the corresponding parameter in a prior declaration.
cc: Warning: hidden3d.c, line 517: In the definition of the function "store_vertex", the promoted type of color_from_column is incompatible with the type of the corresponding parameter in a prior declaration.
cc: Warning: misc.c, line 931: In the definition of the function "arrow_parse", the promoted type of allow_as is incompatible with the type of the corresponding parameter in a prior declaration.

[ and so on ....]


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

non-critical problem...

[Daniel J S. <dan...@ie...>]

Rather than doing a full install, I built the latest tarball and decided 
to just test it within the "src" subdirectory.  I realize "you're not 
supposed to do that", but I ran across something a bit strange with the 
"gnuplot_x11" terminal.  Here is the message I get:

gnuplot> plot sin(x)
Expected X11 driver: /usr/local/libexec/gnuplot/4.0/gnuplot_x11
Exec failed: No such file or directory
See 'help x11' for more details

A couple things.  First, it might be nice if gnuplot would check the 
current active directory, i.e., the directory from which gnuplot is 
launched if it can't find gnuplot_x11 in the expected place.  For example,

Expected X11 driver: /usr/local/libexec/gnuplot/4.0/gnuplot_x11,
using ./gnuplot_x11 instead.

and if it isn't in the current working directory, state

Expected X11 driver: /usr/local/libexec/gnuplot/4.0/gnuplot_x11,
and none present in current working directory.
Exec failed: No such file or directory

If nobody likes that idea, fine.  However, the second thing is that 
after running gnuplot without "gnuplot_x11" present, the command line 
hung.  CNTRL-C broke from the hang, but afterward typing any keyboard 
keys no longer produces a response at the command line.  That may be a bug.

Dan

Re: Finally: 4.0 tagged, tarred and ready to test.

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

>On Tuesday 13 April 2004 11:24 am, Hans-Bernhard Broeker wrote:
>  
>
>>Unless I hear otherwise, this is the tarball that'll go out on
>>SourceForge.net by this time tomorrow (assuming Lars can sign it in
>>time).
>>
>>So: last-minute compilation and other tests should take place *now*.
>>    
>>
>
>The entry message  (and "show version") still report
>
>   This is a pre-version of gnuplot 4.0. 
>             ^^^^^^^^^^^     
>
>Presumably once it's released it's no longer a "pre-version".
>  
>

Also, if you are going to remove that portion of the start up message, 
the second last line might be modified for appearance.  The line "Send 
comments and requests for help to <gnu...@li...>" 
has a tab at the front, and with an 8 character tab common to many 
terminals (and an 80 character default width), that line becomes 83 
characters and extends to a new line in the next line's tab space. 
 Perhaps change that so it reads:

"Send comments and help requests to <gnu...@li...>"

and see if it works better.

Dan

Re: Finally: 4.0 tagged, tarred and ready to test.

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 13 April 2004 11:24 am, Hans-Bernhard Broeker wrote:
>
> Unless I hear otherwise, this is the tarball that'll go out on
> SourceForge.net by this time tomorrow (assuming Lars can sign it in
> time).
>
> So: last-minute compilation and other tests should take place *now*.

The entry message  (and "show version") still report

   This is a pre-version of gnuplot 4.0. 
             ^^^^^^^^^^^     

Presumably once it's released it's no longer a "pre-version".



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Question

[Hans-Bernhard B. <br...@ph...>]

On Tue, 13 Apr 2004, Justace Clutter wrote:

> f(x, Ia) = I*(exp( (e*(x-Rth*Ia))/(k*T)  )-1)
> I = -2.5E-5
> 
> fit f(x,y) '742_743' using (-1*($5-$7)):(-1E-6*(($4+$6)/2)) via I
> 
> 
> So, the question is, I want to solve for the diode current but I need to
> know the current to see how much voltage is lost in the resister.  Is
> this possible?

Your explanation is too incomplete to allow a definite answer. In
particular I can't see what your words have to do with the formula you're
showing.  I guess you'll have to take a couple of steps backward and find
out what exactly it is you're trying to do here.

*) What's actually in that datafile?
*) What's the meaning of x, Ia and I, respectively?
*) As given the dependence of f(x,Ia) on I is quite trivial.  There
should be no problem at all fitting that to a dataset of x and Ia
values to extract a value of I.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Question

[Justace C. <pro...@co...>]

Hey guys...

	I know that a lot of you are busy working on the 4.0 stuff, been
watching...  But I had a question.  I am trying to fit a diode circuit
to some data.  Simple circuit but here is the code that I am trying to
do.

f(x, Ia) = I*(exp( (e*(x-Rth*Ia))/(k*T)  )-1)
I = -2.5E-5

fit f(x,y) '742_743' using (-1*($5-$7)):(-1E-6*(($4+$6)/2)) via I


So, the question is, I want to solve for the diode current but I need to
know the current to see how much voltage is lost in the resister.  Is
this possible?

Justace

Finally: 4.0 tagged, tarred and ready to test.

[Hans-Bernhard B. <br...@ph...>]

Good news, everyone!

I've just concluded all the updates I could think of as having to be done
before the release (including updates to the Copyright years listed in
pretty much all the files), and tagged the current CVS status as the
GNUPLOT_RELEASE_4_0_0.  I'm uploading the prospective 4.0.0 source tarball
to private webspace of mine.  

  http://home.arcor.de/hans-bernhard.broeker/gnuplot-4.0.0.tar.gz

[There's a traffic limit on that, so please be gentle]

Unless I hear otherwise, this is the tarball that'll go out on
SourceForge.net by this time tomorrow (assuming Lars can sign it in time).

So: last-minute compilation and other tests should take place *now*.

Make sure that all the pieces needed for builds of binary packages are in
place.

I'll draft up an Announcement and send it round for checking, next.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: PDFlib Lite vs. the gnuplot Copyright license

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Tue, 13 Apr 2004, Daniel J Sebald wrote:
>
>  
>
>>No "set term pdf" then?  Bummer.  At the OSI site are a couple dozen 
>>licenses that could be chosen and applied without further review; at 
>>least, I think that is what they are saying. 
>>    
>>
>
>Except that's not for us (the currently active group of developers) to do
>in the first place.  Changes to the license can *only* be done by the
>Copyright holders.  That's mainly Tom Williams, plus a handful of others.  
>They'ld all have to be contacted, and agree on a simultaneous change.  
>That would probably take even longer than getting the current license
>approved.
>

Ah.

>>What is it about Gnuplot in philosophy that varies from licenses 
>>currently out there?  Some core principle?  
>>    
>>
>
>gnuplot's license is quite ancient.  It's been around longer than just
>about all the others you'll find in OSI's list except the big 4 (BSD, MIT,
>GPL and LGPL).  Originally it was rather restrictive, like the Minix
>license in that you weren't allowed to distributed binaries from modified
>source, nor even modified sources themselves.  I.e. you were supposed to
>distribute all mods as patches to the "official" source code.
>
>We convinced Tom Williams as of 3.7 to drop the "no distribution of
>binaries from modified sources" clause, but the "no distribution of
>modified sources" one still stands.
>
>Most of us would probably welcome a move to GPL, but that apparently won't
>happen.
>
>  
>
>>Does it pay to look through the list of approved licenses to see if
>>there is something that closely matches Gnuplot's "Copyright" file?
>>    
>>
>
>It may, but I for one won't have time to do it.
>

Well, it looks like this would have to be done anyway as part of the 
approval process.  (Must tell the approval discussion list which of the 
already approved licenses are closest to yours and what about yours is 
different.)

Dan

Re: PDFlib Lite vs. the gnuplot Copyright license

[Hans-Bernhard B. <br...@ph...>]

On Tue, 13 Apr 2004, Daniel J Sebald wrote:

> No "set term pdf" then?  Bummer.  At the OSI site are a couple dozen 
> licenses that could be chosen and applied without further review; at 
> least, I think that is what they are saying. 

Except that's not for us (the currently active group of developers) to do
in the first place.  Changes to the license can *only* be done by the
Copyright holders.  That's mainly Tom Williams, plus a handful of others.  
They'ld all have to be contacted, and agree on a simultaneous change.  
That would probably take even longer than getting the current license
approved.

> What is it about Gnuplot in philosophy that varies from licenses 
> currently out there?  Some core principle?  

gnuplot's license is quite ancient.  It's been around longer than just
about all the others you'll find in OSI's list except the big 4 (BSD, MIT,
GPL and LGPL).  Originally it was rather restrictive, like the Minix
license in that you weren't allowed to distributed binaries from modified
source, nor even modified sources themselves.  I.e. you were supposed to
distribute all mods as patches to the "official" source code.

We convinced Tom Williams as of 3.7 to drop the "no distribution of
binaries from modified sources" clause, but the "no distribution of
modified sources" one still stands.

Most of us would probably welcome a move to GPL, but that apparently won't
happen.

> Does it pay to look through the list of approved licenses to see if
> there is something that closely matches Gnuplot's "Copyright" file?

It may, but I for one won't have time to do it.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: PDFlib Lite vs. the gnuplot Copyright license

[Daniel J S. <dan...@ie...>]

No "set term pdf" then?  Bummer.  At the OSI site are a couple dozen 
licenses that could be chosen and applied without further review; at 
least, I think that is what they are saying.  When you speak of an 
actual lawyer reviewing the license, you mean because Gnuplot's is not 
any of the OSI confirmed it would have to be reviewed, right?  And for 
Gnuplot, the "license" is the file "Copyright"?  But that file is 
somewhat skimpy in legalese compared to the example licenses at OSI.

Oh, but wait.  Skimpiness apparently doesn't preclude approval.  There 
is a "zlib/libpng" license that is even less than what appears in the 
file "Copyright".  But still, even though it would take a J.D. little 
time to analyze a short license, the OSI process probably takes a week 
or two.

What is it about Gnuplot in philosophy that varies from licenses 
currently out there?  Some core principle?  Does it pay to look through 
the list of approved licenses to see if there is something that closely 
matches Gnuplot's "Copyright" file?

Dan


Hans-Bernhard Broeker wrote:

>Gents, 
>
>as part of my ongoing discussion by mail with the PDFLib people, I've just
>found an issue that would quite certainly mean we can't distribute gnuplot
>binaries with the PDF driver built in.  PDFLib Lite grants an exemption to
>open-source projects, but *only* if they have their license formally
>approved by the OSI (Open Source Initiative).  But the gnuplot license is
>not approved by OSI, and I see no way whatsoever we can get it approved in
>time for the imminent release.  For starters, they want us to supply an
>analysis of our license done by an actual lawyer, for which I think we
>have neither the time nor the money.
>
>This means that for the time being, the open-source usage exemption of
>PDFLib Lite doesn't apply to gnuplot.  The other exemptions are for
>private or research usage, which we can't rely on for our public binaries.
>
>It's also somewhat unclear what exactly PDFLib Lite wants us to include in
>a binary built using their library.  Their licence is apparently written
>with the idea of a shared library used by somebody else's program in mind.
>It doesn't make any sense whatsoever in the context of a statically linked
>gnuplot release having it compiled into its monolithic executable.
>
>So, in a nutshell: no pdf.trm in any of the release binary packages!
>
>  
>

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

PDFlib Lite vs. the gnuplot Copyright license

[Hans-Bernhard B. <br...@ph...>]

Gents, 

as part of my ongoing discussion by mail with the PDFLib people, I've just
found an issue that would quite certainly mean we can't distribute gnuplot
binaries with the PDF driver built in.  PDFLib Lite grants an exemption to
open-source projects, but *only* if they have their license formally
approved by the OSI (Open Source Initiative).  But the gnuplot license is
not approved by OSI, and I see no way whatsoever we can get it approved in
time for the imminent release.  For starters, they want us to supply an
analysis of our license done by an actual lawyer, for which I think we
have neither the time nor the money.

This means that for the time being, the open-source usage exemption of
PDFLib Lite doesn't apply to gnuplot.  The other exemptions are for
private or research usage, which we can't rely on for our public binaries.

It's also somewhat unclear what exactly PDFLib Lite wants us to include in
a binary built using their library.  Their licence is apparently written
with the idea of a shared library used by somebody else's program in mind.
It doesn't make any sense whatsoever in the context of a statically linked
gnuplot release having it compiled into its monolithic executable.

So, in a nutshell: no pdf.trm in any of the release binary packages!

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: misc for readmes

[Hans-Bernhard B. <br...@ph...>]

On Tue, 13 Apr 2004, Petr Mikulik wrote:

> > > BUGS:
> > >
> > >  *) compiling help file with Visual C++ 4.0/Windows NT
> > >     The help compiler coming with this version of MSVC++ appers unable
> > >     to compile gnuplot.rtf.  As a workaround download the freely
> > >     available "Help Workshop" from Microsoft and use that instead.
> > >
> > >
> > > => should not this be written to the makefile of MSVC++ ?
> >
> > No.  You need this help compiler for *all* Windows builds.  If at all, it
> > would have to be added to all of them (makefile.{nt,cyg,mgw,win}).
> >
> > > Or to the preface of "MS-Windows" section in INSTALL
> >
> > That'd be another good place, indeed.
> 
> I think it is the right place where it should be -- as it is already in
> makefile.mgw, .cyg:

I've put it into INSTALL.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: misc for readmes

[Hans-Bernhard B. <br...@ph...>]

On Tue, 13 Apr 2004, Petr Mikulik wrote:

> Ok then but ordinary people have no idea what that front-end is for, and
> just got confused immediately in README.1st. Could you please add 1
> sentence or a better title like "gnuplot-mode for emacs (??)  for
> (arbitrary??) OS".

Ah heck, all right then, I'm moving this into a separate file inside the
"lisp" directory.  It'll be called "README.1st" because there already
a README in there which is not written by us.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.