Bug 474044 - Review Request: libzdb - A small, fast, and easy to use database API
Review Request: libzdb - A small, fast, and easy to use database API
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Michael Schwendt
Fedora Extras Quality Assurance
:
: 456955 (view as bug list)
Depends On:
Blocks: 457161
  Show dependency treegraph
 
Reported: 2008-12-01 15:35 EST by Bernard Johnson
Modified: 2014-08-22 08:11 EDT (History)
7 users (show)

See Also:
Fixed In Version: 2.4-3.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-09 18:47:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
bugs.michael: fedora‑review+


Attachments (Terms of Use)

  None (edit)
Description Bernard Johnson 2008-12-01 15:35:28 EST
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.
Comment 1 Bernard Johnson 2008-12-01 15:42:33 EST
*** Bug 456955 has been marked as a duplicate of this bug. ***
Comment 2 Michael Schwendt 2008-12-01 17:04:17 EST
> %{_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?
Comment 3 Bernard Johnson 2008-12-01 17:57:46 EST
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?
Comment 4 Michael Schwendt 2008-12-02 16:24:40 EST
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.
Comment 5 Bernard Johnson 2008-12-05 02:02:57 EST
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+
Comment 6 Michael Schwendt 2008-12-15 14:29:08 EST
>  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.
Comment 7 Bernard Johnson 2009-02-05 22:31:31 EST
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.
Comment 8 Tom "spot" Callaway 2009-02-10 17:48:56 EST
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.
Comment 9 Bernard Johnson 2009-02-11 21:19:00 EST
(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?
Comment 10 Michael Schwendt 2009-02-12 05:21:52 EST
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).
Comment 11 Tom "spot" Callaway 2009-02-12 10:18:12 EST
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.
Comment 12 Michael Schwendt 2009-02-12 11:08:21 EST
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.
Comment 13 Tom "spot" Callaway 2009-02-12 11:13:57 EST
Well, then while we disagree on our interpretations, we draw the same conclusion, so I see no real problem here. ;)
Comment 14 Bernard Johnson 2009-02-16 14:48:12 EST
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.
Comment 15 Michel Alexandre Salim 2009-02-20 01:00:34 EST
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?
Comment 16 Michael Schwendt 2009-02-20 03:41:20 EST
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.
Comment 17 Bernard Johnson 2009-02-25 17:50:24 EST
(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.
Comment 18 Tom "spot" Callaway 2009-02-25 17:53:39 EST
I see no reason why you could not modify that file.
Comment 19 Bernard Johnson 2009-02-25 21:01:37 EST
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@symetrix.com> - 2.4-2
- add a notice to EXCEPTIONS that dual licensing is not available in Fedora
Comment 20 Michael Schwendt 2009-03-07 10:20:22 EST
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.
Comment 21 Bernard Johnson 2009-03-07 11:05:13 EST
(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:
Comment 22 Kevin Fenzi 2009-03-07 12:04:18 EST
cvs done.
Comment 23 Fedora Update System 2009-03-07 13:16:49 EST
libzdb-2.4-3.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/libzdb-2.4-3.fc10
Comment 24 Fedora Update System 2009-03-09 18:47:06 EDT
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.
Comment 25 Christopher Meng 2014-03-21 04:43:15 EDT
Package Change Request
======================
Package Name: libzdb
New Branches: epel7
Owners: bjohnson cicku
Comment 26 Gwyn Ciesla 2014-03-21 07:54:54 EDT
Git done (by process-git-requests).
Comment 27 Bernard Johnson 2014-08-21 22:24:31 EDT
Package Change Request
======================
Package Name: libzdb
New Branches: epel7
Owners: bjohnson
Comment 28 Gwyn Ciesla 2014-08-22 08:10:58 EDT
Branch exists.

Note You need to log in before you can comment on or make changes to this bug.