Spec URL: http://svn.fedorahosted.org/svn/documentation-devel/trunk/Files/documentation-devel-JBoss.spec SRPM URL: http://svn.fedorahosted.org/svn/documentation-devel/trunk/Files/documentation-devel-JBoss-0.4-0.fc9.src.rpm Description: JBoss branded theme for docuemntation-devel.
The license used is the "Creative Commons Attribution-NonCommercial-ShareAlike". There are some troublesome aspects to this license. * This particular license is marked as "bad" on this page; the no-commercial clause is a restriction of freedoms: http://fedoraproject.org/wiki/Licensing * The CC provides no warranty protection, which is why Red Hat Legal has blocked Fedora from using it for formal content that is about specific products; we can use the CC for "generic computer education" Why are you using the NC clause? The JBoss logos are strongly protected by trademark already.
(In reply to comment #1) > The license used is the "Creative Commons Attribution-NonCommercial-ShareAlike". > There are some troublesome aspects to this license. > > * This particular license is marked as "bad" on this page; the no-commercial > clause is a restriction of freedoms: > > http://fedoraproject.org/wiki/Licensing > > * The CC provides no warranty protection, which is why Red Hat Legal has blocked > Fedora from using it for formal content that is about specific products; we can > use the CC for "generic computer education" > > Why are you using the NC clause? The JBoss logos are strongly protected by > trademark already. The main goal here is to allow JBoss writers, developers, and the _extensive_ JBoss community to use Fedora as their main work environment for documentation. The JBoss documentation uses the above license. The xml & images in this package is embedded in the books at build time. I need a license that allows the xml and images to be used in Creative Commons Attribution-NonCommercial-ShareAlike books.
(In reply to comment #2) > The main goal here is to allow JBoss writers, developers, and the _extensive_ > JBoss community to use Fedora as their main work environment for documentation. I'm not sure what you mean by this point? They can choose to use a non-free license if they wish, although I'm don't initially see how the NC helps when it comes to taking community content into formal, Red Hat-produced JBoss (i.e., commercial) documentation. > The JBoss documentation uses the above license. The xml & images in this package > is embedded in the books at build time. Potentially, content from a fully-free usage of a CC license might be blendable with non-free CC licenses. Regardless, the copyright owner can choose to dual-license. Is that Red Hat? > I need a license that allows the xml and images to be used in Creative Commons > Attribution-NonCommercial-ShareAlike books. As in bz #427483, the original copyright holder can choose to dual-license. The NC clause is a restriction of a freedom, making that particular CC license non-free, and therefore not allowed in Fedora.
(In reply to comment #3) > > The JBoss documentation uses the above license. The xml & images in this package > > is embedded in the books at build time. > > Potentially, content from a fully-free usage of a CC license might be blendable > with non-free CC licenses. So maybe if this package was licenced CC then CC(+ all those letters) might be able to use it? > Regardless, the copyright owner can choose to dual-license. Is that Red Hat? > > > I need a license that allows the xml and images to be used in Creative Commons > > Attribution-NonCommercial-ShareAlike books. > > As in bz #427483, the original copyright holder can choose to dual-license. The > NC clause is a restriction of a freedom, making that particular CC license > non-free, and therefore not allowed in Fedora. I'll make someone talk to the lawyers and see how to liecnse this package so it can fit in to Fedora and allow the JBoss folk to use it in there docs.
Clearly there is no demand for this package since no one is bugging me for it.
Or, everyone was waiting for you to resolve the serious licensing issue.
(In reply to comment #6) > Or, everyone was waiting for you to resolve the serious licensing issue. This fully qualifies as not bugging me for it.
Hey, don't look at me, I'm just the janitor. I've no interest in this either. :)
(In reply to comment #1) > The license used is the "Creative Commons Attribution-NonCommercial-ShareAlike". > There are some troublesome aspects to this license. The package is now licensed CC-BY-SA, so this should no longer be a problem. Re-opening request New spec file: https://fedorahosted.org/releases/p/u/publican/publican-jboss.spec New SRPM: http://rlandmann.fedorapeople.org/publican/publican-jboss-1.9-0.fc13.src.rpm
Updated spec and SRPM in light of comments in Bug #427484 New files: http://rlandmann.fedorapeople.org/publican/publican-jboss.spec http://rlandmann.fedorapeople.org/publican/publican-jboss-1.9-1.fc13.src.rpm
Updated spec and SRPM in light of comments in Bug #427484 New files: http://rlandmann.fedorapeople.org/publican/publican-jboss.spec http://rlandmann.fedorapeople.org/publican/publican-jboss-1.9-2.fc13.src.rpm rpmlint now clean: $ rpmlint publican-jboss.spec 0 packages and 1 specfiles checked; 0 errors, 0 warnings. $ rpmlint ../SRPMS/publican-jboss-1.9-2.fc13.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. $ rpmlint ../RPMS/noarch/publican-jboss-1.9-2.fc13.noarch.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings.
(updating summary to reflect current name of package)
For some reason the tarball in the srpm and the tarball downloaded from fedorahosted.org do not match. Jeff, fix this up and I'll do a review.
(In reply to comment #13) > Jeff, fix this up and I'll do a review. Hi Jason; I'm now handling the packaging of Publican and its brand packages for Fedora. I've just uploaded a specfile and srpm for the latest version here: http://rlandmann.fedorapeople.org/publican/publican-jboss.spec http://rlandmann.fedorapeople.org/publican/publican-jboss-2.3-0.fc13.src.rpm rpmlint output: $ rpmlint SPECS/publican-jboss.spec 0 packages and 1 specfiles checked; 0 errors, 0 warnings. $ rpmlint SRPMS/publican-jboss-2.3-0.fc13.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. $ rpmlint RPMS/noarch/publican-jboss-2.3-0.fc13.noarch.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. Thanks for taking a look! Cheers Rudi
Oh, OK. It's generally best if you open your own bugs, especially since these ancient ones seem to be overlooked by everyone except me. Generally you should start your release with 1; releases less than 1 are reserved for prerelease packages. I'm assuming that you're just doing that for the purposes of the review; it's usually best to present the package as you would have it imported. The URL is not correct; at least, it only gets me to a list of fedorahosted projects. Is there any point to the docuemntation-devel-JBoss stuff? As far as I can tell, there was never a package with that name in Fedora. As expected for a review ticket of this age, there are a few lines in the spec which are not required for modern Fedora (BuildRoot:, first line of %install, and for F13+, the entire %clean section). I would suggest removing them unless you intend to target EPEL{4,5} (which I don't believe is possible, since publican there is hopelessly ancient). * source files match upstream. sha256sum: 47c12c97198dc62defb0f0c5f9bbe80171ec3736a467180e8d010d99d758241c publican-jboss-2.3.tgz * 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. * license field matches the actual license. * license is open source-compatible. * license text included in package. * latest version is being packaged. * BuildRequires are proper. * package builds in mock (rawhide, x86_64). * package installs properly. * rpmlint is silent. ? final provides and requires: ? documentation-devel-JBoss = 2.3-0.fc15 publican-jboss = 2.3-0.fc15 = publican >= 2.0 * 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.
(In reply to comment #15) > The URL is not correct; at least, it only gets me to a list of fedorahosted > projects. Oops! Corrected. > Is there any point to the docuemntation-devel-JBoss stuff? As far as I can > tell, there was never a package with that name in Fedora. There were builds of that package used internally at Red Hat; they didn't make it into the wider world since this review stalled, but they certainly existed. The build linked by Jeff when he originally opened this review request was one of these. > As expected for a review ticket of this age, there are a few lines in the spec > which are not required for modern Fedora (BuildRoot:, first line of %install, > and for F13+, the entire %clean section). I would suggest removing them unless > you intend to target EPEL{4,5} (which I don't believe is possible, since > publican there is hopelessly ancient). Yeah, this won't work with Publican 0 (and the deps in EPEL are to old for any later Publican) -- however, Red Hat has builds of Publican 2 and its brand packages for Red Hat Enterprise Linux 5 for internal use, so I'd like to keep these items here to avoid having to maintain separate spec files. Thanks again! Rudi
New spec and SRPM http://rlandmann.fedorapeople.org/publican/publican-jboss.spec http://rlandmann.fedorapeople.org/publican/publican-jboss-2.3-1.fc13.src.rpm
Sure, it's up to you if you want to keep that cruft around. Generally I'd recommend removing the docuemntation-devel-JBoss stuff as soon as is feasible because it can be a bit confusing. Anyway, everything looks good now. APPROVED
New Package SCM Request ======================= Package Name: publican-jboss Short Description: common files and templates needed to build documentation with the JBoss brand with Publican. Owners: jfearn rlandmann Branches: f13 f14 InitialCC:
Git done (by process-git-requests).
Is there any reason why this ticket is still open?