Spec URL: http://fedorapeople.org/~bjohnson/libzdb.spec SRPM URL: http://fedorapeople.org/~bjohnson/libzdb-2.2.3-1.fc10.src.rpm Description: The Zild C Database Library implements a small, fast, and easy to use database API with thread-safe connection pooling. The library can connect transparently to multiple database systems, has zero configuration and connections are specified via a standard URL scheme.
*** Bug 456955 has been marked as a duplicate of this bug. ***
> %{_libdir}/%{name}-%{version}.so* Without doing a test-build, I just hope they don't put %version into the SONAME, since that would break the ABI with every bump of %version. Does anything use this lib yet?
Not yet, but I do need it to update a package in rawhide that will use it. Would this be as simple a changing the name to %{_libdir}/%{name}.so* ? If not, can you elaborate a bit?
As guessed: $ grep soname build.libzdb.10.log gcc -shared [...] -Wl,-soname -Wl,libzdb-2.2.3.so.4 -o .libs/libzdb-2.2.3.so.4.1.2 $ objdump -x libzdb-2.2.3.so.4.1.2 |grep -i son SONAME libzdb-2.2.3.so.4 This is the internal library name an application will link with. The dynamic loader/linker will use this name when searching for the library file. And rpmbuild constructs automatic dependencies on these names. Including the full software 2.2.3 version in it (instead of just the library versioning scheme at the very right) implies that every time the 2.2.3 version will change, the dependencies of all packages that require this library will be broken and will need a rebuild. [...] libzdb-devel stores its header files directly in /usr/include. Due to file names like URL.h, Connection.h and Exception.h, this is typical pollution of the global namespace and must be avoided. Please install into /usr/include/libzdb/ instead. [...] Package "Summary" can start with "Small, fast, ..." instead of "A ...". [...] You can build with --disable-static to skip building the static lib. [...] The licencing stuff covered in file "EXCEPTIONS" seems okay. I'm not a lawyer, though, so Fedora Legal and/or a second pair of eyes would be good.
Spec URL: http://fedorapeople.org/~bjohnson/libzdb.spec SRPM URL: http://fedorapeople.org/~bjohnson/libzdb-2.2.3-2.fc10.src.rpm Thanks Michael, you comments were very valuable. $ objdump -x usr/lib/libzdb.so.4.1.2 | grep SO SONAME libzdb.so.4 $ rpm -qpl libzdb-2.2.3-2.fc10.i386.rpm | grep libzdb.so /usr/lib/libzdb.so.4 /usr/lib/libzdb.so.4.1.2 $ rpm -qpl libzdb-devel-2.2.3-2.fc10.i386.rpm | grep include /usr/include/libzdb /usr/include/libzdb/Connection.h /usr/include/libzdb/ConnectionPool.h /usr/include/libzdb/Exception.h /usr/include/libzdb/PreparedStatement.h /usr/include/libzdb/ResultSet.h /usr/include/libzdb/SQLException.h /usr/include/libzdb/URL.h $ grep Summary: libzdb.spec | head -1 Summary: Small, fast, and easy to use database API $ grep disable libzdb.spec | head -1 %configure --disable-static --enable-protected The package is licensed under GPLv3+ OR GPLv3 + exceptions. Since the exceptions have not been evaluated for being Fedora compatible, wouldn't we just take the OR clause and distribute it under the GPLv3? Also, if you read: http://fedoraproject.org/wiki/Licensing/FAQ, 3rd question, it says "look at the source" and the source is licensed GPLv3+. It also says "COPYING [or in this case EXCEPTIONS] does not signal licensing intent (it might not seem intuitive, but this is what Red Hat legal told us, and we're going by that)." And, then there is also this under "Multiple licensing situations": The source code in my package is dual licensed, but one of the licenses is a proprietary license (the other is GPLv2+). You do not need to list the proprietary license in the License tag, so it should read: License: GPLv2+
> SONAME libzdb.so.4 By doing that, you've created a library that doesn't exist anywhere else. Anything that would be built with it, would be incompatible with the real libzdb as released by upstream. It's similar to packagers who invent a shared library name and version when converting from a static-only package. Upstream really ought to be involved in such a decision. > The package is licensed under GPLv3+ OR GPLv3 + exceptions. So far, you've included the EXCEPTIONS file in the package. That file modifies the licencing by extending/changing the GPLv3. If those special terms and conditions are met, the licencing would no longer be GPLv3.
Spec URL: http://fedorapeople.org/~bjohnson/libzdb.spec SRPM URL: http://fedorapeople.org/~bjohnson/libzdb-2.3-1.fc10.src.rpm (In reply to comment #6) > > SONAME libzdb.so.4 > > By doing that, you've created a library that doesn't exist anywhere else. > Anything that would be built with it, would be incompatible with the real > libzdb as released by upstream. It's similar to packagers who invent a shared > library name and version when converting from a static-only package. > > Upstream really ought to be involved in such a decision. The library soname issue has been resolved. I'm applying a temporary patch until the next release. See: http://www.tildeslash.com/pipermail/libzdb-general/2009-February/000116.html > > > The package is licensed under GPLv3+ OR GPLv3 + exceptions. > > So far, you've included the EXCEPTIONS file in the package. That file modifies > the licencing by extending/changing the GPLv3. If those special terms and > conditions are met, the licencing would no longer be GPLv3. I'll block FE-LEGAL and try to get an opinion.
Some comments: * The original version of this "EXCEPTIONS" had a third clause: 3. Companies listed in this table are not granted rights to modify, distribute, copy or use the Program. Not under the GPL nor under any other Open Source license. This restriction includes employes, both past and present and anyone affiliated with the following Companies. +--------------------------------------------------------------+ | Company | Identified by | +--------------------------------------------------------------+ | The SCO Group | Domain Name: SCO.COM | | MySQL AB | Domain Name: MYSQL.COM | | Red Hat | Domain Name: REDHAT.COM| | Apple Computer | Domain Name: APPLE.COM | | Sun Microsystems | Domain Name: SUN.COM | | International Business Machines | Domain Name: IBM.COM | +--------------------------------------------------------------+ a) The restriction in section 3 and section 3 does not apply if the Program is part of Work by others not affected by section 3 and the Work is distributed under the GPL or under one of the licenses listed in section 2 above ***** Thankfully, that clause is no longer present. However, the EXCEPTIONS seem to not give linking permission to modified versions of their code. Accordingly, we should treat this code as GPLv3+ only, and ignore the EXCEPTIONS. Lifting FE-Legal.
(In reply to comment #8) > Accordingly, we should treat this code as GPLv3+ only, and ignore the > EXCEPTIONS. Should the EXCEPTIONS file be left in the %doc section or left out completely?
Well, I don't understand Tom's comment about an old version of the EXCEPTIONS file. None of the tarballs in this review contained that old version of the file. That comment is only of limited historical value. Further, where do the EXCEPTIONS forbid linking with a modified libzdb? Section 1.a requires the licensee to ''obey the GPL in all respects for "the Program" (= libzdb)''. Originally, I only reviewed the EXCEPTIONS file to see whether it adds anything that doesn't leave us a choice, but it's only a multi-licensing model with multiple options to choose from. We can pick the GPLv3+ as the only license for the Fedora package. We cannot use the EXCEPTIONS, because IMO they violate the GPLv3. Confirmation for that would have been helpful. Hence keeping the EXCEPTIONS file would be misleading, since we would offer dual/multi-licensing like the tarball. Deleting the file would require patching the README (and any other files that mention the EXCEPTIONS file).
Well, the EXCEPTIONS does not violate the GPLv3. It grants additional rights, not restrictions. It is clearly derived from the MySQL linking exception, but, it is not identical. The MySQL exception says: "A FOSS application developer ("you" or "your") may distribute a Derivative Work provided that you and the Derivative Work meet all of the following conditions:" The libzdb EXCEPTIONS says: "You are free to distribute the Program and link the Program with Work licensed under one or more of the Open Source licenses listed below in section 2, as long as:" The wording here is precise, the GPLv3 defines the term "the Program" as: "“The Program” refers to any copyrightable work licensed under this License. Each licensee is addressed as “you”." This is different from a derived, or modified work, which is given a separate definition in the GPLv3: "To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work." So, since EXCEPTIONS explicitly grants linking exceptions to "The Program", but not to "modified versions", it only applies to an unmodified libzdb. Since we are making modifications (and even if we were not, because we would want the right to do so), we cannot leverage the EXCEPTIONS. However, we are not required to do so (which is why it doesn't violate the GPLv3), so we choose not to. The historical reference is made to show that the upstream's intent in with EXCEPTIONS shows a reasonably malicious history. Accordingly, where we might assume ignorance in the choice of wording in the EXCEPTIONS text in a similar scenario, we can not in this specific case. I would advise that we not package the EXCEPTIONS file, as it is of little value to anyone.
Quote: the GNU General Public Licensed Zild Database Library (the `Program') This is how the file EXCEPTIONS uses the term "the Program". The GPL allows modifying the Program. That's a non-issue even when applying the exceptions. Quote: You obey the GPL in all respects for the Program and the Work > Well, the EXCEPTIONS does not violate the GPLv3. It grants additional > rights, not restrictions. 1 b.ii is an added restriction. It takes away freedom. It overrules the licence used for "the Work" when linking with "the Program". Even copyright holders of libzdb cannot do that. For example: Assume I link (L)GPLv2 licensed Work with libzdb + EXCEPTIONS, then 1 b.ii requires me to do more than what would be necessary with just the (L)GPLv2. I stick to my earlier POV, choosing "GPLv3+ only" is okay as one of the multiple licencing options.
Well, then while we disagree on our interpretations, we draw the same conclusion, so I see no real problem here. ;)
Spec URL: http://fedorapeople.org/~bjohnson/libzdb.spec SRPM URL: http://fedorapeople.org/~bjohnson/libzdb-2.4-1.fc10.src.rpm Thanks to both of your for your insightful comments. Here is the latest version 2.4 which upstream has made the requested changes (soname changes & include file directory change). (In reply to comment #11) > I would advise that we not package the EXCEPTIONS file, as it is of little > value to anyone. The files src/exceptions/Exception.* refer to the EXCEPTIONS file. Since this is in the copyright notice, I'd rather leave the EXCEPTIONS file in %doc for reference rather than have the copyright notice refer to a file that doesn't exist. Furthermore, I don't feel that we have the option to changing the copyright notice to not refer to EXCEPTIONS.
Would a README.Fedora or a COPYING.Fedora file noting that this package is distributed by the project under the provisions of the GPLv3 license only, be sufficient?
Well, Tom only advised against including the EXCEPTIONS file because "it is of little value to anyone" (quote). That's not enough reason to exclude it. If we did include it, though, we would offer the same dual-/multi-licensing options as the upstream tarball (and our "License: GPLv3+" tag may not be explicit enough to signal our intent). And with that, somebody could choose to accept the dual-licensing and would be bound to term 1.b.ii, which I think is a problem, as for example, we don't do that for Fedora.
(In reply to comment #16) > If we did include it, though, we would offer the same dual-/multi-licensing > options as the upstream tarball (and our "License: GPLv3+" tag may not be > explicit enough to signal our intent). And with that, somebody could choose to > accept the dual-licensing and would be bound to term 1.b.ii, which I think is a > problem, as for example, we don't do that for Fedora. Can I modify the EXCEPTIONS file to include this text at the top?: ============================================================================ NOTE: This file is included for reference reasons only. The Fedora project only offers this software under the GPLv3+ and MIT licenses. All files are GPLv3+ licenses, except the following files which are MIT licensed: src/exceptions/assert.c src/exceptions/AssertException.h If you wish to exercise the dual license, please obtain the sources from: http://www.tildeslash.com/libzdb/ ============================================================================= Seems like that would make it un-mistakable in conjunction with the package license tag. If I am not allowed to modify that file, then a README.Fedora is probably the best we can do.
I see no reason why you could not modify that file.
Spec URL: http://fedorapeople.org/~bjohnson/libzdb.spec SRPM URL: http://fedorapeople.org/~bjohnson/libzdb-2.4-2.fc10.src.rpm * Wed Feb 25 2009 Bernard Johnson <bjohnson> - 2.4-2 - add a notice to EXCEPTIONS that dual licensing is not available in Fedora
libzdb-2.4-2.fc10.src.rpm gets my APPROVAL. Except (!) it didn't pass the final check, but that's something you can [and MUST] change in pkg cvs: $ diff -u libzdb.spec.orig libzdb.spec --- libzdb.spec.orig 2009-02-26 02:54:22.000000000 +0100 +++ libzdb.spec 2009-03-07 16:09:55.000000000 +0100 @@ -67,7 +67,7 @@ %package devel Summary: Developer header files & libraries for libzdb database API Group: Development/Libraries -Requires: libzdb = %{version}-${release} +Requires: libzdb = %{version}-%{release} %description devel Developer header files & libraries for libzdb database API.
(In reply to comment #20) > Except (!) it didn't pass the final check, but that's something you can [and > MUST] change in pkg cvs: Good catch on the Requires! I'll fix that after import. Thanks for the review. New Package CVS Request ======================= Package Name: libzdb Short Description: A small, fast, and easy to use database API Owners: bjohnson Branches: F-10 EL-5 InitialCC:
cvs done.
libzdb-2.4-3.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/libzdb-2.4-3.fc10
libzdb-2.4-3.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
Package Change Request ====================== Package Name: libzdb New Branches: epel7 Owners: bjohnson cicku
Git done (by process-git-requests).
Package Change Request ====================== Package Name: libzdb New Branches: epel7 Owners: bjohnson
Branch exists.