Bug 585

Please, *always* say why the package is not eligible to be included in Fedora:
http://rpmfusion.org/Contributors#head-0df093adde5a77a5e0569b2460ff49d078007ae3

Z-Push is "GPLv2 with exceptions" according to Tom Callaway and the
exception is, that Zarafa is not allowed in the US, thus this has to
reach RPM Fusion.

Spec URL: http://labs.linuxnetz.de/bugzilla/z-push.spec
SRPM URL: http://labs.linuxnetz.de/bugzilla/z-push-1.2.1-1.src.rpm

rpmlint output:
z-push.noarch: W: non-standard-uid /var/lib/z-push/state apache
z-push.noarch: W: non-standard-gid /var/lib/z-push/state apache
zarafa-z-push.noarch: W: non-standard-uid /var/lib/zarafa/z-push/state apache
zarafa-z-push.noarch: W: non-standard-gid /var/lib/zarafa/z-push/state apache
3 packages and 0 specfiles checked; 0 errors, 4 warnings.

Well, these directories have to be writable by the webserver user.

This is not my first package in Fedora nor do I need a sponsor.

Rest of default questions should be already satisfied with comments before.

Please understand how z-push works and why z-push and zarafa-z-push packages
are required before claiming the schema. Note, that both packages do not
exclude each else necessarily, so no conflict is needed, there are no real 
overlaps.

Hmmm, I wouldn't call that "GPLv2 with exceptions", but rather "GPLv2 with extra restrictions".

The way this is worded bans even distribution to the US from outside the US, which makes us non-US folks responsible for enforcing US patent law, I wouldn't call this acceptable (and I'm not sure this is really compliant with section 8 of the GPLv2 either, but if it's not, it'd just make the license contradictory and the program entirely undistributable). In particular, how is RPM Fusion or its mirrors to prevent US users from downloading the software? By letting US users download the software, they'll be violating the license!

I don't understand why they have to write this in the license at all, pretty much all the other patent-encumbered software does fine without such a clause (Xvid removed theirs, most others never had it in the first place).

If this goes anywhere, it definitely needs to go to non-free.

Personally, I don't care what the exact license tag string is. Maybe even and
simply "GPLv2 without US"?

Tom agreed in IRC some time ago, that z-push is something for RPM Fusion as
a non-free package only. The basic issue is IMHO similar to MP3, but I'm not
a lawyer. And there, we allow downloads from the US for that too, right?

Point behind this clause is, that "ActiveSync over-the-air" is maybe covered
in the US by Microsoft etc. As Z-push is written by a German company (!),
they could be made directly legal responsible for their work, so their lawyer 
checked the situation for non-US and suggested exclusion of US via licensing,
at least is that what I know and understood when talking to them. The clause
8 itself allows such additions, if I got Tom correct.

I think, it's unnecessary to say, Tom == Fedora Legal, but just documentation
reason here. As far as I know, most RPM Fusion mirrors are anyway in Europe, 
not in the US. If you think, that we need legal clarification here, introduce
RF_LEGAL blocker and inherit e.g. Fedora Legal here. I'm pretty sure, Tom is
willing to help - otherwise please let us continue :)

(In reply to comment #5)
> Personally, I don't care what the exact license tag string is. Maybe even and
> simply "GPLv2 without US"?
> 
> Tom agreed in IRC some time ago, that z-push is something for RPM Fusion as
> a non-free package only. The basic issue is IMHO similar to MP3, but I'm not
> a lawyer. And there, we allow downloads from the US for that too, right?
MP3 case means: the code itself is redistributed in a FOSS valid License despite the mp3 codec mechanism idea is patented.
Here, the license is worded in a sense that it restricts the GPL which makes it theoretically not redistributable even for us, since it would be a GPL violation.
(we refused to redistribute some version of faad some time ago, which fall under this case).
Now I wouldn't abuse anyone (IANAL), but the american low, by qualifiying as illegal FOSS that implement patented idea, already restricts the GPL. In this case, z-push only puts this in license words.

 
One could say, if the American law is modified (dreaming), the z-push "GPL restriction" also fall. But the fact that the "restriction" is written within the license suggest it will be inherited within other version. This is unfortunate.

Figured I'd chime in here to clarify things a bit:

The z-push license is an odd duck, because it invokes clause 8 of the GPLv2:

"8.  If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License."

Thus, strictly speaking, the z-push license is not non-free, at least according to the FSF, because they're invoking clause 8 explicitly for the US. Unfortunately, Fedora can't distribute anything under those terms because we're based in the US.

So, this is very similar to the MP3 situation, where the code is FOSS licensed, but due to US patents, we cannot include it in the US (which is why the upstream invoked clause 8). If those patents were to expire, or the patent laws were to change somehow in the US, I think it is extremely likely that the z-push upstream would drop their clause 8 invocation.

I'd suggest tagging this as:

License: GPLv2 with clause 8 invoked (distribution in the US is forbidden)

> Point behind this clause is, that "ActiveSync over-the-air" is maybe covered
> in the US by Microsoft etc.

"Maybe" is not enough to invoke clause 8, they need to prove that there's a patent banning it in the US. Otherwise they're not compliant with the GPL and thus their licensing is contradictory.

(In reply to comment #8)
> > Point behind this clause is, that "ActiveSync over-the-air" is maybe covered
> > in the US by Microsoft etc.
> 
> "Maybe" is not enough to invoke clause 8, they need to prove that there's a
> patent banning it in the US. Otherwise they're not compliant with the GPL and
> thus their licensing is contradictory.

I have a high degree of confidence that there are Microsoft-held patents in the US. If this came in without clause 8 today, I would still reject it. 

(In reply to comment #9)

> I have a high degree of confidence that there are Microsoft-held patents in the
> US. If this came in without clause 8 today, I would still reject it. 

Heh, that didn't come out very clear. I have a high degree of confidence that z-push _infringes_ existing active Microsoft patents in the US.

(In reply to comment #7)
> Figured I'd chime in here to clarify things a bit:

thx spot

> [...]
> Thus, strictly speaking, the z-push license is not non-free, at least according
> to the FSF, because they're invoking clause 8 explicitly for the US.
> Unfortunately, Fedora can't distribute anything under those terms because we're
> based in the US.

I for one would nevertheless would say this should go to RPM Fusion's nonfree repo, as nonfree implies "you should check the license to make sure you are actually allowed to use this software" (which might be the case if you are in the US)

> License: GPLv2 with clause 8 invoked (distribution in the US is forbidden)

Sounds good, as this will make it possible to get the relevant information using tools like repoquery without getting the software (and violating the license)

Okay...are there reviewers?

Spec URL: http://labs.linuxnetz.de/bugzilla/z-push.spec
SRPM URL: http://labs.linuxnetz.de/bugzilla/z-push-1.2.1-2.src.rpm

Updated package, because Fabian Arrotin from CentOS found some issues in my
original package when testing it.

Hmmm. I took a closer look at this and would like to get back to some points that already have been raised:

"""
NOTE: According to sec. 8 of the GNU General Public License (GPL), 
Version 2, the distribution of the Program in or to the 
United States of America is excluded from the scope of this license. 
"""

(In reply to comment #4)
> The way this is worded bans even distribution to the US from outside the US,
> [...] In particular, how is RPM Fusion or its mirrors to prevent US users 
> from downloading the software? 

I'd tend to agree in parts. But OTOH and IANAL: I don't think we need to enforce this on a technical basis. A proper page in the wiki, linked on the front page might do the trick if it says something like
"""
- software in the free repos is free has no usage or distribution restriction; see <this page> in the Fedorawiki for details 

- software in the nonfree repo you should check the license of the software before you actually use it, as there might be usage (for example: non-commercial) or distribution restrictions you. Some of them are

 - zsync: [...] 
"""
Something like that would be similar to the "Don't export fedora to Iran, North Korea, ..." Fedora has.

(In reply to comment #5)
> As far as I know, most RPM Fusion mirrors are anyway in Europe, 
> not in the US. 

http://mirrors.rpmfusion.org/mm/publiclist/

<drumroll>And the number 1 country with most RPM Fusion mirrors is: US
</drumroll><applause/>

Six mirrors to be precise. FR gets the second place with only three mirrors. 

And that were only public mirrors. There are likely private mirrors as well and by taking this package we might bring the owners of those into trouble :-/

nobody commented here or on the list :-/

I consider to just move forward with the review; we can always remove the package later if people complain later instead of now

BTW, and just curious: did anybody check how debian handles this package?

okay, robert contacted a few mirror admins and ask them for their option; we got some replies and further discussed the issue on Fudcon in personal today. We agreed to basically do this:

- I review the package with the intention to include it in the nonfree (even if it's kind of free, but it has a restriction which might make it nonfree in some peoples eyes) repository later
- we send an announcement to the mirror admins in the US soon to make sure that this package is coming in a few weeks; that way they can update their mirror scripts to exclude this package from syncing
- we also add a short note to the text mirrormanager shows new mirror admins to make sure they get aware of this issue
- that text mentions a wiki page (which will get created) that explains the issue and lists problematic packages like this 
- we add a short "README" to the wiki and the mirror somewhere that mentions this issues and basically says "before using or redistributing nonfree software make sure it's legal to do so where you are"

Does that sound fine for everyone? If not please speak up over the next few days, tia!

Spec URL: http://labs.linuxnetz.de/bugzilla/z-push.spec
SRPM URL: http://labs.linuxnetz.de/bugzilla/z-push-1.2.2-1.src.rpm

Sorry, I wanted to review this weeks ago but was really busy with ohter issue; I apologize for the long delay

General comment: the spec file is really scary; but well, I see no easy and long-term-safe way how to clean that mess :-/

I noticed two things where I'm not really sure if they are right as they are:

- Will this part from the file section work if apache is not yet installed? 
%attr(-,apache,apache) %dir %{_localstatedir}/lib/zarafa/%{name}/state/
Afaics the user is created as a %pre script in apache, so I guess it won't work. Maybe a "Requires(pre):" will do it (not sure, I never packaged or reviewed PHP stuff up to now). Or am I missing something? And will that apache perm really work if other webservers are used?

- Is "Requires: php >= 4" really the proper way for the dep here? Shouldn't that be something like "php-api = %{php_apiver}" (at least on current Fedora? might be different in EL land...)

Some other comments, just for completeness:

- Hmm, the license field is quite long an kind of breaks the output of "rpm -qip z-push-1.2.2-1.src.rpm" -- but I see no easy way around that :-/

- is there any chance to get those patches and config files (or a different solution to solve the problem at hand) upstream?

- this install document afaics might be helpful even for users of this rpm, so you might want to consider shipping it (maybe in a adjusted way?) 

- did not try if this package actually works; trusting the packager in this regard

- rpmlint:

arafa-z-push.noarch: W: invalid-license GPLv2 with clause 8 invoked
zarafa-z-push.noarch: W: invalid-license distribution in the US is forbidden
z-push.noarch: W: invalid-license GPLv2 with clause 8 invoked
z-push.noarch: W: invalid-license distribution in the US is forbidden
z-push.src: W: invalid-license GPLv2 with clause 8 invoked
z-push.src: W: invalid-license distribution in the US is forbidden
3 packages and 0 specfiles checked; 0 errors, 6 warnings.

forgot something: should this package name start with "php-" ?

(In reply to comment #18)
> - Will this part from the file section work if apache is not yet installed? 
> %attr(-,apache,apache) %dir %{_localstatedir}/lib/zarafa/%{name}/state/
> Afaics the user is created as a %pre script in apache, so I guess it won't
> work. Maybe a "Requires(pre):" will do it (not sure, I never packaged or
> reviewed PHP stuff up to now). Or am I missing something? And will that apache
> perm really work if other webservers are used?

The RPM dependency ordering causes z-push -> php -> httpd, which are installed
in the reversed order during dependency satisfy. It will work the same way, as
phpMyAdmin, phpPgAdmin and phpldapadmin are doing for example. You're right, I
should replace "webserver" by "httpd" like e.g. phpldapadmin is doing. Thanks
for pointing out that.

> - Is "Requires: php >= 4" really the proper way for the dep here? Shouldn't
> that be something like "php-api = %{php_apiver}" (at least on current Fedora?
> might be different in EL land...)

The php-api dependency is only required for binaries, that depend on the PHP
ABI and would break if ABI changes, but soname doesn't change. The scripts do
not depend on any ABI, they are just interpreted at runtime. It's like at Perl
I would say. Yes, when reading http://fedoraproject.org/wiki/Packaging:PHP, 
it's not very clear.

> - Hmm, the license field is quite long an kind of breaks the output of "rpm
> -qip z-push-1.2.2-1.src.rpm" -- but I see no easy way around that :-/

We could trunicate to "GPLv2 without distribution in the US" which is a bit
shorter maybe. But breaks the output, too.

> - is there any chance to get those patches and config files (or a different
> solution to solve the problem at hand) upstream?
> 
> - this install document afaics might be helpful even for users of this rpm, so
> you might want to consider shipping it (maybe in a adjusted way?) 

I'm working together with upstream to try to get rid of this. The problem is,
that z-push can be used in two ways: One is for Zarafa, the original way and
for second for IMAP/Maildir/vCard. But you can use both in parallel as well.
Upstream tells just to do two z-push installs then. As z-push is mostly used
for Zarafa per default and by history and it can be provided in a configure-
free way, I split this up into two packages - which also avoids to require the
Zarafa package with php-mapi by default for Z-Push <-> IMAP/Maildir/vCard only
users. Main problem behind is, that RPM in Fedora still doesn't support soft 
dependencies (unsatisfied dependencies), so these split-up, patches etc.

The INSTALL document from the tarball is shipped in two different slightly 
modified ways with each RPM package as README, so that it is suitable and hopefully doesn't confuse end users. Just compare INSTALL and README files.

> - did not try if this package actually works; trusting the packager in this
> regard

Thank you, package is already in use at customers at work and by some other
Zarafa and/or CentOS users.

> forgot something: should this package name start with "php-" ?

No, it's not a PHP extension but a software using PHP. Like not every software
depending on Perl is called perl-* for example.

Hopefully I clarified things a bit. It's a tricky situation, I know.

(In reply to comment #20)
> The RPM dependency ordering causes z-push -> [...] You're right, I
> should replace "webserver" by "httpd" like e.g. phpldapadmin is doing. Thanks
> for pointing out that.

k, will wait for that then

> > - Hmm, the license field is quite long an kind of breaks the output of "rpm
> > -qip z-push-1.2.2-1.src.rpm" -- but I see no easy way around that :-/
> We could trunicate to "GPLv2 without distribution in the US" which is a bit
> shorter maybe. But breaks the output, too.

So it's not worth it afaics; leave it as it is

Spec URL: http://labs.linuxnetz.de/bugzilla/z-push.spec
SRPM URL: http://labs.linuxnetz.de/bugzilla/z-push-1.2.2-2.src.rpm

took another look; consider this sort of approved; but I'd like to finish the other things mentioned in comment #15 fist (e.g. the readme and the announcement) before I officially approve this. Putting that readme into the package might be something to consider as well. 

I'd argue the implications of (in this instance) an enforced GPL section 8 clause is part of the non-free repository already -thinking in terms of the potentially dangerous software patent encumbered software already in that repository, mirrors/users/entities are already "required" to carefully consider mirroring everything in the non-free repository.

Spec URL: http://labs.linuxnetz.de/bugzilla/z-push.spec
SRPM URL: http://labs.linuxnetz.de/bugzilla/z-push-1.3-1.src.rpm

Resulting binary RPM packages:
-> http://labs.linuxnetz.de/bugzilla/z-push-1.3-1.noarch.rpm
-> http://labs.linuxnetz.de/bugzilla/zarafa-z-push-1.3-1.noarch.rpm

Spec URL: http://labs.linuxnetz.de/bugzilla/z-push.spec
SRPM URL: http://labs.linuxnetz.de/bugzilla/z-push-1.5.1-1.src.rpm

This is a new release of Z-Push, which is licensed under the same terms and
conditions like Zarafa (AGPLv3). There is no longer a non-US restriction. That
means, Z-Push can be handled now equivalent at RPM Fusion like MP3.

Spec URL: http://labs.linuxnetz.de/bugzilla/z-push.spec
SRPM URL: http://labs.linuxnetz.de/bugzilla/z-push-1.5.2-1.src.rpm

This is a new release of Z-Push, which is licensed under the same terms and
conditions like Zarafa (AGPLv3). There is no longer a non-US restriction. That
means, Z-Push can be handled now equivalent at RPM Fusion like MP3. It also
includes now the written permission from Zarafa that RPM Fusion is allowed to
ship a modified copy of Z-Push under the name Z-Push.

= Heads up for @rpmfusion-developers-list =

This package afaics aims the free repo these days; it's "AGPLv3 with exceptions". Here is the exception (copy'n'pasted from index.php):

* According to sec. 7 of the GNU Affero General Public License, version 3,
* the terms of the AGPL are supplemented with the following terms:
*
* "Zarafa" is a registered trademark of Zarafa B.V.
* "Z-Push" is a registered trademark of Zarafa Deutschland GmbH
* The licensing of the Program under the AGPL does not imply a trademark license.
* Therefore any rights, title and interest in our trademarks remain entirely with us.
*
* However, if you propagate an unmodified version of the Program you are
* allowed to use the term "Z-Push" to indicate that you distribute the Program.
* Furthermore you may use our trademarks where it is necessary to indicate
* the intended purpose of a product or service provided you use it in accordance
* with honest practices in industrial or commercial matters.
* If you want to propagate modified versions of the Program under the name "Z-Push",
* you may only do so if you have a written permission by Zarafa Deutschland GmbH
* (to acquire a permission please contact Zarafa at trademark@zarafa.com).

The file permission.pdf contains a written permission, that allows us to call our package z-push. 

So IOW and roughly speaking: the situation is similar to Firefox in Fedora, but not as strictly handled afaics. That's fine for me, but other RPM Fusion developers should have a chance to raise concerns. Hence I'll wait until at least Tuesday next week before I approve this package; of course we can always rename the package later or move it to the nonfree repo if we want to.

= Review =

Ony a few minor things:

 * I for one find the spec file line
License:	AGPLv3 with exceptions
 confusing, as the "with exceptions" is not explained anywhere in an obvious place. I'd say a clarifying comment or section in the README.FEDORA.package would be a good idea. Normally I'd say you should bug upstream to add it to LICENSE or create a file LICENSE.exception instead of adding it to files like index.php only, as people might not see it there and think it's a regular AGPLv3

 * BTW, I'd give files like README.FEDORA.package a prefix with %{name} in the SRPM, as otherwise bad things bappen when people install multiple SRPMs that contain files with that name

 * rpmlint gives a warning on the SRPM:
z-push.src:11: W: mixed-use-of-spaces-and-tabs (spaces: line 11, tab: line 3)

 * should zarafa-z-push have a dep on zarafa or something else that owns /etc/zarafa/?

Comment on those and I'll approve it nobody complains about the naming.

Spec URL: http://labs.linuxnetz.de/bugzilla/z-push.spec
SRPM URL: http://labs.linuxnetz.de/bugzilla/z-push-1.5.3-1.src.rpm

This is a new release of Z-Push, which also should solve the raised valid
concerns by Thorsten.

(In reply to comment #28)
>  * I for one find the spec file line
> License:        AGPLv3 with exceptions
>  confusing, as the "with exceptions" is not explained anywhere in an obvious
> place. I'd say a clarifying comment or section in the README.FEDORA.package
> would be a good idea. Normally I'd say you should bug upstream to add it to
> LICENSE or create a file LICENSE.exception instead of adding it to files like
> index.php only, as people might not see it there and think it's a regular
> AGPLv3

Good catch! I opened a bug in upstream tracker and in the meantime the issue
got fixed in upstream SVN. Until the next release I'm shipping a patch within
the z-push package. More details are within the *.patch file.
 
>  * BTW, I'd give files like README.FEDORA.package a prefix with %{name} in the
> SRPM, as otherwise bad things bappen when people install multiple SRPMs that
> contain files with that name

Fixed. I added the prefix "%{name}-" to remaining SourceX files.
 
>  * rpmlint gives a warning on the SRPM:
> z-push.src:11: W: mixed-use-of-spaces-and-tabs (spaces: line 11, tab: line 3)

Fixed as well.

>  * should zarafa-z-push have a dep on zarafa or something else that owns
> /etc/zarafa/?

Another good catch! I added ownership of /etc/zarafa/ to zarafa-z-push, as I
think, section "The directory is owned by a package which is not required for 
your package to function" from the Fedora Packaging Guidelines
http://fedoraproject.org/wiki/PackagingGuidelines#File_and_Directory_Ownership
should apply here. And yes, I spent some time whether a -filesystem subpackage
makes sense or not, but for now it doesn't make sense, because z-push is the
only exception. Once this changes (which is very unlikely), I'll introduce of
course a -filesystem subpackage.

APPROVED

Thank you very very much for your time, efforts and work, Thorsten!


Package CVS request
======================
Package Name: z-push
Short Description: ActiveSync over-the-air implementation for mobile syncing
Owners: robert
Branches: EL-5 EL-6 F-14 F-15
InitialCC: 
----------------------
License tag: free

/var/lib/z-push is not writable by httpd process.

semanage fcontext -a -t httpd_sys_content_t '/var/lib/z-push(/.*)?'
restorecon -rv /var/lib/z-push

helps but a proper permanent solution may be needed.

SELinux is on the map, when Z-Push is in RPM Fusion and things settled a bit.

CVS branching was not 100% successful as it seems? Works on all other branches...

**** Access denied: robert is not in ACL for rpms/z-push/devel
cvs commit: Pre-commit check failed
cvs [commit aborted]: correct above errors first!

[00:42:05] < kwizart> rsc, can you retry for devel ?
[00:42:53] < rsc> kwizart: looks better now...
[00:43:03] < kwizart> k
[00:43:30] < kwizart> new cvs module script are still broken, appears sometime
[00:43:43] < rsc> ah

9693 (z-push): Build on target fedora-development-rpmfusion_free succeeded.
9694 (z-push): Build on target fedora-15-rpmfusion_free succeeded.
9695 (z-push): Build on target fedora-14-rpmfusion_free succeeded.
9696 (z-push): Build on target el-6-rpmfusion_free succeeded.
9697 (z-push): Build on target el-5-rpmfusion_free succeeded.

I'll close this review request once these first package were pushed to the
updates-testing repos. At the moment, it's a reminder for myself to look if
the push happened already.