Red Hat Bugzilla – Bug 125921
umb-scheme has incorrect license
Last modified: 2013-07-02 19:00:39 EDT
Description of problem:
Guile as distributed in the Fedora (and previous RedHat) distributions
requires the umb-scheme RPM for its SLIB directory.
SLIB is a GNU package; but it is not released under the GNU GPL. The
Fedora umb-scheme RPM incorrectly declares its license to be the GNU
Using umb-scheme for this purpose creates RPMs for multiple platforms
while the only portion used, SLIB, is actually noarch. It also denies
visibility to SLIB and recognition for its authors.
Please stop pirating SLIB through umb-scheme and instead use the SLIB
RPMs which I distribute from http://swiss.csail.mit.edu/~jaffer/SLIB
Version-Release number of selected component (if applicable):
Steps to Reproduce:
I really don't understand why the slib package is distributed along
with umb-scheme as I was recently reassigned to resolve this bug. I
think it deserves its own rpm. The problem is probably with
dependencies which have to be figured out when slib is removed from
the umb-scheme rpm. It solves also the problem with the different
license. If you agree I can propose adding separate package for slib
and removing slib from umb-scheme.
I agree that separating SLIB from UMB-Scheme is the right thing to do.
Among core RPMs, I think you will find that Guile is the only package
is the current SLIB distribution.
I have discussed slib removal from umb-scheme and a final conclusion
is to remove slib from umb-scheme and adding it to the guile rpm (with
proper recognition of slib license and authors). Now we're waiting for
guile package maintainer opinion because he's now on vacation.
Incorporating SLIB into Guile will again have its 3.MB of noarch
code replicated for each Guile platform.
Although Guile may currently be the only *core* package using SLIB,
there are other packages which use it: JACAL, Schelog, G-wrap,
GNU-cash, Meroon, SCM, umb-scheme, mzscheme (Dr. Scheme),
I believe that Guile and these applications will best be served if
SLIB is a distinct noarch RPM.
Ok, we'll reconsider this and keep you informed about the planned
chnages to umb-scheme and slib.
Having the same slib code included in binary packages for different
architectures isn't a big issue in this case. We have the disk space
to spare here, and it shouldn't impact the user at all since they'll
only wind up with one copy.
Historically, the other packages that use slib haven't been relevant
to the majority of our users, so splitting slib out for them is not a
priority. GNUCash is not an issue since gnucash uses guile anyways.
Overall, the benefits of not having Yet Another Package for users to
worry about outweigh the benefits of having slib packaged separately.
Unless something major changes with FC users needs, or we've forgotten
to cover some major benefits, then I think inclusion in the guile
package is the path to take.
It wouldn't be "yet another package" because it replaces umb-scheme.
Moving SLIB from total obscurity buried inside UMB-Scheme to
total obscurity buried inside Guile is not the change I was hoping
for. It would continue to deny visibility to SLIB and recognition
for its authors.
Aubrey, I have good news for you, we decided to replace umb-scheme
with slib, so that slib will have its own package. Unfortunately it
will not be done in FC3t2 because a devel freeze is today and it
would be pretty hard to resolve dependencies in such a haste. The
change will appear in the next release.
I just included the new slib package into CVS and built it. The new
package is slib-3a1-1.noarch.rpm.