Spec URL: http://rdieter.fedorapeople.org/rpms/poppler-data/poppler-data.spec
SRPM URL: http://rdieter.fedorapeople.org/rpms/poppler-data/poppler-data-0.2.1-1.fc11.src.rpm
This package consists of encoding files for poppler. When installed,
the encoding files enables poppler to correctly render CJK and Cyrillic
The contents here are currently bundled in the poppler package. Since uspstream distributes this part separately, it makes sense to package this (noarch) content separately as well.
License: Redistributable, no modification permitted
here, may require licensing exception similar to firmware.
Blocking FE-legal for licensing clarification for "no modification permitted"
The more I think about it, the more black and white it is ... this content can't possibly be acceptable for fedora.
Gosh, I've never dealt with content before. Re-reading,
" The one exception is that we permit content (but only content) which restricts modification as long as that is the only restriction."
So my take is that we're still a go.
I agree that this is most likely acceptable content, though I'll keep FE-Legal in place and won't approve until that gets acked. However, we're already shipping this data in our release branches, it's not really small and has a completely different release cycle, so splitting it out makes sense in any case.
Packaging-wise, this is trivial and looks fine. Just waiting for FE-Legal clearance.
* source files match upstream. sha256sum:
* 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.
* license field matches the actual license.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper (none).
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* rpmlint is silent.
* final provides and requires are sane:
poppler-data = 0.2.1-1.fc12
* 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.
* seems acceptable content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
It seems that FESCo took up this issue, although it looks like there were talking about something different. See http://meetbot.fedoraproject.org/fedora-meeting/2009-07-10/fedora-meeting.2009-07-10-17.00.html (Adobe CMap files - code or content?) and https://fedorahosted.org/fesco/ticket/177.
That seems to answer one question (the legal one) but begs another: is this package duplicating something that's already in ghostscript? Can the data be unified and shared between the two packages?
Oh, I just noticed that this already blocks the relevant ghostscript bug. This package already has the appropriate license tag as indicated in bug 487510, so I'd say that we're good to go.
New Package CVS Request
Package Name: poppler-data
Short Description: Encoding files
Owners: please clone poppler acl's (else, me: rdieter)
InitialCC: please clone poppler acl's
There are eighteen people in the commit ACL alone for poppler. Honestly I'd prefer not to go spamming them all when they might not particularly care. So I've added the ACL with just you, and the rest of the folks are welcome to add themselves. I'm happy to do that and save the web form clicking if they ping me.
fair nuff, thanks.
Is there any reason for this ticket to remain open?
Nope, thanks for the poke.