Bug 227570

Hold on a bit -- there's a new version out, and a few issues I've fixed.

Okay, updated. New:

Spec URL: http://mattdm.org/misc/fedoraextras/calc.spec
SRPM URL: http://mattdm.org/misc/fedoraextras/calc-2.12.1.8-1.fc7.mattdm.src.rpm

A remark based on coarse visual inspection only

The sources are LGPL'ed. Your spec 'BR: readline-devel'.
-> Compiling/linking this package against readline will violate readline's GPL.

Oh, good point. It actually has an internal readline alternative it can use.
I'll check with the author about the licensing and readline, and if there's no
ability to make a change I'll modify it to not use readline. Thanks.

Oh, wait, no coffee yet this morning. The LGPL allows conversion to GPL, so
technically I can do that without any upstream input. So really the
consideration here comes down to how much using gnu readline benefits the
program. Right now, since there's actually no dynamic library, using LGPL over
GPL provides no benefit at all to anyone, so I might as well make the conversion.

Further, it's probable that the calc library itself could remain under the gpl
with just the calc command-line binary converted -- the best of both worlds.
Because probably online the command-line util actually links against readline.
(Or am I missing something there?)

(In reply to comment #5)
> Oh, wait, no coffee yet this morning. The LGPL allows conversion to GPL, so
> technically I can do that without any upstream input.
Yes, AFAICT, _YOU_ could re-licence/re-publish the whole package under the GPL
(With all implications of it - You'd be the upstream, shipping a derived product).

Yet another solution would be not to link against readline.

> Further, it's probable that the calc library itself could remain under the gpl
> with just the calc command-line binary converted -- the best of both worlds.
> Because probably online the command-line util actually links against readline.
One would have to check the sources for details - Unfortunately this package
applies a pretty ugly and not easy to understand build/make-system

> (Or am I missing something there?)
I don't think so.

Yeah, rather than using autoconf, it does a similar bunch of tests in its
makefile. Good times.

Okay, updated without readline:

Spec URL: http://mattdm.org/misc/fedoraextras/calc.spec
SRPM URL: http://mattdm.org/misc/fedoraextras/calc-2.12.1.8-2.fc7.mattdm.src.rpm


There's another possible license issue here, with the license of the included
md5.c file:

/*
 ***********************************************************************
 ** Copyright (C) 1990, RSA Data Security, Inc. All rights reserved.  **
 **                                                                   **
 ** License to copy and use this software is granted provided that    **
 ** it is identified as the "RSA Data Security, Inc. MD5 Message-     **
 ** Digest Algorithm" in all material mentioning or referencing this  **
 ** software or this function.                                        **
 **                                                                   **
 ** License is also granted to make and use derivative works          **
 ** provided that such works are identified as "derived from the RSA  **
 ** Data Security, Inc. MD5 Message-Digest Algorithm" in all          **
 ** material mentioning or referencing the derived work.              **
 **                                                                   **
 ** RSA Data Security, Inc. makes no representations concerning       **
 ** either the merchantability of this software or the suitability    **
 ** of this software for any particular purpose.  It is provided "as  **
 ** is" without express or implied warranty of any kind.              **
 **                                                                   **
 ** These notices must be retained in any copies of any part of this  **
 ** documentation and/or software.                                    **
 ***********************************************************************
 */

which is basically like the BSD license except the wording about "all material
mentioning or referencing" is a bit stronger than the BSD license's 
"in the documentation and/or other materials" phrase. Honestly, I'm a little bit
fuzzy on why the 3-clause BSD license is GPL-compatible but the 4-clause one
isn't, and which category this falls into.

Oh, wait, it's worse than that. Ahh, licensing is such joy. See this discussion
regarding a similar problem in apr-utils. 

http://mail-archives.apache.org/mod_mbox/apr-dev/200610.mbox/%3c87y7rpw8g3.fsf@thosu.err.no%3e

Okay, so upstream is now aware of and working on the above issue. I expect a
pretty quick resolution.

Was there ever any resolution to this?

I need to make an updated package. The md5 module is either removed in the
current upstream release or will be. Haven't decided whether to link against
readline or not. (Really, it needs some code reworking so that the library and
the command-line tool aren't so intertwined -- there's no reason at all for the
*library* to need readline.)

Finally had some time to work on this. New packages in

   http://mattdm.org/misc/fedoraextras/

I patched out md5 (should be okay -- it's redistributable, just not linkable
with GPL/LGPL code) and made a flag which patches from LGPL->GPL if you enable
readline, which I've made the default, because it's so handy.

Still working with upstream for the better solution -- splitting the command
line interface (which benefits from Readline and not from being LGPL) from the
library (the opposite). But that may take some time, and I don't think that's a
reason to hold up getting this in Fedora.

What about replacing the MD5 code with a GPL-compatible implementation instead 
of zapping it entirely?

I've discussed that with upstream. I'd actually suggested one alternative
(http://sourceforge.net/project/showfiles.php?group_id=42360&package_id=34443),
and the maintainer's lawyer's advice was that that was licensed in an unclear
way which made it even more restrictive and less free. 

I just now discovered the mhash library, and perhaps code from that would be
suitable -- or a future version of calc could just use the library directly.

However, in a private e-mail, the author noted to me that since md5 has been
show to have some weakness, he considers it not very important to have and even
suggested just removing it to resolve the problem. So, following that advice
seemed to be the best bet for now.

I just confirmed with the upstream author that the next upstream version will
remove md5 functionality. Reimplementing it will be explored in future releases.

Did anything ever happen here?  Or were the packages in comment 13 ready for
review?  I guess the License: tag(s) will need fixing in any case.

I'm working on packages for calc-2.12.2. This upstream release removes the
questionable md5 code and, bonus, dynamically links libraries. Should be ready
real soon now. In the meantime, you can look at the packages in the link at
comment 13 -- if the release number starts with "0", there are known problems
(and probably unknown ones) that I'm still working on (but review comments are
still welcome).

Right now I have it with an option in the spec file which, if "1", converts from
LGPL to GPL and links with readline. This is intended to be temporary -- right
now, the code is such that there's not a good distinction between the
command-line utility and the library. In theory, all readline-dependent
functionality could be split out from the library and only the command-line calc
program linked against that; then we'd have LGPLv2 for the libs and GPL for the
actual program. But that's for the future.

Personally, I really value having real readline support (the built-in
alternative is nothing close) more than having the libraries LGPL, but upstream
really wants the basic libs to be LGPL, which is an understandable position. So
I'm taking suggestions for how to set the flag by default.

Okay, so, I made some time to work on this. The packages you see there now
(calc-2.12.2-0.5.fc8.mattdm.gpl.src.rpm  et al) look pretty good to me and are
ready for review. Thanks.

Now updated to calc 2.12.2.1.

- This should have a calc- prefix:
Source2:       COPYING-GPL

- The -devel package should require the -libs package, not the main package.

- MUST: Permissions on files must be set properly. Executables should be set
with executable permissions, for example. Every %files section must include a
%defattr(...) line.

the -devel and -libs packages do not have a %defattr line

Thank you very much.

> - This should have a calc- prefix:
> Source2:       COPYING-GPL

Even when it's the unmodified, canonical GPL file?

> - The -devel package should require the -libs package, not the main package.

Thanks. Actually, probably more files should be moved to the libs package, too.

> the -devel and -libs packages do not have a %defattr line

I believe the one from %files carries through. But sure, I'll fix it. :)

Okay, new packages up. Fixed a couple more things I noticed while I was at it.
Thanks again.

* Wed Sep 05 2007 Matthew Miller <mattdm> - 2.12.2.1-2
- allow customlib functions with -DCUSTOM.
- made stdrc subpackage for standard resource files and scripts.
- only ship internal line-editor keybindings file if we're not using
  readline
- fix some packaging issues as follows (thanks Till Maas).
- Prefix COPYING-GPL source file with "calc" to avoid file conflicts. 
  Just in case. :)
- defattr for all files sections.
- make the devel package rely on calc-libs, not calc. This is largely
  academic since the calc libs and binaries are not as clearly separated
  as they should be -- a future upstream version will improve this, though,
  so we might as well do the right thing.
- make calc-libs not require calc proper; theoretically this should be true.

Wait, hold off on that one. More coming.

No, I take that back. I thought I'd discovered that the new version had
detangled the readline-using parts of the command-line tool better from the
library, but turns out not. Let's just go ahead with what I have now and I'll
work with upstream further on that.

I am confused looking, matt -- GPL or LGPL -- the website states:

The calc program is free. It is distributed under the GNU Lesser General Public
License.

Calc is open software; you can redistribute it and/or modify it under the terms
of the GNU Lesser General Public License as published by the Free Software
Foundation version 2.1 of the License. 

see: http://isthe.com/chongo/tech/comp/calc/

GPL, as per section 3 of LGPL v2.1, so we can link against readline. This is a
temporary situation I'm working on dealing with upstream.

Alternately, there's logic in the spec file to build without readline and remain
LGPL.  I'm open to making that the default if we have other non-GPL-compatible
free software packages in Fedora that people are interested in linking against
calc. That uses the much-inferior internal line editing routines, though, and
makes the command-line program noticeably less nice to use, so I'd prefer to not.

The upstream possibilities are 1) modify the source to be libedit/editline
compatible (or fix whatever it is in libedit's readline-interface compatibility
layer that isn't working), or 2) split the package so the math and language
libraries don't need to be linked against the line input code -- then, the
command line "calc" program can by GPL and the libraries (which have no real use
for readline) can stay LGPL.

#1 is probably relatively trivial; #2 manageable but less so. If you'd like to
help with either, that'd be awesome.

So, yeah. Anything else? If the package looks basically good/clean, I'm eager to
get it in and work on further improvements from there.

I didn't look at this yet, however

* Keep timestamp
  - When you use "cp" or "install", add "-p" option to keep timestamp
* Parallel make
  - Support parallel make when possible, otherwise write a comment
    in the spec file
    which shows that the Makefile does not support parallel make
* Permission
  - Please explain why you chose the permission "0444", not "0644".
* Defattr
  - We now recommend "%defattr(-.root.root,-)"
* rebuild
  - mock build fails at least on ppc
    http://koji.fedoraproject.org/koji/taskinfo?taskID=163593

Please post the full URL of your spec/srpm so that we can easily
find which spec/srpm are the newest (and should be reviewed).

Thanks for the comments.

> * Keep timestamp

fixed.

> * Parallel make

fixed (it doesn't work).

> * Permission

Following upstream. I changed the executables from 555 to 755; I have no really
strong feelings about changing or leaving the rest, but I have a slight
preference for staying the way they have it since it seems like unnecessary
clutter to change it in the spec file. I can ask upstream about it and see if
they have any objection to changing the defaults in the make file.

> * Defattr

fixed.

> * rebuild
> - mock build fails at least on ppc

Will look into.

There's updated packages at:

http://mattdm.org/misc/fedoraextras/calc.spec
http://mattdm.org/misc/fedoraextras/calc-2.12.2.1-2.fc8.mattdm.gpl.src.rpm

but I still have to look at the ppc build issue.

Okay, builds fine on ppc64. I've tracked down the bug to what looks like some
wrong assumptions about integer sizes in the makefile. I'll get that fixed.
(Package review guidelines indicate that we can go ahead in the meantime; I'll
file the separate bug for that as soon as possible.)

So....
http://mattdm.org/misc/fedoraextras/calc.spec
http://mattdm.org/misc/fedoraextras/calc-2.12.2.1-4.fc8.mattdm.gpl.src.rpm

For 2.12.2.1-4:

* rpmlint
  - rpmlint complains about lots of undefined-non-weak-symbols.
-----------------------------------------------------
$ rpmlint calc-libs
calc-libs.i386: W: no-documentation
calc-libs.i386: W: undefined-non-weak-symbol /usr/lib/libcustcalc.so.2.12.2.1
_zeroval_
calc-libs.i386: W: undefined-non-weak-symbol /usr/lib/libcustcalc.so.2.12.2.1 conf
calc-libs.i386: W: undefined-non-weak-symbol /usr/lib/libcustcalc.so.2.12.2.1
_oneval_
calc-libs.i386: W: undefined-non-weak-symbol /usr/lib/libcustcalc.so.2.12.2.1 qalloc
(and so many)
calc-libs.i386: W: undefined-non-weak-symbol /usr/lib/libcalc.so.2.12.2.1 cust
calc-libs.i386: W: undefined-non-weak-symbol /usr/lib/libcalc.so.2.12.2.1
rl_readline_name
(and so many)
------------------------------------------------------
    This will cause linkage failure against these libraries and cannot
    be accepted (if you want to provide -devel subpackage).

* Documents
  - For this package, the "core" package is calc-libs.
    i.e. all other packages depend on calc-libs, and
         even one can try to install only calc-libs
         and try not to install calc.
    So there can be the case in which no documents like
    license texts are installed, which is not proper.

    In short, license texts and so on must be moved to
    -libs subpackage.

Huh, I had no idea rpmlint could do that. Thanks, I'll track that down and fix it.

Should documents be just moved to libs, or duplicated there? 

Fixing the link issues is turning out to be little bit of a pain (patches to the
code). Will have an update tomorrow.

Okay. New version fixes that by disabling the custom function interface -- the
two libraries are very messily interlinked, and the custom interface is by
definition an optional feature. I'll work with upstream in getting that fixed
eventually.

http://mattdm.org/misc/fedoraextras/calc.spec
http://mattdm.org/misc/fedoraextras/calc-2.12.2.1-7.fc8.mattdm.gpl.src.rpm

Okay.

----------------------------------------------------
   This package (calc) is APPROVED by me
----------------------------------------------------

Thanks for your help, everyone.

New Package CVS Request
=======================
Package Name: calc
Short Description: Arbitrary precision arithmetic system and calculator
Owners: mattdm
Branches: F-7
InitialCC: 
Cvsextras Commits: yes

cvs done.

Package Change Request
======================
Package Name: calc
New Branches: F-8

Please branch for F-8. Thank you.

cvs done.