octave-dev — GNU Octave developers' list

[OctDev] Re: delaunay

[Rafael L. <rla...@us...>]

[Cc: to the octave-dev mailing list.  Please respect the M-F-T header.]

* Kuhn, Jonathan <jon...@me...> [2005-04-26 15:58]:

> I get the following error when I try to run delaunay in octave.
>  
> >> x = [1:15];
> >> y = [1:15];
> >> [x,y]=meshgrid(x,y);
> >> x=reshape(x,15*15,1);
> >> y=reshape(y,15*15,1);
> >> tri=delaunay(x,y)
> error: `delaunayn' undefined near line 51 column 13
> error: evaluating assignment expression near line 51, column 11
> error: evaluating if command near line 50, column 5
> error: evaluating if command near line 49, column 3
> error: called from `delaunay' in file `/usr/share/octave/2.1.49/site/m/octave-fo
> rge/geometry/delaunay.m'
> error: evaluating assignment expression near line 42, column 4

This is a problem with your installation of the octave-forge package and
has nothing to do with Octave itself.  The file delaunayn.oct is probably
lacking in your system or is in a wrong place.  
 
-- 
Rafael

[OctDev] Re: missing copyright statements

[Dmitri A. S. <das...@gm...>]

Russell Standish wrote:
...
> Surely code openly released by the copyright holder without an
> explicit license becomes "public domain" and can be used in any way by
> whomever as they see fit.
> 

This is, generally speaking, definitely not the case in USA (see e.g.:
http://creativecommons.org/about/legal/cultivating).

As Paul Kienzle pointed out to me, in case of octave-forge, indeed any
non-claimed work become BSD-licensed or public domain.

 From the file COPYING:

<<<
...
  Any files not otherwise covered by a license
are assumed to be covered by a BSD-style license (see COPYING.BSD) if the
author is listed or in the public domain if no author is listed.  Files which
link with octave are implicitly covered by the GPL (see COPYING.GPL).
 >>>


Sincerely,

Dmitri.
-- 

[OctDev] Re: missing copyright statements

[Andy A. <ad...@si...>]

On Sat, 23 Apr 2005, Dmitri A. Sergatskov wrote:

> I was looking for files in octave-forge
> with missing clear copyright statement.
>
> main/image/
> 	imread.m (Andy Adler)
> 	imwrite.m (Andy Adler)

Fixed. Thanks for doing this work.
--
Andy Adler

[OctDev] Re: missing copyright statements

[Russell S. <r.s...@un...>]

On Sun, Apr 24, 2005 at 01:40:43AM -0400, Bill Denney wrote:
>=20
> Sorry about that.  I agree to license this and all my contributions to=20
> octave and octave forge as GPL'd code.  (This should prevent problems if =
I=20
> unexpectedly pass away as was previously mentioned.)
>=20

I think I missed that previous "mention". What were the problems?
Surely code openly released by the copyright holder without an
explicit license becomes "public domain" and can be used in any way by
whomever as they see fit.

--=20
*PS: A number of people ask me about the attachment to my email, which
is of type "application/pgp-signature". Don't worry, it is not a
virus. It is an electronic signature, that may be used to verify this
email came from me if you have PGP or GPG installed. Otherwise, you
may safely ignore this attachment.

----------------------------------------------------------------------------
A/Prof Russell Standish                  Phone 8308 3119 (mobile)
Mathematics                         	       0425 253119 (")
UNSW SYDNEY 2052         	         R.S...@un...            =20
Australia                                http://parallel.hpc.unsw.edu.au/rks
            International prefix  +612, Interstate prefix 02
----------------------------------------------------------------------------

Re: [OctDev] Octave-forge packaging

[Dmitri A. S. <das...@gm...>]

Paul Kienzle wrote:

> 
> Personal views aside, I'm content to remove any of my code from 
> octave-forge if John believes it violates his license.  That includes 
> gcv since I'm responsible for putting it there.  You will have to decide 

I would argue again that only gcvsplf.f should go. I thought we agreed
that distributing the source to a program that uses proprietary library
does not violate GNU, but rather being "pretty useless in a Free world."
It is quite feasible that one can produce a free replacement for gcvsplf
based on the paper:

H.J. Woltring (1986), A FORTRAN package for generalized, cross-validatory
spline smoothing and differentiation. Advances in Engineering
Software 8(2):104-113 (U.K.).


> - Paul
> 

Dmitri.
-- 

Re: [OctDev] missing copyright statements

[Paul K. <pki...@us...>]

On Apr 23, 2005, at 11:36 PM, Dmitri A. Sergatskov wrote:

> Since we are on subject of copyright.
>
> I was looking for files in octave-forge
> with missing clear copyright statement.
> There are quite a few of those.

You can use 'cvs log' to find out who is responsible for entering 
individual files in the repository.

> Here some of them:
>
> main/vrml/
> 	most files (Etienne Grossmann  <et...@is...>)
> 	(some files do not have even author name)
>
> main/general/
> 	deref.cc (?)

Paul Kienzle (this will be purged after the next release)

> main/control/
> 	feedback.m (Ben Sapp <bs...@la...>)
>
> main/image/
> 	imginfo.m (Etienne Grossmann  <et...@is...>)
>
> 	imread.m (Andy Adler)
>
> 	imwrite.m (Andy Adler)
>
> 	testimio.m

Paul Kienzle

> main/irsa/
> 	irsa_actcore.m ( Joerg Huber ?)

already has a copyright statement

> main/linear-algebra/
> 	GramSchmidt.cc (P.R. Nienhuis <106...@co...>?)
>
> main/optim/
> 	cdiff.m (?)

Etienne Grossmann

> 	wsolve.m (Paul Kienzle ?)

Paul Kienzle

> main/signal/
> 	flattopwin.m (Paul Kienzle ?)

Paul Kienzle

> 	freqs_plot.m (Paul Kienzle ?)

Julius Smith

> 	ellipdemo.m (Paul Kienzle ?)

Paulo Neis

> main/symbolic/
> 	probably_prime.cc (?)

Paul Kienzle

>
> main/specfun/
> 	expint.f (D.E. AMOS)
> 	Why do we need this file there at all?

removed.

>
> main/struct/
> 	struct.cc (Etienne Grossmann  <et...@is...>)
>
> main/time/
> 	datesplit.m  (Bill Denney <bi...@gi...>)
>
> extra/ver20
> 	most files (Paul Kienzle)

FSF does not insist on copyright statements short files.

> I think something has to be done about it.

Strictly speaking the copyright defaults to BSD according to the top 
level COPYING file.  This probably isn't possible to do, and certainly 
not so simply as I have done it.

admin/get_authors will list the uncopyrighted files.  Unfortunately it 
doesn't properly filter out all public domain files or short programs.  
Anyone care to
fix it?

In trying to figure out what exact text I should use to disclaim 
copyright I found this advice on a Python mailing list:

	http://mail.python.org/pipermail/python-dev/2005-February/051531.html

Here's what the Creative Commons uses as their public domain disclosure:

	http://creativecommons.org/licenses/publicdomain/



Thanks,

	- Paul

Re: [OctDev] Octave-forge packaging

[Rafael L. <ra...@de...>]

* Paul Kienzle <pki...@us...> [2005-04-24 10:39]:

> Personal views aside, I'm content to remove any of my code from 
> octave-forge if John believes it violates his license.  That includes 
> gcv since I'm responsible for putting it there.  You will have to 
> decide for yourself what to do with gpc. At a minimum I can remove
> nonfree from future releases if the Debian and Fedora maintainers
> insist.  Let me know.

I only now realized that the nonfree directory is distributed in the
octave-forge tarball and this is apparently the source of the problems. I
think we should drop it, such that the tarball becomes really free under
the strict FSF interpretation.

A question to John: octave-gpc is distributed as a separate tarball in
http://sourceforge.net/project/showfiles.php?group_id=2888.  Is this okay
with you?

-- 
Rafael

Re: [OctDev] Octave-forge packaging

[John W. E. <jw...@be...>]

On 24-Apr-2005, Paul Kienzle <pki...@us...> wrote:

| Whether or not the above is a correct interpretation has AFAIK not been 
| decided.  I happen to disagree with the FSF interpretation. Linking is 
| a completely arbitrary criterion. I could just as easily write the 
| arguments to a file and call a separate program to invoke the function. 
| A memory based filesystem would make this faster.  It should even be 
| possible to write a specialized 'filesystem' which allows one process 
| to access memory from another without a copy, making the overhead 
| almost invisible.

Again, IANAL, but because the GPL uses copyright law, I think the key
question is whether one is creating a derivative work.  It does not
really matter what technical means are employed to create the
derivative.  A court may eventually decide that linking (static,
dynamic, or otherwise) does not create a derivative work.  But until
then, I will stick with the FSF interpretation.

jwe

Re: [OctDev] Octave-forge packaging

[Paul K. <pki...@us...>]

On Apr 23, 2005, at 6:47 PM, Rafael Laboissiere wrote:

> * John W. Eaton <jw...@be...> [2005-04-23 14:38]:
>
>> It depends on whether you agree with the FSF that having the "user
>> perfrom the link" is a violation of the GPL.  The reason is that this
>> is a subterfuge.  No one person along the way is doing something avoid
>> the terms of the GPL, but the result is the same.
>>
>> Clearly, different people have different ideas about the claim that
>> the FSF makes.  But I agree with the FSF interpretation.  If you
>> accept the other interpretation, and say that it is OK to have the
>> user perform the link, then the GPL is weakened to the point where it
>> might as well not exist.  In any case where the terms of the GPL would
>> be violated by distributing non-free software linked with GPL
>> software, we could just distribute the parts separately and ask that
>> users perform the final step of linking them together.
>
> Thanks for the clarifications.  The issue now boils down to the 
> following
> question: which license should I actually use for licensing octave-gpc?

According to the above interpretation, there is no license under which 
you can release octave-gpc which will remove the problem.

Whether or not the above is a correct interpretation has AFAIK not been 
decided.  I happen to disagree with the FSF interpretation. Linking is 
a completely arbitrary criterion. I could just as easily write the 
arguments to a file and call a separate program to invoke the function. 
A memory based filesystem would make this faster.  It should even be 
possible to write a specialized 'filesystem' which allows one process 
to access memory from another without a copy, making the overhead 
almost invisible.

Personal views aside, I'm content to remove any of my code from 
octave-forge if John believes it violates his license.  That includes 
gcv since I'm responsible for putting it there.  You will have to 
decide for yourself what to do with gpc. At a minimum I can remove 
nonfree from future releases if the Debian and Fedora maintainers 
insist.  Let me know.

- Paul

[OctDev] changes to new gnuplot syntax

[Dmitri A. S. <das...@gm...>]

Quentin Spencer wrote:
> ........ , so I have 
> taken the liberty of checking in all of the changes. I think we are due 
> for a new octave-forge release some time because the old one is, well, 
> old. However, there are still some other functions in other directories 
> that should be converted to the new gnuplot syntax before then.
> 

There is a small batch of diffs with changes to new syntax.
ftp://coffee.phys.unm.edu/pub/dima/octave/octave-forge.diff.2005.04.24.tar.gz

There are few files in main/irse left to be converted...

> -Quentin
> 
> 

Dmitri.
-- 

[OctDev] missing copyright statements

[Dmitri A. S. <das...@gm...>]

Since we are on subject of copyright.

I was looking for files in octave-forge
with missing clear copyright statement.
There are quite a few of those.

Here some of them:

main/vrml/
	most files (Etienne Grossmann  <et...@is...>)
	(some files do not have even author name)

main/general/
	deref.cc (?)

main/control/
	feedback.m (Ben Sapp <bs...@la...>)

main/image/
	imginfo.m (Etienne Grossmann  <et...@is...>)

	imread.m (Andy Adler)

	imwrite.m (Andy Adler)

	testimio.m

main/irsa/
	irsa_actcore.m ( Joerg Huber ?)

main/linear-algebra/
	GramSchmidt.cc (P.R. Nienhuis <106...@co...>?)

main/optim/
	cdiff.m (?)
	wsolve.m (Paul Kienzle ?)

main/signal/
	flattopwin.m (Paul Kienzle ?)
	freqs_plot.m (Paul Kienzle ?)
	ellipdemo.m (Paul Kienzle ?)

main/symbolic/
	probably_prime.cc (?)

main/specfun/
	expint.f (D.E. AMOS)
	Why do we need this file there at all?

main/struct/
	struct.cc (Etienne Grossmann  <et...@is...>)

main/time/
	datesplit.m  (Bill Denney <bi...@gi...>)

extra/ver20
	most files (Paul Kienzle)


I think something has to be done about it.

Sincerely,
Dmitri.
-- 

Re: [OctDev] Octave-forge packaging

[Rafael L. <rla...@us...>]

* John W. Eaton <jw...@be...> [2005-04-23 14:38]:

> It depends on whether you agree with the FSF that having the "user
> perfrom the link" is a violation of the GPL.  The reason is that this
> is a subterfuge.  No one person along the way is doing something avoid
> the terms of the GPL, but the result is the same.
> 
> Clearly, different people have different ideas about the claim that
> the FSF makes.  But I agree with the FSF interpretation.  If you
> accept the other interpretation, and say that it is OK to have the
> user perform the link, then the GPL is weakened to the point where it
> might as well not exist.  In any case where the terms of the GPL would
> be violated by distributing non-free software linked with GPL
> software, we could just distribute the parts separately and ask that
> users perform the final step of linking them together.

Thanks for the clarifications.  The issue now boils down to the following
question: which license should I actually use for licensing octave-gpc?

-- 
Rafael

Re: [OctDev] Octave-forge packaging

[John W. E. <jw...@be...>]

On 23-Apr-2005, Dmitri A. Sergatskov <das...@gm...> wrote:

| Dmitri A. Sergatskov wrote:
| 
| > This "pretty useless" code could be useful one day when one writes a Free
| > replacement of gcvsplf.f and gpcl (or author releases it under Free 
| > license, etc...)
| > 
| 
| Here is some other piece of information:
| 
| http://isb.ri.ccf.org/biomch-l/archives/biomch-l-1994-06/00093.html
| 
| So, the author of gcvsplf.f died more than 10 years ago.
| What the status of the copyright now?

IANAL, but I suppose it belongs to his heirs unless the copyright was
assigned to someone else along the way.

The sad thing is that the file in question is all of about 600 lines
of Fortran.  But I know as well as anyone that if you don't understand
the methods involved, it can be damn hard to write the 600 lines.

jwe

Re: [OctDev] Octave-forge packaging

[John W. E. <jw...@be...>]

On 23-Apr-2005, Dan McMahill <mcm...@al...> wrote:

| I usually avoid the GPL vs BSD license flamewar, but, by 'non-free'
| here its really 'non-GPL'.  Certainly BSD licensed software is free,
| but the GPL would seem to prevent use of BSD licensed plug-ins.

No.  The BSD license (the newer one, without the advertising clause)
is perfectly compatible with the GPL.

| But the reality is that sometimes the effort of writing an octave
| interface to non-GPL software is 1% of the effort of replacing the
| other tool.  An example would be:

The effort required is not the test that matters.  What matters is
whether the resulting binary can be distributed under terms that are
compatible with the GPL.

| In general, I think the plug-in licensing ideas here are unfortunate.
| I could easily envision a company which already provides a matlab mex
| interface to one of their products wanting to release an octave mex
| version too.  The amount of extra work for them is minimal and it may
| make some of their customers happy.  What it does is prevent people
| who may want to use octave and even contribute improvements from
| using it if they're tied, due to the GPL no less, to using matlab.

Rather than blaming the terms of the free software licenses, I
consider this to be a problem with the non-free software licenses.

jwe

Re: [OctDev] Octave-forge packaging

[John W. E. <jw...@be...>]

On 23-Apr-2005, Rafael Laboissiere <ra...@de...> wrote:

| Thanks for bringing this issue to my attention, I was not aware of it.
| The first paragraph of the first question reads:
| 
|     If you do this, your program won't be fully usable in a free
|     environment. If your program depends on a non-free library to do a
|     certain job, it cannot do that job in the Free World. If it depends
|     on a non-free library to run at all, it cannot be part of a free
|     operating system such as GNU; it is entirely off limits to the Free
|     World.
| 
| My understanding of what is written above is that the octave-gpc binding
| is pretty useless in the Free World, but that I am not prevented to
| release it under the GPL.  People are just prevented to freely
| redistribute the linked result Octave/GPC/octave-gpc, but they are
| allowed to install the packages and use this linked result in their
| computers.

It depends on whether you agree with the FSF that having the "user
perfrom the link" is a violation of the GPL.  The reason is that this
is a subterfuge.  No one person along the way is doing something avoid
the terms of the GPL, but the result is the same.

Clearly, different people have different ideas about the claim that
the FSF makes.  But I agree with the FSF interpretation.  If you
accept the other interpretation, and say that it is OK to have the
user perform the link, then the GPL is weakened to the point where it
might as well not exist.  In any case where the terms of the GPL would
be violated by distributing non-free software linked with GPL
software, we could just distribute the parts separately and ask that
users perform the final step of linking them together.

| As regards the second question, there is nothing in the GPC package that
| prevents linking it against a GPL program.  

I thought that the reason that this discussion started was that the
license for some dependency of the GPC package included a clause about
noncommercial use, which conflicts with the GPL.

jwe

Re: [OctDev] Octave-forge packaging

[Dmitri A. S. <das...@gm...>]

Dmitri A. Sergatskov wrote:

> This "pretty useless" code could be useful one day when one writes a Free
> replacement of gcvsplf.f and gpcl (or author releases it under Free 
> license, etc...)
> 

Here is some other piece of information:

http://isb.ri.ccf.org/biomch-l/archives/biomch-l-1994-06/00093.html

So, the author of gcvsplf.f died more than 10 years ago.
What the status of the copyright now?

Dmitri.
-- 

Re: [OctDev] Octave-forge packaging

[Dmitri A. S. <das...@gm...>]

John W. Eaton wrote:
> On 23-Apr-2005, Dmitri A. Sergatskov <das...@gm...> wrote:
...
> | on netlib, but octave-forge has  LICENSE.gcvsplf which pretty much
> | prohibits commercial use of the software (not commercial distribution,
> | as far as I can tell -- IANAL).
> 
> Isn't commercial distribution a commercial use?  It depends on
> precisely what is meant by "use".  But in any case, a license that
> prohibits commercial use (in any sense) would be incompatible with the
> GPL, so it could not be linked with and distributed as part of Octave.
> 

I agree.

> Since Octave is distributed under the plain GPL with no exceptions, it
> doesn't allow non-free plugins.  So if the code is linked with Octave
> as a plugin (through the DEFUN_DLD interface or by any other means), I
> would ask that you stop distributing it.
> 

...

It looks to me now that both gpc/ and splines/ have the same problem.
The wrappers and .m files are released under GNU, but they both
depends on proprietary libraries. In case of splines/ the proprietary
software is a single Fortran file which is included in the distribution.
So, in my opinion, the inclusion and distribution of   gcvsplf.f is
incompatible with GNU software. The rest of the source there
are "pretty useless in the Free World", but still legal to be distributed.
We just cannot build and distribute binaries.

So, my suggestion is to drop "gcvsplf.f" and distribute the rest of the code.
This "pretty useless" code could be useful one day when one writes a Free
replacement of gcvsplf.f and gpcl (or author releases it under Free license, etc...)

> jwe
> 

Sincerely,

Dmitri.
-- 

Re: [OctDev] Octave-forge packaging

[Dirk E. <ed...@de...>]

On 23 April 2005 at 11:23, Quentin Spencer wrote:
| 
| >| Notice also that the octave-gpc package in Debian is in the contrib
| >| section, not in main.
| >
| >I don't think that where the package is stored in the collection makes
| >any difference.
| >  
| >
| Back to my original question: does Debian distribute octave-forge 
| sources with the non-free stuff included, even though it doesn't get 
| packaged with Octave-forge?

We do, which is a possible a violation. Being lazy, I just made use of Paul's
magic 'ignore this directory' files to keep the corresponding code out of the
resulting binary, but never split the source tarball further than Paul did
upstream. 

A number of other Debian packages are in fact split into free and non-free
parts. Maybe it is time to do this for octave-forge now, and/or maybe it is
time to undertake the bigger reorg Paul sometimes mused about (copying, say,
the CRAN mechanism from R).  In any event, someone has got to step to the
plate and do the work.

Dirk

-- 
Better to have an approximate answer to the right question than a precise 
answer to the wrong question.  --  John Tukey as quoted by John Chambers

Re: [OctDev] Octave-forge packaging

[Quentin S. <qsp...@ie...>]

>| Notice also that the octave-gpc package in Debian is in the contrib
>| section, not in main.
>
>I don't think that where the package is stored in the collection makes
>any difference.
>  
>
Back to my original question: does Debian distribute octave-forge 
sources with the non-free stuff included, even though it doesn't get 
packaged with Octave-forge?

Clearly there are different opinions about whether using non-free things 
that link to octave is allowed at all, but it would be easier for me if 
we just created an octave-forge package without the non-free tree and 
perhaps made it separate. It may well be that Red Hat lawyers won't 
object, but I'd just as soon not have to run my package past the legal 
department to get it into Fedora Extras. For what it's worth, while Red 
Hat shares the same legal concerns about these things as the Debian 
project, I sometimes get the impression from following their mailing 
lists that they are even more cautious because being a corporation 
(based in the U.S., which adds some additional liabilities WRT 
encryption, etc.) makes you a more likely lawsuit target (at least that 
seems to be the perception).

-Quentin

Re: [OctDev] Octave-forge packaging

[Rafael L. <ra...@de...>]

* John W. Eaton <jw...@be...> [2005-04-23 11:39]:

> I suggest reading
> 
>   http://www.gnu.org/licenses/gpl-faq.html#FSWithNFLibs
> 
> and
> 
>   http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
> 
> Note that the answer to the second question explains that you can add
> an exception to the GPL so that software you write can link to
> non-free libraries.  But that will only work if ALL the parts of your
> code are covered by a license with the exception.  Since you are also
> linking with Octave, which does not include an exception to allow
> linking with non-free software, then linking to non-free libraries is
> not allowed.
> 
> | I wrote the octave-gpc binding and decided to release it under the GPL.
> | This means that if one day someone writes a GPLed drop-in replacement for
> | GPC, then the binding can be used freely.
> 
> But until then, you have a problem because you only have the non-free
> library to link with, and the GPL does not permit this by default.

Thanks for bringing this issue to my attention, I was not aware of it.
The first paragraph of the first question reads:

    If you do this, your program won't be fully usable in a free
    environment. If your program depends on a non-free library to do a
    certain job, it cannot do that job in the Free World. If it depends
    on a non-free library to run at all, it cannot be part of a free
    operating system such as GNU; it is entirely off limits to the Free
    World.

My understanding of what is written above is that the octave-gpc binding
is pretty useless in the Free World, but that I am not prevented to
release it under the GPL.  People are just prevented to freely
redistribute the linked result Octave/GPC/octave-gpc, but they are
allowed to install the packages and use this linked result in their
computers.

As regards the second question, there is nothing in the GPC package that
prevents linking it against a GPL program.  

> | Notice also that the octave-gpc package in Debian is in the contrib
> | section, not in main.
> 
> I don't think that where the package is stored in the collection makes
> any difference.

You are right.  I just mention that for the record.

-- 
Rafael

Re: [OctDev] Octave-forge packaging

[Dan M. <mcm...@al...>]

On Sat, Apr 23, 2005 at 10:16:48AM -0400, John W. Eaton wrote:
> On 23-Apr-2005, Dmitri A. Sergatskov <das...@gm...> wrote:
> 
> | Quentin Spencer wrote:
> | ...
> | > anyone out there tell me how this is done for Debian? Furthermore, I 
> | > wonder if it wouldn't be better to make the nonfree part a separate 
> | > package or remove it from octave-forge--does anyone even use it?
> | > 
> | 
> | I like csaps (from nonfree/splines/). The only non-free file there
> | is gcvsplf.f (taken from netlib). I could not find any license info
> | on netlib, but octave-forge has  LICENSE.gcvsplf which pretty much
> | prohibits commercial use of the software (not commercial distribution,
> | as far as I can tell -- IANAL).
> 
> Isn't commercial distribution a commercial use?  It depends on
> precisely what is meant by "use".  But in any case, a license that
> prohibits commercial use (in any sense) would be incompatible with the
> GPL, so it could not be linked with and distributed as part of Octave.
> 
> Since Octave is distributed under the plain GPL with no exceptions, it
> doesn't allow non-free plugins.  So if the code is linked with Octave
> as a plugin (through the DEFUN_DLD interface or by any other means), I
> would ask that you stop distributing it.
> 
> My interpretation of the GPL is essentially the same as that of the
> FSF when it comes to plugins.  You can find more information in the
> GPL FAQ.  Now, I do see that the following question and answer
> 
>   http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
> 
> says
> 
>   If a program released under the GPL uses plug-ins, what are the
>   requirements for the licenses of a plug-in?
> 
>   It depends on how the program invokes its plug-ins. If the program
>   uses fork and exec to invoke plug-ins, then the plug-ins are separate
>   programs, so the license for the main program makes no requirements
>   for them.
> 
>   If the program dynamically links plug-ins, and they make function
>   calls to each other and share data structures, we believe they form a
>   single program, which must be treated as an extension of both the main
>   program and the plug-ins. This means the plug-ins must be released
>   under the GPL or a GPL-compatible free software license, and that the
>   terms of the GPL must be followed when those plug-ins are
>   distributed.

yuck.  so a BSD licensed library which provides a mex interface to it
would not be compatible with this.  It would be unfortunate if the GPL
prevented the distribution of free software which included a mex
frontend.

>   If the program dynamically links plug-ins, but the communication
>   between them is limited to invoking the `main' function of the plug-in
>   with some options and waiting for it to return, that is a borderline
>   case.

Or perhaps you view a mex interface more in this category?  The interface
seems fairly well defined.  In other words its not like octave and
a mex plugin make lots of random function calls.

> So the distribution of some non-free plugins with Octave may fall into
> the borderline category mentioned in the final paragraph of the
> answer.

I usually avoid the GPL vs BSD license flamewar, but, by 'non-free'
here its really 'non-GPL'.  Certainly BSD licensed software is free,
but the GPL would seem to prevent use of BSD licensed plug-ins.


> In any case, as a practical matter, it is not a good thing to write
> interfaces to non-free software for Octave.  The reason is that it
> tends to delay the creation of free software to solve the same
> problem.

But the reality is that sometimes the effort of writing an octave
interface to non-GPL software is 1% of the effort of replacing the
other tool.  An example would be:

- an octave frontend to Berkeley SPICE.  I don't think anyone has
written one, but it probably wouldn't be too hard and certainly
much much less work than writing your own GPL simulator.  In fact
the size of the problem is why the NG-spice project backed off
from their original goal of a complete rewrite as a GPL program.

> Finally, the above only applies to code that is linked with Octave.
> If the package consists entirely of .m files, then it does not violate
> the Octave license terms if it has a non-free license.  But it is
> still much better if the package uses a free software license.
 
In general, I think the plug-in licensing ideas here are unfortunate.
I could easily envision a company which already provides a matlab mex
interface to one of their products wanting to release an octave mex
version too.  The amount of extra work for them is minimal and it may
make some of their customers happy.  What it does is prevent people
who may want to use octave and even contribute improvements from
using it if they're tied, due to the GPL no less, to using matlab.


-Dan


-- 

Re: [OctDev] Octave-forge packaging

[John W. E. <jw...@be...>]

On 23-Apr-2005, Rafael Laboissiere <ra...@la...> wrote:

| * John W. Eaton <jw...@be...> [2005-04-23 10:26]:
| 
| > On 23-Apr-2005, Rafael Laboissiere <ra...@la...> wrote:
| > 
| > | Indeed, octave-gpc is released under the GNU GPL.  However, octave-gpc
| > | links against the General Polygon Clipping Library
| > | (http://www.cs.man.ac.uk/aig/staff/alan/software/gpc.html), which has a
| > | non-free license.
| > 
| > Doesn't that mean that you can't distribute the result, because the
| > whole cannot be distributed under the terms of the GPL?
| 
| I am not fully confident on this issue, but I think it works the other
| way around: if a library is released under the GPL, then the linked
| result *_must_* also be released under the GPL.

I suggest reading

  http://www.gnu.org/licenses/gpl-faq.html#FSWithNFLibs

and

  http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

Note that the answer to the second question explains that you can add
an exception to the GPL so that software you write can link to
non-free libraries.  But that will only work if ALL the parts of your
code are covered by a license with the exception.  Since you are also
linking with Octave, which does not include an exception to allow
linking with non-free software, then linking to non-free libraries is
not allowed.

| I wrote the octave-gpc binding and decided to release it under the GPL.
| This means that if one day someone writes a GPLed drop-in replacement for
| GPC, then the binding can be used freely.

But until then, you have a problem because you only have the non-free
library to link with, and the GPL does not permit this by default.

| Notice also that the octave-gpc package in Debian is in the contrib
| section, not in main.

I don't think that where the package is stored in the collection makes
any difference.

jwe

Re: [OctDev] Octave-forge packaging

[Rafael L. <ra...@la...>]

* John W. Eaton <jw...@be...> [2005-04-23 10:26]:

> On 23-Apr-2005, Rafael Laboissiere <ra...@la...> wrote:
> 
> | Indeed, octave-gpc is released under the GNU GPL.  However, octave-gpc
> | links against the General Polygon Clipping Library
> | (http://www.cs.man.ac.uk/aig/staff/alan/software/gpc.html), which has a
> | non-free license.
> 
> Doesn't that mean that you can't distribute the result, because the
> whole cannot be distributed under the terms of the GPL?

I am not fully confident on this issue, but I think it works the other
way around: if a library is released under the GPL, then the linked
result *_must_* also be released under the GPL.

I wrote the octave-gpc binding and decided to release it under the GPL.
This means that if one day someone writes a GPLed drop-in replacement for
GPC, then the binding can be used freely.

Notice also that the octave-gpc package in Debian is in the contrib
section, not in main.

-- 
Rafael

Re: [OctDev] Octave-forge packaging

[John W. E. <jw...@be...>]

On 23-Apr-2005, Rafael Laboissiere <ra...@la...> wrote:

| Indeed, octave-gpc is released under the GNU GPL.  However, octave-gpc
| links against the General Polygon Clipping Library
| (http://www.cs.man.ac.uk/aig/staff/alan/software/gpc.html), which has a
| non-free license.

Doesn't that mean that you can't distribute the result, because the
whole cannot be distributed under the terms of the GPL?

jwe

Re: [OctDev] Octave-forge packaging

[John W. E. <jw...@be...>]

On 23-Apr-2005, Dmitri A. Sergatskov <das...@gm...> wrote:

| Quentin Spencer wrote:
| ...
| > anyone out there tell me how this is done for Debian? Furthermore, I 
| > wonder if it wouldn't be better to make the nonfree part a separate 
| > package or remove it from octave-forge--does anyone even use it?
| > 
| 
| I like csaps (from nonfree/splines/). The only non-free file there
| is gcvsplf.f (taken from netlib). I could not find any license info
| on netlib, but octave-forge has  LICENSE.gcvsplf which pretty much
| prohibits commercial use of the software (not commercial distribution,
| as far as I can tell -- IANAL).

Isn't commercial distribution a commercial use?  It depends on
precisely what is meant by "use".  But in any case, a license that
prohibits commercial use (in any sense) would be incompatible with the
GPL, so it could not be linked with and distributed as part of Octave.

Since Octave is distributed under the plain GPL with no exceptions, it
doesn't allow non-free plugins.  So if the code is linked with Octave
as a plugin (through the DEFUN_DLD interface or by any other means), I
would ask that you stop distributing it.

My interpretation of the GPL is essentially the same as that of the
FSF when it comes to plugins.  You can find more information in the
GPL FAQ.  Now, I do see that the following question and answer

  http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins

says

  If a program released under the GPL uses plug-ins, what are the
  requirements for the licenses of a plug-in?

  It depends on how the program invokes its plug-ins. If the program
  uses fork and exec to invoke plug-ins, then the plug-ins are separate
  programs, so the license for the main program makes no requirements
  for them.

  If the program dynamically links plug-ins, and they make function
  calls to each other and share data structures, we believe they form a
  single program, which must be treated as an extension of both the main
  program and the plug-ins. This means the plug-ins must be released
  under the GPL or a GPL-compatible free software license, and that the
  terms of the GPL must be followed when those plug-ins are
  distributed.

  If the program dynamically links plug-ins, but the communication
  between them is limited to invoking the `main' function of the plug-in
  with some options and waiting for it to return, that is a borderline
  case.

So the distribution of some non-free plugins with Octave may fall into
the borderline category mentioned in the final paragraph of the
answer.

In any case, as a practical matter, it is not a good thing to write
interfaces to non-free software for Octave.  The reason is that it
tends to delay the creation of free software to solve the same
problem.

Finally, the above only applies to code that is linked with Octave.
If the package consists entirely of .m files, then it does not violate
the Octave license terms if it has a non-free license.  But it is
still much better if the package uses a free software license.

jwe