Bug 467237

Doxygen patch accepted upstream:
http://viewcvs.globus.org/viewcvs.cgi/gsi/gssapi/source/library/gssapi.h?r1=1.21&r2=1.22
http://viewcvs.globus.org/viewcvs.cgi/gsi/gssapi/source/library/inquire_cred.c?r1=1.11&r2=1.12
http://viewcvs.globus.org/viewcvs.cgi/gsi/gssapi/source/library/wrap.c?r1=1.15&r2=1.16

Versioned symbols patch accepted upstream:
http://viewcvs.globus.org/viewcvs.cgi/gsi/gssapi/source/configure.in?r1=1.11&r2=1.12
http://viewcvs.globus.org/viewcvs.cgi/gsi/gssapi/source/library/Makefile.am?r1=1.22&r2=1.23
http://viewcvs.globus.org/viewcvs.cgi/gsi/gssapi/source/library/gssapi.sym?r1=1.1&r2=1.2

globus-gssapi-gsi library not thread safe bug:

http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=6510

Patch accepted upstream:

http://viewcvs.globus.org/viewcvs.cgi/gsi/gssapi/source/library/globus_i_gsi_gss_utils.c?r1=1.51&r2=1.52

This package was updated due to the renaming of the GPT package.

SRPM: http://www.grid.tsl.uu.se/repos/globus/fedora/10/src/SRPMS/globus-gssapi-gsi-5.9-0.3.fc10.src.rpm

SPEC: http://www.grid.tsl.uu.se/repos/globus/info/globus-gssapi-gsi.spec

One additional patch submitted upstream:

Dereferencing of type-punned pointers:
http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=6604

New version
- Added s390x as 64 bit arch
- Added comment documenting source
- Adapt to changes in the globus-core package

http://www.grid.tsl.uu.se/repos/globus/fedora/10/src/SRPMS/globus-gssapi-gsi-5.9-0.5.fc10.src.rpm
http://www.grid.tsl.uu.se/repos/globus/info/globus-gssapi-gsi.spec

Package updated due to new packaging guidelines
- Change defines to globals
- Remove explicit requires on library packages

http://www.grid.tsl.uu.se/repos/globus/info/new/globus-gssapi-gsi-5.9-1.fc10.src.rpm
http://www.grid.tsl.uu.se/repos/globus/info/new/globus-gssapi-gsi.spec

Draft packaging guidelines for Globus packages are now available:
http://fedoraproject.org/wiki/PackagingDrafts/Globus

Here is my review for this one:

? This is possibly an inconsistency: globus-gsi-credential package has
   BuildRequires:	globus-gsi-cert-utils-devel >= 1
whereas this package has
   BuildRequires:	globus-gsi-cert-utils-devel >= 5
Is this intentional?
   $ rpm -q globus-gsi-cert-utils
   globus-gsi-cert-utils-5.5-1.fc10.x86_64

- rpmlint
   globus-gssapi-gsi-devel.x86_64: W: no-documentation
can be ignored.

- koji rawhide build is fine:
   http://koji.fedoraproject.org/koji/taskinfo?taskID=1346454

? library/ssl_locl.h contains a copy of BSD with advertising. Does that make this package "ASL 2.0 and BSD" ?

(In reply to comment #7)
> Here is my review for this one:
> 
> ? This is possibly an inconsistency: globus-gsi-credential package has
>    BuildRequires: globus-gsi-cert-utils-devel >= 1
> whereas this package has
>    BuildRequires: globus-gsi-cert-utils-devel >= 5
> Is this intentional?
>    $ rpm -q globus-gsi-cert-utils
>    globus-gsi-cert-utils-5.5-1.fc10.x86_64

This is not inconsistent. This package uses features that were introduce in version 5 of globus-gsi-cert-utils, while globus-gsi-credential only uses features that have been in the library since version 1.

The GPT source package description for globus-gsi-credential says:

        <Source_Dependencies Type="compile">
            <Dependency Name="globus_gsi_cert_utils">
                <Version>
                    <Simple_Version Major="1"/>
                </Version>
            </Dependency>
        </Source_Dependencies>

While for this package it says:

        <Source_Dependencies Type="compile">
            <Dependency Name="globus_gsi_cert_utils">
                <Version>
                    <Simple_Version Major="5"/>
                </Version>
            </Dependency>
        </Source_Dependencies>

The rpm build requires reflect this.

> - rpmlint
>    globus-gssapi-gsi-devel.x86_64: W: no-documentation
> can be ignored.
> 
> - koji rawhide build is fine:
>    http://koji.fedoraproject.org/koji/taskinfo?taskID=1346454
> 
> ? library/ssl_locl.h contains a copy of BSD with advertising. Does that make
> this package "ASL 2.0 and BSD" ?  

As far as I can tell - no. The file is not installed as part of the binary package, so its license does not influence the license of the package directly. So the question is whether the license of this file influences the license of the package indirectly from being part of the compilation of the library.

The file as included in the source tarball has three license statements:

1. Apache 2.0
2. BSD with advertising
3. OpenSSL

So when compiling this (Apache 2.0 or BSD with advertising or OpenSSL) with all the other files which are Apache 2.0 the resulting binary is Apache 2.0.

(In reply to comment #8)
> The file as included in the source tarball has three license statements:
> 
> 1. Apache 2.0
> 2. BSD with advertising
> 3. OpenSSL
> 

Yes there is also that third statement, Openssl.

> So when compiling this (Apache 2.0 or BSD with advertising or OpenSSL) with all
> the other files which are Apache 2.0 the resulting binary is Apache 2.0.  

At this point I can't be sure if we should regard this as "X or Y or Z". Why is it not "X and Y and Z"? I don't see an indication of either convention in the source. Shall we ask FE-Legal?

I checked our openssl package at Fedora. This ssl/ssl_locl.h file contains two statements,

* BSD with advertising
* OpenSSL

The globus folks just took that file and added a new licence to it (Apache 2.0). Are they legally allowed to do that? 

Let's block FE-Legal. This is something I can't (and shouldn't) decide by myself.

The two original licenses in the file are the original dual licensing of openssl:

http://www.openssl.org/source/license.html

Upstream then copied the file into their source and added their own license statement to it, which is Apache 2. I agree this addition is a bit questionable.

If this file would instead have been installed as part of the openssl package then this package would be Apache-2 like all the other globus packages.

Also, if the "relicensing" done by upstream is OK, then we can say this file is Apache 2, and then the package would be Apache 2 as well.

However, if this is not the case the library is a unit compiled from some sources having Apache 2 license and other sources (one file) having openssl license. These two licenses are compatible with each other, but neither of them "wins" the way GPL always does. In this case the License tag should be "ASL 2.0 and OpenSSL". This might in fact be the right thing to do.

Reading the original openssl license more carefully:

 * The licence and distribution terms for any publically available version or
 * derivative of this code cannot be changed.  i.e. this code cannot simply be
 * copied and put under another distribution licence
 * [including the GNU Public Licence.]

makes the Apache license statement added by Globus a bit dubious. Or maybe it was intended as an an AND and not an OR - but then why do it?

Anyway I'm getting more inclined to change the License tag to "ASL 2.0 and OpenSSL".

I have created a new version where the license tag is "ASL 2.0 and OpenSSL":

http://www.grid.tsl.uu.se/repos/globus/info/new/globus-gssapi-gsi-5.9-2.fc10.src.rpm
http://www.grid.tsl.uu.se/repos/globus/info/new/globus-gssapi-gsi.spec

I now think this makes the most sense.

Yes, I agree that that's the best thing to do with what we have, but the biggest doubt here is whether upstream globus is legally allowed to add a new license an top of the existing one or not.

FE-Legal usually responds in a couple days. You can send an email to their mailing list if you want.

I would point out to globus upstream that they do not have permission to change the licensing terms on that file. Also, since this is an exact copy of the openssl headers, why are we even using it? We should be using the system openssl-devel files.

(In reply to comment #15)
> I would point out to globus upstream that they do not have permission to change
> the licensing terms on that file. Also, since this is an exact copy of the
> openssl headers, why are we even using it? We should be using the system
> openssl-devel files.  

I have filed a bugzilla report upstream about the license issue:

http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=6736

Globus is using the system openssl-devel header files when possible. However, this file is not installed by a normal openssl installation, and is therefore not part of the openssl-devel package. So there is no system version to use of this file.

I'm not sure if that is better or worse, because it means they're using unpublished private openssl API.

There are also these files library/pkcs11*.h that carry yet another license but they don't get compiled. So, for now, they won't cause us any trouble.

Can you ask upstream about these files too, what are they for, are they going to get compiled in a future version etc.?

(In reply to comment #18)
> Can you ask upstream about these files too, what are they for, are they going
> to get compiled in a future version etc.?  

http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=6737

spot, 
It looks like the upstream is a little slow with responding. Can we come up with a temporary resolution until they respond since there are many other globus packages that depend on this one awaiting review?

If yes, what should the license tag be?

Or is this an absolute blocker?

"ASL 2.0 and OpenSSL" is the correct license tag. I don't think this is a blocker, even though upstream has incorrected added the ASL 2.0 terms to the OpenSSL header files. We'll just use those files under the proper OpenSSL licensing. 

Please follow up with upstream to get it corrected, but I'm lifting FE-Legal.

incorrected should be "incorrectly". It's a Monday, sorry.

Okay then. Thanks spot! There are no other issues with this package.

----------------------------------------------------
This package (globus-gssapi-gsi) is APPROVED by oget
----------------------------------------------------

Thank you for the review. I will follow what upstream will do about the issue.


New Package CVS Request
=======================
Package Name: globus-gssapi-gsi
Short Description: Globus Toolkit - GSSAPI library
Owners: ellert
Branches: F-9 F-10 F-11 EL-4 EL-5
InitialCC:

cvs done.

globus-gssapi-gsi-5.9-2.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/globus-gssapi-gsi-5.9-2.fc9

globus-gssapi-gsi-5.9-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/globus-gssapi-gsi-5.9-2.fc10

globus-gssapi-gsi-5.9-2.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/globus-gssapi-gsi-5.9-2.fc11

globus-gssapi-gsi-5.9-2.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

globus-gssapi-gsi-5.9-2.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

globus-gssapi-gsi-5.9-2.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.