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/
|
