Red Hat Bugzilla – Bug 886838
libdb license problem (Artistic License)
Last modified: 2013-05-28 11:29:13 EDT
libdb package included non free file.
license: Artistic License (license version is not elected.)
If apply Artistic License version 2.0, this is no problem. (Fedora accepted license)
If apply Artistic License version 1.0, this is license problem (Fedora not accept license, and not GPL compatible)
Question: Which is apply license version ? I don't know.
1. remove this file and rebuild.
2. replace to free software (Accepted Fedora) file.
3. remove fedora repos.
Tom, since IANAL, could you please check this?
The original file that this is based off of has quite a storied history.
https://lists.nongnu.org/archive/html/gnu-linux-libre/2010-05/msg00000.html includes correspondence from the copyright holders giving permission for use under the GPL. But even that is unnecessary, since that code has previously been licensed under the LGPL:
I would think that the simplest solution for now would be to use this code under the terms of the LGPLv2+, and just append that License to the spec file tag.
Jindrich, you probably want to let the libdb upstream know about this, they may prefer it to be under BSD instead, and I would imagine that Makoto Matsumoto and Takuji Nishimura would be willing to grant permission for that code to be used under BSD license terms.
But this is not a blocker for Fedora as is.
Just as a reminder: Legal issues like this should be blocked against "FE-Legal" so that they land in my INBOX for review. :)
Blocked FE-legal, This is license problem.
I'm sorry, I thought I made that aspect clear, this is not a current license problem. That last piece of information was just a reminder of how to get issues like this to my attention.
Fedora is fine to retain this file as is, we just need to include "LGPLv2+" in the package License tag. Jindrich should reach out to the libdb upstream to inform them that they either need to change the license in the file to reflect the LGPLv2+ license option or reach out to Makoto Matsumoto and Takuji Nishimura and ask them to grant permission for that original mt19937int.c code to be used under BSD license terms.
This bug is affected Fedora 18.
How it this bug current status ? (responce from upstream author, "mt19937db.c" license status, etc...)
Is this bug is resolved ?
Why change bug stete is "NEW" to "MODIFIED" ?
I see libdb.git (fedora), Its not change.
The license field in f18 and rawhide now says:
License: BSD and LGPLv2+
Please verify if it's OK. Still no reply from Oracle on that.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I suggest that reflect new license statement from source.
See Reference URI.
This landed in 5.3.21-10.fc20.
Re-open this bug. and Im sorry.
I checked fedora "libdb.git" version "007-mt19937db.c_license.patch" and trisquel's original patch, diff path name is changed (fedora version).
but "clearly modified statement" (changelog, E.g changing date, etc...) is not find, and not written. Im confuse original patch.
and I *think* that this patch license is GPLv3. (I see top directory, and I see "COPYING".)
Is this is correct ?
If this patch license is GPLv3, fedora version patch is GPLv3 paragraph 4 and 5 not compliant. Its non-free and license problem. (I *think*)
I recommend that compliance GPL, written change log, and include GPL license text. (GPLv3 paragraph 4 and 5-a ).
If not this license is GPLv3, What is this patch licensed under ?
Patched mt19937db.c license is LGPL, but license text is missing. I suggest that include license text.
I do not believe that patch is GPLv3+, as Trisquel has no copyright over that change. The patch is simply applying the license change from the mt19937db upstream version. It would be very very difficult to argue that a unified diff file (and not the changes represented inside of it) is a copyrightable work.
The missing license text is a minor issue however, and I have remedied it in rawhide.