Bug 234191
Summary: | Is arpack's license GPL compatible? | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Axel Thimm <axel.thimm> |
Component: | arpack | Assignee: | Axel Thimm <axel.thimm> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 12 | CC: | 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
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. 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 > > 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 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. Ok, I will forward this to Sorensen.. D. Just checking in on this, any change from Professor Sorenson/Rice University on this? 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. So the arpack license was determined to be GPL-incompatible, yet octave went ahead and linked with it? That's not good. No, it isn't. Please open a bug against octave and block it against FE-Legal. I entered bug 578873. 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. (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. *** Bug 578873 has been marked as a duplicate of this bug. *** 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. 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). (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. *** Bug 578873 has been marked as a duplicate of this bug. *** (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. :) (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. *** Bug 578873 has been marked as a duplicate of this bug. *** Re-opening until F-12 (and F-11) CVS commits done. 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. (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. 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 |