Bug 233423

MUST:
=====
* rpmlint output is: <empty>
* Package and spec file named appropriately
* Packaged according to packaging guidelines
* License ok
* spec file is legible and in Am. English.
* Source matches upstream
* Compiles and builds on devel x86_64
* BR: ok
* No locales
* No shared libraries
* Not relocatable
* Package owns / or requires all dirs
* No duplicate files & Permissions
* %clean & macro usage OK
* Contains code only
* %doc does not affect runtime, and isn't large enough to warrent a sub package
* no -devel package needed
* no .desktop file required

Approved!

One remark though, why meccab-python, but for ruby ruby-mecab, wouldn't it be
better to also call this python-mecab?

Thinking about this some more, according to:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-8756a3bce652c376d7ba3908461b638784b6952d

This must be named python-mecab, unapproving.

Must-fix:
=========
* Change name to python-mecab

Well,

* This is a Python binding for MeCab, so the main package is
  mecab, not python. i.e. This is rather a subpackage of mecab
  and very similar with paragui-python.

  And... actually for ruby-mecab:
--------------------------------------------------------
These naming guidelines only apply to ruby packages whose main purpose is
providing a Ruby library; packages that mainly provide user-level tools that
happen to be written in Ruby do not need to follow these naming guidelines,
and should follow the general  NamingGuidelines instead.
---------------------------------------------------------
  so.. IMO I have to rename from ruby-mecab to mecab-ruby...

* If mecab-python should be renamed to python-mecab, so are
  mecab-perl, mecab-java? I think it is quite questionable.

(In reply to comment #3)
> Well,
> 
> * This is a Python binding for MeCab, so the main package is
>   mecab, not python. i.e. This is rather a subpackage of mecab
>   and very similar with paragui-python.
> 
>   And... actually for ruby-mecab:
> --------------------------------------------------------
> These naming guidelines only apply to ruby packages whose main purpose is
> providing a Ruby library; packages that mainly provide user-level tools that
> happen to be written in Ruby do not need to follow these naming guidelines,
> and should follow the general  NamingGuidelines instead.
> ---------------------------------------------------------
>   so.. IMO I have to rename from ruby-mecab to mecab-ruby...
>

No,

The part quoted from the ruby guidelines, is identical for python. In both cases
the exception is for applications, since an application shouldn't be called
python-fee just because its written in python. In this case we are talking about
bindings, iow they make mecabs functionality available to applications written
in python/ruby. Thus they should be called python-mecab and ruby-mecab, this is
so that people looking for python "libs" can find them easily by doing "yum list
'py*'" .

About paragui, things are different there as the binding is in the main lib
package, and the correct name for the main package obviously is paragui, thus a
python subpackage automatically becomes paragui-python, this is an exception I
think. But maybe even there it should get called python-paragui by using
"%package -n python-paragui" instead of "%package python"

In this however these are seperate packages from the main package and thus must
be called python-mecab and ruby-mecab according to my reading of the guidelines,
if you disagree, please discuss this on the list.

> * If mecab-python should be renamed to python-mecab, so are
>   mecab-perl, mecab-java? I think it is quite questionable.

Yes, the same goes for perl modules according to:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-8756a3bce652c376d7ba3908461b638784b6952d

And I cannot find anything for java, so choose what you like I guess.

Then would you check these?

http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/python-mecab.spec
http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/python-mecab-0.95-2.fc7.src.rpm

* Sat Mar 31 2007 Mamoru Tasaka <mtasaka.u-tokyo.ac.jp> - 0.95-2
- A bit clean up
- change the name to python-mecab

Looks fine now, approved!

Thank you!!

Request for CVS admin:

New Package CVS Request
=======================
Package Name:           python-mecab
Short Description:      Python binding for MeCab
Owners:                 mtasaka.u-tokyo.ac.jp
Branches:               devel FC-6 FC-5
InitialCC:              (nobody)

(In reply to comment #6)
> Looks fine now, approved!
Hmm, I don't see any applicable license, copyright not even any mention of an
author.

IMO, it's illegal to ship this package.

For license:

The license is actually the same as the main part of mecab
(upstream declares), and this binding is simply gerenated
automatically by using swig. So there is no problem.

Anyway I asked upstream to include License document explicitly.

And.. please understand currently I am _very_ careful for
license...

(In reply to comment #9)
> For license:
> 
> The license is actually the same as the main part of mecab
> (upstream declares), and this binding is simply gerenated
> automatically by using swig. So there is no problem.
There are SEVEREST probles:

You are packaging unlicensed, uncopyrighted sources.

To formulate it into a devil's advocate argument: You are shipping unowned
sources, you or upstream probably have stolen somewhere, very likely from
Microsoft or SCO - Now prove this claim wrong!

Please don't speek in so aggressive word...

You may use English as your first or second language,
however, I am not and I cannot understand what
you want to say by "devil's advocate argument"...
for me the word seems _very_ aggressive to me
and I hear it as if you are criticizing my personality.....

Ralf,

I don't see the big problem here ?? I do see a small problem though: Mamoru, I
seem to have missed the fact (my bad) that you have included a modified tarbal
in the SRPM, with license files added. Don't do that! Please provide a new
version with the original tarbal and include a README.fedora pointing to the
license docs in /usr/share/doc/mecab-0.95, those should always be present since
python-mecab Requires mecab. 

Ralf Mamoru is very carefull about licenses AFAIK, for one of the mecab-XXXX
dictionaries I reviewed he explicitly asked Spot if the license was ok. Also the
main mecab is under the BSD/GPL/LGPL, and the main mecab docs refer to this
package as if its an integral part (for as far as I can read japanese) , add to
that the this is distributed from the same website as the main package, has the
same author (which is listed in the original tarbal) , and is indeed all
autogenerated with swig, and I don't see any real problem. We have more packages
where the website says this is GPL, but they forgot to add any license to the
tarbal, there we always request upstream to fix it and in the mean time ship it
as is. So I agree that the adding off licenses by Mamoru is bad, but that
doesn't amke this whole package bad.

Hans,

Well, I didn't modify tarball. So the tarball in srpm does
not contain License documents. Currently I copy the license
documents from the main part of mecab
---------------------------------------------
# LICENSE
for doc in COPYING BSD GPL LGPL ; do
	%{__install} -cpm 644 %{_datadir}/doc/mecab-%{version}/$doc .
done
---------------------------------------------

You prefer to simply add License.Fedora which says "license documents
are included in main mecab rpm"?

NOTE:

It seems that my account on my university seems to have expired today....
and sadly, today is Sunday. So while I can upload a modified
spec file as attached, I cannot upload the whole srpm until
I have my account again fixed....

p.s.

(In reply to comment #8)
> (In reply to comment #6)
> > Looks fine now, approved!
> Hmm, I don't see any applicable license, copyright not even any mention of an
> author.
> 
You didn't look very good then the README clearly states the author.

(In reply to comment #14)
> Hans,
> 
> Well, I didn't modify tarball. So the tarball in srpm does
> not contain License documents. Currently I copy the license
> documents from the main part of mecab
> ---------------------------------------------
> # LICENSE
> for doc in COPYING BSD GPL LGPL ; do
> 	%{__install} -cpm 644 %{_datadir}/doc/mecab-%{version}/$doc .
> done
> ---------------------------------------------
> 

Ah that explains, when I reviewed this I didn't notice. Now I understand, I was
already puzzled how I could have missed a modified tarbal as I always check for
that. Yes please add a License.fedora instead, thats more acurate / honest.

I'm still waiting to hear from Ralf on this though, if my arguments are not
enough to convince him that this package is OK license-wise, we will need to ask
someone with more "powers" to make a judgement on this, for example Spot.

(In reply to comment #15)
> NOTE:
> 
> It seems that my account on my university seems to have expired today....
> and sadly, today is Sunday. So while I can upload a modified
> spec file as attached, I cannot upload the whole srpm until
> I have my account again fixed....

Once the license issue is cleared, you can just attach the modified specfile 
and License.fedora .

Upstream replied to me that they will include license explicitly
from next version 10 minutes ago.

Okay, thats good! Let me guess the reply is in japanese? If you can get upstream
to send you a mail in English stating that mecab-python / ruby / perl / java are
under the same license as mecab itself. Then that would end all doubts
surrounding the licensing and we can move forward.

Once you have that mail include that mail in a License.fedora, and refer the
reader to the main mecab License files in that same License.fedora document.

Warren,

What does the setting of fedora-review to + by you mean, does that mean that you
are happy with the given license explanation and the package as reviewed
initially can be imported? or ?

(In reply to comment #13)
> I don't see the big problem here ??
I do see a SHOWSTOPPER: This package IS NOT PROPERLY LICENSED - Period.

As such it CAN NOT be shipped as part of Fedora.

Hmm, I didnt intentionally set fedora-review+.  That was a mistake on my part.

It seems to me that Ralf is just being a hard ass like usual.  But it is
reasonable to wait until after upstream makes a new release that has explicit
licenses before building this package.

(In reply to comment #21)
> Hmm, I didnt intentionally set fedora-review+.  That was a mistake on my part.
> 
> It seems to me that Ralf is just being a hard ass like usual.
Watch your language, Togami - There might be a language barrier hitting, but are
you really name-calling me as an "arse"?

>  But it is
> reasonable to wait until after upstream makes a new release that has explicit
> licenses before building this package.

There is no doubt that this package violates:
http://fedoraproject.org/wiki/Packaging/Guidelines#head-76294f12c6b481792eb001ba9763d95e2792e825
because it doesn't contain any licence/copyright notice nor any indication that
Fedora is legimitated to ship this package.

We have seen packages banned for far less.

Any progress on the license issue? Perhaps we should ask Spot otherwise, he is
sorta the authority on license issues.

Not yet. Upstream said that they would add license text explicitly
in the next version, however it seems that they don't want to release
next version only for license text inclusion.

You could try asking Spot if the mail from upstream that the license text will
be added is enough for now.

(In reply to comment #25)
> You could try asking Spot if the mail from upstream that the license text will
> be added is enough for now.

Including a copy of this mail probably will be. 

The point behind all this is to shift responsibility and liability wrt.
licensing to "upstream" to prevent harm from users and packagers.

I sent a mail to spot about license issue of this package.

spot replied:

------------------------------------------------
If you have a copy of upstream saying that the files are under the same
license as the rest of MeCab, I would recommend that you included a copy
of that email as a text file in the package until they update with the
license texts included, but I think it is OK for Fedora as is.

~spot
-------------------------------------------------

Well, thats means we can go ahead then, both fedora-review and fedora-cvs flags
are set to +, so you should be able to import it right now.

Well, I must re-read the build procedure because currently
I have not caught up with what is actually changed during
plague -> koji buildsys change...

Rebuilt on all branches, closing.

Thank you for the review!!