Bug 492996

The URL in the spec doesn't seem related.

Can you indicate where you get a license of "Freely redistributable without restriction"?  The only place I can see any indication of a license is in SpecialRenameuser.php and it says GPLv2+.  The upstream web site says "unspecified".  I think it's reasonable to assume that GPLv2+ applies to all five php files since they're distributed together.  It would be nice to query the author about inserting proper license notices as suggested by the GPL.  Also note that in any case, "Freely distributable without restriction" is not sufficiently free for code in Fedora.  We need the right to modify as well.

The README.fedora file mentions InputBox twice.

* source files match upstream.  sha256sum:
  d791117c556ad9af35dc51dbac815ef129e507fcad30db9740bbaa3108bb4f59  
   RenameUserJob.php
  0f73d6727b396dfae1b3fd3126763e74fda852a70204a5d6b98815b3db6d9987  
   SpecialRenameuser.alias.php
  217a14bf162a32a2276b68f4e84ae820711943f259fa4ccb245e535f3aa9a3b1  
   SpecialRenameuser_body.php
  b952cb8b5dd7a636faae2ec15945db877a07ee26b3faf35932c2b59488a20b5a  
   SpecialRenameuser.i18n.php
  0220b4877670f5bc88a2b76e34ff677b44864a3424d4a4ec80ec82e7ef8aafcb  
   SpecialRenameuser.php

* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
X license field does not match the actual license.
* license is open source-compatible.
* license text not included upstream.
* BuildRequires are proper (none, as there
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* rpmlint is silent.
* final provides and requires are sane:
   mediawiki-Renameuser = 0-0.1.20090331svn.fc11
  =
   mediawiki >= 1.14

* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no generically named files
* code, not content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.

The package review process needs reviewers!  If you haven't done any package
reviews recently, please consider doing one.

Just an update on the licensing.  I contacted the listed author, and he said that  when he initially wrote the extension, he placed it under GPLv2+.  Since that time, it has been broken up into separate files.  Some of them are derived files and are also under GPLv2+, but he has not written any part of RenameUserJob.php, so he doesn't know what the situation is with that file.

The files SpecialRenameuser.alias.php and SpecialRenameuser.i18n.php are both internationalization files for SpecialRenameuser.php, so I would think that it is safe to call those dervied files.  Also, SpecialRenameuser_body.php is the file that actually generates the Special page for this extension.  Likewise, I would think that would be a dervied work as well.  Moreover, the extension stops working if you remove any of those files.

I am still working on finding out the license status for RenameUserJob.php.

I have verified the license for RenameUserJob.php and it is GPLv2+ as well.  The URL that is listed in the package also lists the license as well.  I have created a new SRPM and a new spec file.  Here are their URLs:

http://www.guthrie.info/RPMS/f10/mediawiki-Renameuser-0-0.2.20090505svn.fc10.src.rpm
http://www.guthrie.info/RPMS/f10/mediawiki-Renameuser.spec

I have run rpmlint on the spec file, the SRPM, and the resulting RPM, and in all cases, rpmlint returns no errors or warnings.

First off, README.fedora still talks about some module called InputBox which doesn't seem related to RenameUser.  Could you fix that up?

Now, we can trust a license indicated on an upstream web site as long as we reasonably believe that the authors of the software in question were the ones who made the indication of the license on that site.  However, in this case, according to the wiki history it's it's you who've made the indication that it's GPLv2+.  So, besides fixing the README.fedora file, I see two options which will allow me to approve this:

1) Spot acks what's being done.  I've blocked FE-Legal to request his input.
2) You include in this package the relevant parts of the email conversations with the authors that you indicated you've had on the upstream wiki page.

Sorry, licensing sucks.

Yeah... can you add the email conversations with upstream(s) where they clarify licensing as a "README.Licensing" in the package?

And it's been over a month since comment #4 with no response.  I guess I'll go ahead and close this soon.

I apologize for the delay.  My life's been a little hectic with a possible move in the works plus trying to find a new job.

I have built a new package with the new file called LICENSE.fedora.  It contains the email conversations that I have had with the authors regarding the licensing.    I've not added any additional text into that file.  Please let me know if I need to add any additional info in that file.

The authors were taking the stance that they have put the license into one of the source code files, and that the rest of the files are derived works so they fall under the same license.  I have not asked regarding an explicit README.Licensing file.

The new SRPM can be found here:  http://www.guthrie.info/RPMS/f11/mediawiki-Renameuser-0-0.4.20090505svn.fc11.src.rpm
Here is the new SPEC file: http://www.guthrie.info/RPMS/f11/mediawiki-Renameuser.spec

(In reply to comment #7)
> The authors were taking the stance that they have put the license into one of
> the source code files, and that the rest of the files are derived works so they
> fall under the same license.  I have not asked regarding an explicit
> README.Licensing file.

I should also add that just general advice on how to proceed with the licensing issue would be appreciated.

OK, I took a look at the package and I only see one remaining issue:  The LICENSE.fedora file isn't UTF-8; it contains 0xC6, which is probably an ISO-8859-15 character.  I guess you've just dumped some email messages to a file, and the message with the character doesn't contain an encoding, but I would suggest that the file is intended to be read as a file, not a mail folder, and so should be UTF-8.  Can you convert it before you import?

The only general advice I can give regarding the license issue is to get everyone to include proper copyright and license statements somewhere in each source file.  I could see authors in the previous century being ignorant of the need to properly license their code, but these days there's really no excuse.  If you want more specific advice, though, you're welcome to contact fedora-legal-list.

APPROVED

(In reply to comment #9)
> OK, I took a look at the package and I only see one remaining issue:  The
> LICENSE.fedora file isn't UTF-8; it contains 0xC6, which is probably an
> ISO-8859-15 character.  I guess you've just dumped some email messages to a
> file, and the message with the character doesn't contain an encoding, but I
> would suggest that the file is intended to be read as a file, not a mail
> folder, and so should be UTF-8.  Can you convert it before you import?

Thank you for the approval and your assistance.  I do have one question though.  You were correct in that the LICENSE.fedora file is a dump of emails.  I was wondering if you had nay suggestions on any explanatory text that I might want to include in that file, or if those emails can stand on their own?

(In reply to comment #9)
> OK, I took a look at the package and I only see one remaining issue:  The
> LICENSE.fedora file isn't UTF-8; it contains 0xC6, which is probably an
> ISO-8859-15 character.  I guess you've just dumped some email messages to a
> file, and the message with the character doesn't contain an encoding, but I
> would suggest that the file is intended to be read as a file, not a mail
> folder, and so should be UTF-8.  Can you convert it before you import?

> APPROVED  

The UTF8 issue has been fixed, and the package is ready for import.

New Package CVS Request
=======================
Package Name: mediawiki-Renameuser
Short Description: An extension that provides a special page for renaming user accounts
Owners: guthrie
Branches: F-10 F-11
InitialCC:

CVS done.

So I just imported the package into the devel branch, and I received the following email bounce:

This is the mail system at host cvs1.fedora.phx.redhat.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mediawiki-Renameuser-owner>: host bastion[10.8.34.50] said:
    550 5.1.1 <mediawiki-Renameuser-owner>: Recipient address
    rejected: User unknown in local recipient table (in reply to RCPT TO
    command)


Now I know that the email said to send a report to postmaster, but I'm also worried that such an email will get lost in a flood of spam.  (I.e., postmaster can often be a spam magnet, especially on high profile domains.)  Also, I'm guessing that this is more of an issue with the account system as opposed to the mail system anyway.  So my question is to whom should I send this report to?

There's a delay between package creation and the propagation of the aliases to the mail server.

You set the fedora-cvs flag; did you need something from the CVS admins?  It sure seems like the proper CVS branches were created when I set up the package.

Thank you very much for the explanation.  I was concerned that the above mail issue might have been CVS-related since I was thinking that the mail address would have been created at the same time as the CVS branches.  I have unset the flag as it seems that all of the branches seem to be working correctly in all other respects.

(In reply to comment #16)
> I have unset the
> flag as it seems that all of the branches seem to be working correctly in all
> other respects.  

More precisely, I set the CVS flag back to +.

The build has completed in all requested releases.  Closing this review request out.