I'd like to submit the attached package for inclusion into Fedora.
Where are your spec/srpm?
Hmm, something went wrong in my attempt to attach it. Here are external links: http://synopsis.fresco.org/download/srpm/qmtest-2.4-1.fc9.src.rpm http://synopsis.fresco.org/download/srpms/qmtest.spec Thanks, Stefan
Well, first of all: * Some files (under qm/external/DocumentTemplate/) are licensed under ZPLv1.0, which is GPL incompatible. This must need fixing. * By the way some document files refer to the URL http://www.software-carpentry.com/openpub-license.html for the license text but the link is broken. Do the licenses of these files match with doc/cli_reference.xml ?
Thanks for the quick feedback, and thanks for pointing out the license issue. As you may have noticed, QMTest contains some Zope modules. While I did upgrade some of them a little while ago, I left out a few. It seems I should upgrade all of them, thus getting them all to be licensed under ZPL 2.1, which is GPL compatible. The links to the Software Carpentry are broken because that site isn't alive any more. I will ask the relevant people to see what to do. We will probably pull out those now defunct URLs of those texts. Thanks, Stefan
If there is any news please let me know it.
I have fixed the two issues you made me aware of, i.e. I have upgraded the ZOPE license to 2.1, and I have replaced the now obsolete URL to www.software-carpentry.com. I have uploaded a new source rpm and a new spec file: http://synopsis.fresco.org/download/srpm/qmtest-2.4-2.fc9.src.rpm http://synopsis.fresco.org/download/srpm/qmtest.spec If you confirm that this passes the Fedora acceptance test I'll spin a new minor QMTest release (2.4.1) and then submit qmtest-2.4.1-1 for inclusion into Fedora. Thanks, Stefan
Now legal issue is resolved. Assigning to myself.
For 2.4-2 * License ** There seems no files to specify GPL version ** Some codes/documents are under Open Publican - So the license tag should be "GPL+ and Open Publican" - Also some file contains the contents "(see the file LICENSE.OPL)", however I can find "LICENSE.OPL" file nowhere. Please add this. * ldconfig - Calling ldconfig on scriptlets is not needed for this package. * python module dependency - Please check if all python module dependency related rpms are correctly added to "Requires" * Documents - Please also install "ChangeLog" "NEWS" as documents
Here are updated package / spec file: http://synopsis.fresco.org/download/srpm/qmtest-2.4-3.fc9.src.rpm http://synopsis.fresco.org/download/srpm/qmtest.spec I added the missing files (LICENSE.OPL, ChangeLog, NEWS), removed the redundant ldconfig call, and adjusted the license tag to "GPLv2 and Open Publication" QMTest doesn't require any external Python modules, so there is nothing to add to "Requires". Thanks !
(In reply to comment #9) > and adjusted the license tag to "GPLv2 and Open Publication" Well, would you tell me from what file you judged that this package is GPL version 2 specific, not GPL at any version (i.e. not GPL+ but GPLv2)?
ping?
ping again?
I uploaded a new spec file and a new source rpm: http://synopsis.fresco.org/download/srpm/qmtest-2.4-4.fc9.src.rpm http://synopsis.fresco.org/download/srpm/qmtest.spec The spec file now indicates "GPLv2+ and Open Publication", and the code contains some fixes to be compatible with Python 2.6.
Well, again would you tell me where it is indicated that this package is licensed under GPLv2+, not GPL+ (GPL at any version)? Note that just putting GPLv2 license text in the tarball does not mean that the software is licensed under GPLv2 (because of section 9 of GPLv2 license text). If there is GPLv2 license text, but no other files specifies the version of GPL, then it is regarded that it is licensed under GPL+.
I think you are wrong here. The file 'COPYING' that is referenced throughout the code clearly states that this is version 2. Please note that the license text itself starts somewhat below, with GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION So, the condition of section 9 is met by the very beginning of the COPYING file.
(In reply to comment #15) > I think you are wrong here. The file 'COPYING' that is referenced throughout > the code clearly states that this is version 2. > > Please note that the license text itself starts somewhat below, with > > GNU GENERAL PUBLIC LICENSE > TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > > So, the condition of section 9 is met by the very beginning of the COPYING > file. So actually no. See this: http://fedoraproject.org/wiki/Licensing/FAQ Putting GPLv2 text only does not mean that the software is licensed under GPLv2.
The sources explicitly say "for license terms please see the file COPYING". And even if you disregard that (to me clear) statement, the FAQ you cite mentions this (point 4.): "Technically it could be under any license, but if all we have to go by is COPYING, we'll guess COPYING is accurate." Finally, as I'm the maintainer, and my employer the copyright holder, it is not a matter of discussion what license QMTest is released under, but rather, where to put the licensing terms to make our users aware of them. FWIW, the qmtest.com website (http://www.codesourcery.com/qmtest) clearly states that QMTest is available under GPL version 2. Is that what you are asking for ?
(In reply to comment #17) > The sources explicitly say "for license terms please see the file COPYING". > And even if you disregard that (to me clear) statement, the FAQ you cite > mentions this (point 4.): > > "Technically it could be under any license, but if all we have to go by is > COPYING, we'll guess COPYING is accurate." In this case we don't do any _guess_ (if possible) but check the license in the technical point of view. > Finally, as I'm the maintainer, and my employer the copyright holder, it is not > a matter of discussion what license QMTest is released under, but rather, where > to put the licensing terms to make our users aware of them. > > FWIW, the qmtest.com website (http://www.codesourcery.com/qmtest) clearly > states that QMTest is available under GPL version 2. Is that what you are > asking for ? I no longer trust website license information because I have seen many cases in which the website license information is wrong due to various reasons. By the way, if you are upstream all I want is that you put the explicit declaration in the COPYING or README that this software is licensed under GPL version 2.
(In reply to comment #18) > By the way, if you are upstream all I want is that you put the explicit > declaration in the COPYING or README that this software is licensed under > GPL version 2. I'm sorry if I don't follow what you are saying. The COPYING file already starts with GNU GENERAL PUBLIC LICENSE Version 2, June 1991 So how could I be more explicit than that ? (And, in the same spirit: What do you exactly mean by "check the license in the technical point of view" ? The cited paragraph clearly says that in case nothing else is available the information (which includes the license version header right on top of COPYING) will be used.) So, right now there are two references: the website, as well as the top of the COPYING file; both agree on the license being GPLv2. What else does it take to convince you ?
Stefan, would you mind reading the rest of the COPYING file? Down where in term 9 it says: If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. This is where the whole issue comes from. You cannot just say "Look at the COPYING file". Well, you can, but that file is rather explicit in saying that then someone who wishes to distribute the software can choose GPLv1 if they want. The FSF is really clear that every source file needs to contain a specific block of text indicating, among other things, the license version in use. Now, there's a whole procedure to go through in determining the intent of the author if they have chosen for some reason to leave off those blocks of text. Upstream web sites can be used assuming that we can establish that they are authoried by the same entity which authored the software. But that's really a case-by-case thing that the legal folks need to look at. Isn't it just simpler to include an actual statement of the license version?
OK, here you go: README file is changed, to explicitly state 'version 2', and qmtest.spec file is changed (back) to 'GPLv2', so both now agree with the website (qmtest.com). http://synopsis.fresco.org/download/srpm/qmtest-2.4-5.fc9.src.rpm http://synopsis.fresco.org/download/srpm/qmtest.spec
Okay, please fix %changelog entry and upload 2.4.1 tarball when ready. ---------------------------------------------------- This package (qmtest) is APPROVED by mtasaka ---------------------------------------------------- Please follow the procedure written on: http://fedoraproject.org/wiki/PackageMaintainers/Join from "Get a Fedora Account". After you request for sponsorship a mail will be sent to sponsor members automatically (which is invisible for you) which notifies that you need a sponsor. After that, please also write on this bug for confirmation that you requested for sponsorship and your FAS (Fedora Account System) name. Then I will sponsor you. If you want to import this package into Fedora 9/10, you also have to look at http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT (after once you rebuilt this package on koji Fedora rebuilding system). If you have questions, please ask me.
I just released QMTest 2.4.1. The source package is available from http://www.codesourcery.com/public/qmtest/qmtest-2.4.1/qmtest-2.4.1.tar.gz It includes the qmtest.spec file. I have created a Fedora account (username=stefan), and added FE_NEEDSPONSOR to the block field of this bug. Please let me know if you need anything else. Thanks, Stefan
$ LANG=C rpmbuild -ts qmtest-2.4.1.tar.gz error: Failed to read spec file from qmtest-2.4.1.tar.gz ?? (anyway would you provide your srpm? It is much helpful) By the way I am sponsoring you now.
I have uploaded an srpm and a spec file to http://stefan.fedorapeople.org/. By the way, is there any reason why the source package name includes the build platform ('fc9') ? This isn't actually a platform-specific file, or is it ? If not, shall I rename such files in the future before uploading (or importing into CVS) ? Thanks, Stefan
Well, - I just noticed that many HTML files have "Generated by Epydoc 3.0.1" comments. Does this mean that document HTML files in qmtest can be regenerated by using epydoc (this is available in Fedora)? - By the way would you preserve the old %changelog entry? ("initial package" for 2.4.1 don't seem proper) (In reply to comment #25) > By the way, is there any reason why the source package name includes the build > platform ('fc9') ? - Because rpmbuild -bs just expands %{?dist} value. > This isn't actually a platform-specific file, or is it ? - In short, you need not take care of this. If your srpm is rebuild on a platform where dist is defined as ".fc11", the rebuilt binary rpms will have ".fc11" in their names. i.e. %{?dist} value is re-valuated when rebuilding binary rpms and the binary rpms are "renamed" properly. Also Fedora CVS system can treat this correctly.
(In reply to comment #26) > Well, > - I just noticed that many HTML files have "Generated by Epydoc 3.0.1" > comments. Does this mean that document HTML files in qmtest can be > regenerated > by using epydoc (this is available in Fedora)? Yes. Our released source tarballs already ship with them, though, so there is no need to regenerate anything. (And, we have used different tools to generate those docs in the past (such as HappyDoc or Synopsis), so I wouldn't want to hardcode the use of epydoc into the spec file or the build system, for example. > - By the way would you preserve the old %changelog entry? > ("initial package" for 2.4.1 don't seem proper) Well, 2.4.1 is the first QMTest release for which I build rpm packages. > (In reply to comment #25) > > By the way, is there any reason why the source package name includes the build > > platform ('fc9') ? > - Because rpmbuild -bs just expands %{?dist} value. OK, I understand where the name is coming from. I don't understand whether changing the name of the source rpm (removing the {?dist} tag) would be wrong. But that was just out of interest. There is no need to rename anything. Thanks, Stefan
Okay, then this package can be approved. Now please follow "Join" wiki: http://fedoraproject.org/wiki/PackageMaintainers/Join (By the way would you also update Synopsis?)
New Package CVS Request ======================= Package Name: qmtest Short Description: an automated software test execution tool. Owners: stefan Branches: F-9 F-10 InitialCC:
cvs done.
I have imported qmtest into cvs, and built it: http://koji.fedoraproject.org/koji/packageinfo?packageID=7353 Is there anything else for me to do at this point ? Will the package eventually show up via yum ? (The same questions apply to the Synopsis package.) Thanks,
For F-10/9: - Please visit bodhi web interface: https://admin.fedoraproject.org/updates/ and submit requests to push the rebuilt packages to repositories. For 11: - The rebuilt packages will be (or maybe already have been) pushed into repository.
By the way a Happy New Year!
OK, I requested updates for QMTest and Synopsis for both F9 and F10. I guess this issue (as well as #438543) can now be closed. Thanks for all your help ! And a Happy New Year to you, too ! :-)
Thanks. When you think the requested packages can be moved from testing to stable, please revisit the bodhi interface and edit your requests. Closing as NEXTRELEASE.