Bug 234191

Summary: Is arpack's license GPL compatible?
Product: [Fedora] Fedora Reporter: Axel Thimm <axel.thimm>
Component: arpackAssignee: Axel Thimm <axel.thimm>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 12CC: alex, axel.thimm, dbateman, matt, qspencer, tcallawa, varekova
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-09 08:25:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Axel Thimm 2007-03-27 17:03:58 UTC
bug #214967 is arpack's new package review. After a long wait concerning whether
its license is appropriate for inclusion in Fedora it was checked and found to
be fine (with a given clarification by one of the authors).

Another issue was raised whether the license is also GPL compatible and thus can
be used to link octave against. Since this is not anymore a blocking issue for
reviewing arpack I'm moving this part over to this bug.

Once arpack has its own component in bugzilla the bug can be placed under
arpack, for now I'm using the next best slot which is octave, since octave is
the GPL consumer interested in linking against arpack.

Comment 1 Axel Thimm 2007-03-27 17:33:12 UTC
For reference: the license use in arpack (transcribed from a doc file):

Rice BSD Software License

Permits source and binary redistribution of the software ARPACK and
P_ARPACK for both non-commercial and commercial use.

 Copyright (©) 2001, Rice University
 Developed by D.C. Sorensen, R.B. Lehoucq, C. Yang, and K. Maschhoff.
 All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

o Redistributions of source code must retain the above copyright
  notice, this list of conditions and the following disclaimer.

o Redistributions in binary form must reproduce the above copyright
  notice, this list of conditions and the following disclaimer in the
  documentation and/or other materials provided with the distribution.

o If you modify the source for these routines we ask that you change
  the name of the routine and comment the changes made to the
  original.

o Written notification is provided to the developers of intent to use
  this software.  Also, we ask that use of ARPACK is properly cited in
  any resulting publications or software documentation.

o Neither the name of Rice University (RICE) nor the names of its
  contributors may be used to endorse or promote products derived from
  this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY RICE AND CONTRIBUTORS "AS IS" AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL RICE OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


Comment 2 Axel Thimm 2007-03-27 17:36:48 UTC
For reference: Prof. Dan Sorensen's clarification on David Bateman's request

Date: Tue, 13 Feb 2007 13:52:59 -0600
From: Dan Sorensen
To: David Bateman
Subject: Re: ARPACK License Question

Dear Mr. Bateman

I apologize for not responding to this previously.

The clarification we discussed is the following


The clause in the license statement  that states

>>Written notification is provided to the developers of intent to use this 
>> software. Also, we ask that use of ARPACK is properly cited in any 
>> resulting publications or software documentation.

has the following intension in your case.

We are asking for acknowledgment in FEDORA that ARPACK is
the software that underlies what corresponds to the  "eigs" command.   
There is no intention to pass on a requirement of notification of use
from users of FEDORA.   

This is the understanding we have with MATLAB for example.

If the above note or a slight modification of it is not acceptable
for the purposes of using ARPACK in FEDORA, I will have to refer
you to the tech transfer department of Rice University as I explained
during our phone conversation.

Once again my apologies for the delay and I thank you for your
interest in ARPACK.

Best Regards
Dan Sorensen



 



David Bateman wrote:
> Dear Professor Sorensen,
>
> Perhaps you have not yet seen the e-mail below, and so I draw it to your
> attention. Can you please examine the request to modify the license of
> ARPACK in this mail belong to allow its inclusion in FEDORA and other
> similar open source linux distributions?
>
> As the author of the eigs function for Octave (www.octave.org) that uses
> ARPACK for its functionality, I'd hate to see my work not included in
> Octave due to this question not being resolved.
>
> Best Regards
> David
>
>   


Comment 3 David Bateman 2007-03-28 10:12:42 UTC
Please note that Proffesor Sorensen seems quite willing to negotiate on the
question, and it is rather the lawyers at Rice Uni that required to offending
clause. If FE-Legal might supply the exact text of the minimum clarification
that would be needed, then I can approach Prof Sorensen with this request. In
practice this clause is not applied as Matlab links against ARPACK and their
users are not required to notify Rice University, so I suspect even if the
lawyers at Rice get involved it might not be too difficult to convince them to
modify this badly thought out clause.

Regards
David

Comment 4 Tom "spot" Callaway 2007-04-04 23:00:13 UTC
So here is what the FSF says on the matter:

As is, the license is Free, but not GPL-Compatible, due to the "required"
written notification.

They suggested making a "slight modification" and changing the
"written notification" to be optional, like the name
changing and citations. 

They suggested:

* We ask that written notification be provided to the developers
of intent to use this software.

By making it an optional request instead of a requirement, it would
become GPL compatible.

Comment 5 David Bateman 2007-04-05 16:29:56 UTC
Ok, I will forward this to Sorensen..

D.

Comment 6 Tom "spot" Callaway 2007-06-11 02:34:42 UTC
Just checking in on this, any change from Professor Sorenson/Rice University on
this?

Comment 7 Axel Thimm 2007-12-30 10:10:59 UTC
I think we can close this meta-bug as "fixed" as the information whether the
current license is GPL compatible or not has been provided (with Tom's negative
answer from the FSF, but still an answer).

I'll leave that as NEEDINFO on David in case he does manage to get an answer
from RICE and/or Prof. Sorenson, but will close it in a couple of weeks.

Comment 8 Matt McCutchen 2010-04-01 01:35:28 UTC
So the arpack license was determined to be GPL-incompatible, yet octave went ahead and linked with it?  That's not good.

Comment 9 Tom "spot" Callaway 2010-04-01 13:14:10 UTC
No, it isn't. Please open a bug against octave and block it against FE-Legal.

Comment 10 Matt McCutchen 2010-04-01 17:57:33 UTC
I entered bug 578873.

Comment 11 David Bateman 2010-04-01 19:51:44 UTC
Perhaps before flying off the handle and thinking that a project like Octave with "GNU" in its title wouldn't be very careful with what code it accepts into its core, you'd check if the upstream hadn't changed its license. Check

http://www.caam.rice.edu/software/ARPACK/RiceBSD.txt#LICENSE

which is a standard 3 clause BSD license, and which applied to both ARPACK and PARPACK and the discussion

http://n4.nabble.com/eigs-and-ARPACK-td1652816.html

that followed this change in license before allowing ARPACK to be used in the core of Octave.

D.

Comment 12 Matt McCutchen 2010-04-01 20:43:55 UTC
(In reply to comment #11)
> Perhaps before flying off the handle and thinking that a project like Octave
> with "GNU" in its title wouldn't be very careful with what code it accepts into
> its core, you'd check if the upstream hadn't changed its license.

Or perhaps you'd comment in this bug so it wouldn't mislead future passers-by.  Apologies for not assuming that GNU projects are infallible.

In any case, I morphed bug 578873 accordingly.

Comment 13 Axel Thimm 2010-04-07 17:07:13 UTC
*** Bug 578873 has been marked as a duplicate of this bug. ***

Comment 14 Axel Thimm 2010-04-07 17:14:11 UTC
For future reference: The file located at

    http://www.caam.rice.edu/software/ARPACK/RiceBSD.txt

has a time-stamp of 2008-11-20 17:06:06 UTC and currently contains the following text:

BSD Software License

Pertains to ARPACK and P_ARPACK

Copyright (c) 1996-2008 Rice University.  
Developed by D.C. Sorensen, R.B. Lehoucq, C. Yang, and K. Maschhoff.
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

- Redistributions of source code must retain the above copyright
  notice, this list of conditions and the following disclaimer. 
  
- Redistributions in binary form must reproduce the above copyright
  notice, this list of conditions and the following disclaimer listed
  in this license in the documentation and/or other materials
  provided with the distribution.
  
- Neither the name of the copyright holders nor the names of its
  contributors may be used to endorse or promote products derived from
  this software without specific prior written permission.
  
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT  
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT  
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Comment 15 Axel Thimm 2010-04-07 17:27:43 UTC
Builds for F-13 and rawhide are queued in. I'm not sure the license change should also have F-12 and F-11 packages updated (only the license data has changed).

Comment 16 Matt McCutchen 2010-04-07 17:49:13 UTC
(In reply to comment #15)
> I'm not sure the license change
> should also have F-12 and F-11 packages updated (only the license data has
> changed).    

Why ever not?  Without the update, users of F11 and F12 will think octave is violating the GPL.  There is, of course, essentially no risk of breakage.

Comment 17 Axel Thimm 2010-04-07 18:13:45 UTC
*** Bug 578873 has been marked as a duplicate of this bug. ***

Comment 18 Axel Thimm 2010-04-07 18:24:53 UTC
(In reply to comment #16)
> (In reply to comment #15)
> > I'm not sure the license change
> > should also have F-12 and F-11 packages updated (only the license data has
> > changed).    
> 
> Why ever not?  Without the update, users of F11 and F12 will think octave is
> violating the GPL.  There is, of course, essentially no risk of breakage.    

Because I would force all (direct and indirect) arpack users to redownload packages. And neither octave, nor arpack (the old packaging) are broken or otherwise in violation of any licenses:

a) ARPACK was packaged under certain license. A license chance allows downstream 
   to pick either license (if otherwise the code hasn't changed). E.g. there is
   no expiry date on a license, so the ARPACK code can be redistributed with both
   the old and the new license. This is obviously not the case if/when ARPACK
   will be repackged upstream (which it hasn't).

b) octave uses the ARPACK code in knowledge of the new license.

So the setup in F-11/F-12 is valid, and pushing down the updates for just a license change is a matter of cosmetics vs bandwidth. Given that it took more than two years for someone to notice and even a year for the license change to propagate into Fedora's knowledge, I don't anticipate a wave of wondering Fedorians. More likely F-11 and F-12 will be EOL'd before the second person notices. ;)

And after all Google is your friend. I'm quite sure that soon searching for "Fedora arpack octave license" will bring this bug up at topmost position. Actually just for fun I just googled it and it already does. :)

Comment 19 Matt McCutchen 2010-04-07 18:35:51 UTC
(In reply to comment #18)
> Because I would force all (direct and indirect) arpack users to redownload
> packages.

That's what delta-RPMs are for.  :D

> And neither octave, nor arpack (the old packaging) are broken or
> otherwise in violation of any licenses:

Agreed.

> And after all Google is your friend. I'm quite sure that soon searching for
> "Fedora arpack octave license" will bring this bug up at topmost position.
> Actually just for fun I just googled it and it already does. :)    

Fair point.

Please still commit the changes to CVS so that they will be picked up if arpack is ever updated for another reason.

Comment 20 Alex Lancaster 2010-04-08 19:41:41 UTC
*** Bug 578873 has been marked as a duplicate of this bug. ***

Comment 21 Alex Lancaster 2010-04-08 19:42:31 UTC
Re-opening until F-12 (and F-11) CVS commits done.

Comment 22 Tom "spot" Callaway 2010-04-19 18:35:48 UTC
I'm lifting FE-Legal here, although, the F-12 and F-11 commits should be done. I agree with Axel about the updates, they're not strictly necessary here, but if they are ever necessary, they should pick up the new licensing.

Comment 23 Alex Lancaster 2010-07-17 20:07:16 UTC
(In reply to comment #21)
> Re-opening until F-12 (and F-11) CVS commits done.    

This is almost finished, please do the commit for F-12 and we can close this bug (F-11 is now EOL, so don't need worry about that branch), no need to do any actual builds as noted above.  Also moving to arpack component rather than octave since that's where the changes are needed now.

Comment 24 Bug Zapper 2010-07-30 10:29:34 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping