Spec URL: http://salimma.fedorapeople.org/for_review/Falcon/Falcon.spec SRPM URL: http://salimma.fedorapeople.org/for_review/Falcon/Falcon-0.8.8-1.src.rpm Description: The Falcon Programming Language is an embeddable scripting language aiming to empower even simple applications with a powerful, flexible, extensible and highly configurable scripting engine. Falcon is also a standalone multiplatform scripting language that aims to be both simple and powerful. Note: this is based on upstream's package review request (https://bugzilla.redhat.com/show_bug.cgi?id=428603) which I was reviewing. Upstream did not have the time to go through the application process to be a Fedora maintainer, so I'm creating a new review request here.
*** Bug 428603 has been marked as a duplicate of this bug. ***
Before going much further, let's have someone look over the license. Having License: ASL 2.0 doesn't seem correct to me because, well, it's not ASL 2.0; it should either be "ASL 2.0 with exceptions" or some other tag assigned by the license folks. Blocking FE-Legal for an official opinion.
Doing a full review of this and bug 429086, please review bug 366841 and 427077 in return. Has someone already send this license to Spot for approval?
Full review done: Must Fix -------- * tarbal in srpm doesn't match upstream (content is the same, but the tarballs differ) : [hans@localhost ~]$ diff Falcon-0.8.8.tar.gz /usr/src/redhat/SOURCES/Falcon-0.8.8.tar.gz Binary files Falcon-0.8.8.tar.gz and /usr/src/redhat/SOURCES/Falcon-0.8.8.tar.gz differ [hans@localhost ~]$ * Get license approved by Spot (and get a shortname for it from him) Should Fix ---------- * Please drop the not seen in any other specfile ###################################################################### ## Install. ###################################################################### Lines
The correct URL is perhaps the following? http://salimma.fedorapeople.org/for_review/Falcon/Falcon-0.8.8-1.fc8.src.rpm Then: %_includedir/falcon/setup.h (in Falcon-devel-0.8.8-1.fc9) contains: ----------------------------------------------------------------------------------- 34 35 #ifndef FLC_SETUP_H 36 #define FLC_SETUP_H 37 38 #include <falcon/config.h> 39 ------------------------------------------------------------------------------------ But I cannot find <falcon/config.h>. Also, %_includedir/falcon/xtree_fix.h contains: ------------------------------------------------------------------------------------- 1 // tree internal header 2 3 #if _MSC_VER > 1000 4 #pragma once 5 #endif 6 7 #ifndef _XTREE_ 8 #define _XTREE_ 9 10 #pragma message ("Using modified VC6 XTREE for Falcon...") 11 12 #include <cstddef> 13 #include <iterator> 14 #include <memory> 15 #include <xutility> 16 ------------------------------------------------------------------------------- But what is <xutility>? BTW I usually do some check like: $ grep -h 'include ' `rpm -ql Falcon-devel | grep /usr/include` | sort | uniq
* config.h is generated from config.h.in in the build process. * xtree_fix.h was an old fix for first version of std::map provided by the first version of VC6. I posted that fix to M$, and they integrated it in the first service pack. Of course, without crediting me. It stays in the sources for historical reasons, but it is not currently included anywhere. BTW, xutility was another VC6 specific header; as that one was correct, I used it.
License has been sent to fedora-legal; Spot responded to it saying he's checking with lawyers. @Mamoru: ah yes, thanks, that's the correct URL @Hans: Thanks. I removed most of the # header lines, but missed that one out. Re-downloaded tarball from upstream link, now everything should be correct: http://salimma.fedorapeople.org/for_review/Falcon/Falcon-0.8.8-1.fc9.src.rpm
(In reply to comment #7) > @Hans: Thanks. I removed most of the # header lines, but missed that one out. > Re-downloaded tarball from upstream link, now everything should be correct: > > http://salimma.fedorapeople.org/for_review/Falcon/Falcon-0.8.8-1.fc9.src.rpm > Looks good now, approved under the condition of Legal approval (not setting fedora-review to +, before that).
Sent off to the FSF for approval. 5d in the license concerns me, but we'll see what the FSF says.
About 5d it just states that it must be said somewhere in the docs, on the site, in the program screens, in the readme files, in the troubleshooting guide or wherever you like that the scripts were falcon. I think it's a very small constraint, if relevant at all, and it's meant to protect the final user from concealing this information (that may be relevant to him) and the Falcon project from unauthorized commercial (i.e. closed source) exploitation. If you are using a C compiler you're compiling to object code, but if you're using a script you're using a virtual machine, and it may be a good idea for your users not to be spoiled from the right of knowing what they are running on their machines. I didn't want to deprive Falcon script writers of the ability to distribute commercial closed source applications, but in that case, I didn't want the fact of using Falcon to be obfuscated so that the end user didn't possibly know. I think this goes along OSI guidelines (certification process started), but it's a bit forceful on radical free software concept of FSF. In case they ask, I can give the grant to Fedora users to pick up FSF GPL3 or any later or Falcon FPLL license, wichever they prefer. Falcon's is just less restrictive, so it's their call. (actually, if they ask I can provide double licensing directly for Falcon itself. I don't mind if the users select a more restrictive license on their own will).
Giancarlo, now that the licensing situation has been resolved, could you release a tarball that has the new licensing stated explicitly? Or if there's no imminent release planned, perhaps a GPG-signed document detailing the new dual-licensing situation. I'll then get the package properly submitted. Thanks, -- Michel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 bugzilla wrote: > > Please do not reply directly to this email. All additional > > comments should be made in the comments box of this bug report. > > > > Summary: Review Request: Falcon - The Falcon Programming Language > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=430307 > > > > > > > > > > > > ------- Additional Comments From michel.sylvan 2008-04-09 16:23 EST ------- > > Giancarlo, now that the licensing situation has been resolved, could you release > > a tarball that has the new licensing stated explicitly? Or if there's no > > imminent release planned, perhaps a GPG-signed document detailing the new > > dual-licensing situation. I'll then get the package properly submitted. > > > > Thanks, > > Thank you. I didn't insist because I didn't want to bother you/Fedora in the eve of version 9. The dual license situation is as follow: as the Committee President (and lead developer), I certify that we the Comittee agreed on the fact that GPLv2 license are compatible with the aims of our project. Just, we want to grant some further degree of freedom for commercial applications, that may prefer to apply FPLL rather than GPLv2. So, we acknowledge this fact and we grant anyone the right to distribute The Falcon Programming Language or any other software issued by our project under the terms of GPLv2. I.e. you may substitute the LICENSE file with the following notice: =============== Copyright 2004-2008, Giancarlo Niccolai et. al (See the AUTHORS file) This program is free software; you can redistribute it and/or modify it under the terms of either: a) the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version, or b) the Falcon Programming Language License version 1.1 (available at http://www.falconpl.org/?page_id=license_1_1 <or include the license verbatim in a file>). ================ And you can add GPL verbatim or a link to it. GPG: http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0xE67C2CA012030B86 - -or- http://www.niccolai.cc/public.gpg - ----- The situation is as follows: version 1.1 of the license (fedora-legal has 1.0) seems to be fine with debian-legal, and my legals have analized it and approved it, but we're dual licensing our project with GPL to remove any possible doubt about our project not being free software. We'll file FPLL for OSI certification and eventually (but not necessarily) stop dual licensing once certified that FPLL grants the same freedom as GPL, and more, by OSI. We ourselves didn't re-release Falcon 0.8.8 under dual licensing just because of lack of time, and because our 0.8.10 version is being readied in this days. We gladfully grant anyone the right to do so if he wish. Bests, Giancarlo Niccolai. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH/mF55nwsoBIDC4YRAmLhAKCQ555llBq86orlMtMPKASIZO/X3gCfS73V O5LTJQeiLQyRhFvls1/Kaug= =lsIE -----END PGP SIGNATURE-----
Giancarlo Niccolai & Co: Many thanks! Michel, can you do a new srpm with that mail included in %doc and the License: tag set to GPLv2+, then I'm ready to approve this package..
Done. http://www.falconpl.org/downloads/0.8.8/Falcon-0.8.8-1.fc9.src.rpm Please, feel free to fix glitches without further notice. I just took your package , added a file now listed in %doc and changed the license tag as GPLv2+, but plz double check. Bests, Giancarlo Niccolai.
Oh, and also added the dual license plaque as indicated above to the LICENSE file, and updated to FPLL 1.1.
Michel, do you want me to check Giancarlo's srpm, or should I wait for an updated one from you?
Hello; not to press anyone, but I see the situation is blocked. Is there any other problem?
(In reply to comment #17) > Hello; not to press anyone, but I see the situation is blocked. Is there any > other problem? > Nope, I'm / we are waiting for Michel, the submitter and future maintainer of the Falcon package for Fedora. ping Michel.
Just checked the SRPM and as Giancarlo said, the only changes are the inclusion of the license grant. The only problem is, the tarball on the website has not been updated: File in SRPM: 22cc42da337853c91ca30d91905e9ccb ../Falcon-0.8.8.tar.gz File in server: 119819f68e725fb53ef80d9d61e19a5d Falcon-0.8.8.tar.gz Giancarlo, could you either post the grant somewhere on the site, or update the tarball? Otherwise I can use the old tarball, and add the grant file as a separate source, with a link to this page for reference. Thanks!
Hello; The tarball in the srpm is now on the site as http://www.falconpl.org/downloads/0.8.8/Falcon-0.8.8-fc9.tar.gz I cannot update the original package because it would break currently released debian-based distros (packagers would have tons of bells ringing as they monitor sites download pages to check for updates with automated tools). You may either use this TGZ and repackage the srpm, or you may just link it as you wish. Bests, Giancarlo Niccolai.
(In reply to comment #20) > Hello; > The tarball in the srpm is now on the site as > http://www.falconpl.org/downloads/0.8.8/Falcon-0.8.8-fc9.tar.gz The normal way would be to use an original upstream tarball and Fedora to apply patches. > I cannot update the original package because it would break currently released > debian-based distros (packagers would have tons of bells ringing as they monitor > sites download pages to check for updates with automated tools). Off cause upstream can do this! It's what 10000s of projects do. Upstream work must be independent of distro specific work (packaging an rpm). If it's not, then something is very broken.
Well, IMHO it's not so normal to change a package without changing its version number after it has been released. Falcon 0.8.8 has not yet been released by Fedora, but it has been released by others, and changing that package wouldn't be fair, I suppose. Of course upstreams can do it and do it, but IMHO a kinder way to update things is that of changing the version number of the package. Anyhow, long story short: you have a Falcon 0.8.8 version released under GPL. There is a source package released with that policy on the site (the link I posted) and you may either pick it or use the other .tgz and patch it. Am I required to do anything else? TIA.
(In reply to comment #21) > (In reply to comment #20) > > Hello; > > The tarball in the srpm is now on the site as > > http://www.falconpl.org/downloads/0.8.8/Falcon-0.8.8-fc9.tar.gz > > The normal way would be to use an original upstream tarball and Fedora to apply > patches. > This is not about patches, but about adding a new license to the tarbal. Ralf, it would _really_ help if you first read the entire ticket before shooting of some random comments. > > I cannot update the original package because it would break currently released > > debian-based distros (packagers would have tons of bells ringing as they monitor > > sites download pages to check for updates with automated tools). > Off cause upstream can do this! It's what 10000s of projects do. > Upstream work must be independent of distro specific work (packaging an rpm). > > If it's not, then something is very broken. > Upstream should never respin a tarbal without a version change or some other change in the name of the tarbal, replacing an already distributed tarbal causes lots of troubles for lots of distros. Something which you know, again please read the ticket first. Also the comment you were responding from is from _upstream_! An upstream who has been very kind to Fedora, so kind as to dual license, and respin a tarbal now (with a different name as to not cause all kinda checksum alarms to go off which would have happened if the original tarbal changed). So I would like to say: Thanks Giancarlo Niccolai, the respinned (differently named) tarbal will work nicely for us.
(In reply to comment #22) > Anyhow, long story short: you have a Falcon 0.8.8 version released under GPL. > There is a source package released with that policy on the site (the link I > posted) and you may either pick it or use the other .tgz and patch it. Am I > required to do anything else? > No this is sufficient (and many thanks for doing this). Now I just need Michel to post a link to a new srpm based on this tarbal and then I can approve this.
(In reply to comment #23) > (In reply to comment #21) > > (In reply to comment #20) > > > Hello; > > > The tarball in the srpm is now on the site as > > > http://www.falconpl.org/downloads/0.8.8/Falcon-0.8.8-fc9.tar.gz > > > > The normal way would be to use an original upstream tarball and Fedora to apply > > patches. > > > > This is not about patches, but about adding a new license to the tarbal. Which is silly - Upstream should get used to using reasonable release policies Ralf, > it would _really_ help if you first read the entire ticket before shooting of > some random comments. I did - Openly said, your accusation embarrasses me very much. > > > I cannot update the original package because it would break currently released > > > debian-based distros (packagers would have tons of bells ringing as they monitor > > > sites download pages to check for updates with automated tools). > > Off cause upstream can do this! It's what 10000s of projects do. > > Upstream work must be independent of distro specific work (packaging an rpm). > > > > If it's not, then something is very broken. > > > > Upstream should never respin a tarbal without a version change or some other > change in the name of the tarbal. Correct. > replacing an already distributed tarbal causes > lots of troubles for lots of distros. Something which you know, again please > read the ticket first. They should release a new release - Even if a licence change is the only change. Such kind of incidents happen all the time. > Also the comment you were responding from is from _upstream_! An upstream who > has been very kind to Fedora, so kind as to dual license, and respin a tarbal > now (with a different name as to not cause all kinda checksum alarms to go off > which would have happened if the original tarbal changed). > > So I would like to say: Thanks Giancarlo Niccolai, the respinned (differently > named) tarbal will work nicely for us. I disagree. We should not ship temporary hacked forks. If a package doesn't comply to our licensing requirements, it's out. Upstream has the freedom to release a new release with the issues fixed. Their decision.
This is by no mean a temporary hacked fork. This is the old code with the new license applied. It makes an official release too, as the new licensing scheme is official, and that tar.gz will be downloadable from the site shortly. Moreover, what is commonly happening in Fedora/RH is that they have just special grants from non-gpl upstreams. Authorized patches on licenses (and non-authorized/self made patches on code) are the norm, not the exception; I cannot see what's your problem when you even receive an official new package, released by the upstream. Sorry for the frankness, but it really seems you're making fuzz for nothing.
This is not a fuzz over nothing, unfortunately: the source URL does not match the source tarball in the SRPM. The license grant itself is fine; what I'm saying is, either add the additional file as a separate source, or incorporate the new file in a new tarball *and* make the tarball available. The third way, incorporating the file but not publishing it, is not good. I'll do an updated SRPM a bit later.
Ignore previous comment; didn't notice that you were replying to Ralf.
Updated package: http://salimma.fedorapeople.org/for_review/Falcon/Falcon-0.8.8-2.fc9.src.rpm http://salimma.fedorapeople.org/for_review/Falcon/Falcon.spec Koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=580112
(In reply to comment #29) > Updated package: > http://salimma.fedorapeople.org/for_review/Falcon/Falcon-0.8.8-2.fc9.src.rpm > http://salimma.fedorapeople.org/for_review/Falcon/Falcon.spec > > Koji scratch build: > http://koji.fedoraproject.org/koji/taskinfo?taskID=580112 Perfect, approved!
Thanks everyone! New Package CVS Request ======================= Package Name: Falcon Short Description: The Falcon Programming Language Owners: salimma Branches: F-7 F-8 EL-5 InitialCC: Cvsextras Commits: yes
Perhaps you also want to request F-9 branch?
cvs done. (I also did a F-9 branch as it makes little sense not to at this point).
Thanks. That's probably a good thing -- now that Rawhide == future F-10, it's a bit hard to build against
Falcon-0.8.8-2.fc9 has been submitted as an update for Fedora 9
Falcon-0.8.8-2.fc8 has been submitted as an update for Fedora 8
Falcon-0.8.8-2.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.