Bug 430307 - Review Request: Falcon - The Falcon Programming Language
Review Request: Falcon - The Falcon Programming Language
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Hans de Goede
Fedora Extras Quality Assurance
http://www.falconpl.org/
:
: 428603 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-25 18:03 EST by Michel Alexandre Salim
Modified: 2008-05-21 07:07 EDT (History)
4 users (show)

See Also:
Fixed In Version: 0.8.8-2.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 07:07:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
hdegoede: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Michel Alexandre Salim 2008-01-25 18:03:31 EST
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.
Comment 1 Michel Alexandre Salim 2008-01-25 18:04:04 EST
*** Bug 428603 has been marked as a duplicate of this bug. ***
Comment 2 Jason Tibbitts 2008-01-26 22:15:51 EST
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.
Comment 3 Hans de Goede 2008-01-27 04:48:28 EST
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?
Comment 4 Hans de Goede 2008-01-27 05:39:48 EST
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
Comment 5 Mamoru TASAKA 2008-01-27 06:28:48 EST
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
Comment 6 Giancarlo Niccolai 2008-01-27 06:35:46 EST
* 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.
Comment 7 Michel Alexandre Salim 2008-01-27 09:58:34 EST
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

 
Comment 8 Hans de Goede 2008-01-28 04:11:45 EST
(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).
Comment 9 Tom "spot" Callaway 2008-02-18 16:00:37 EST
Sent off to the FSF for approval. 5d in the license concerns me, but we'll see
what the FSF says.
Comment 10 Giancarlo Niccolai 2008-02-18 18:14:35 EST
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).
Comment 11 Michel Alexandre Salim 2008-04-09 16:23:39 EDT
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
Comment 12 Giancarlo Niccolai 2008-04-10 14:53:04 EDT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

bugzilla@redhat.com 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@gmail.com  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-----

Comment 13 Hans de Goede 2008-04-10 15:46:02 EDT
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..
Comment 14 Giancarlo Niccolai 2008-04-10 16:37:50 EDT
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.
Comment 15 Giancarlo Niccolai 2008-04-10 16:40:42 EDT
Oh, and also added the dual license plaque as indicated above to the LICENSE
file, and updated to FPLL 1.1.
Comment 16 Hans de Goede 2008-04-10 16:59:17 EDT
Michel, do you want me to check Giancarlo's srpm, or should I wait for an
updated one from you?
Comment 17 Giancarlo Niccolai 2008-04-13 16:41:37 EDT
Hello; not to press anyone, but I see the situation is blocked. Is there any
other problem?
Comment 18 Hans de Goede 2008-04-13 16:46:27 EDT
(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.
Comment 19 Michel Alexandre Salim 2008-04-20 20:22:58 EDT
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!
Comment 20 Giancarlo Niccolai 2008-04-21 03:38:32 EDT
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.
Comment 21 Ralf Corsepius 2008-04-21 04:09:02 EDT
(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.

Comment 22 Giancarlo Niccolai 2008-04-21 04:22:14 EDT
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.
Comment 23 Hans de Goede 2008-04-21 04:24:09 EDT
(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.
Comment 24 Hans de Goede 2008-04-21 04:26:08 EDT
(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.
Comment 25 Ralf Corsepius 2008-04-21 04:52:41 EDT
(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.



Comment 26 Giancarlo Niccolai 2008-04-21 05:28:49 EDT
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.
Comment 27 Michel Alexandre Salim 2008-04-23 21:05:23 EDT
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.
Comment 28 Michel Alexandre Salim 2008-04-23 21:07:19 EDT
Ignore previous comment; didn't notice that you were replying to Ralf.
Comment 31 Michel Alexandre Salim 2008-04-25 22:33:12 EDT
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
Comment 32 Mamoru TASAKA 2008-04-25 22:39:29 EDT
Perhaps you also want to request F-9 branch?
Comment 33 Kevin Fenzi 2008-04-26 12:41:33 EDT
cvs done. 

(I also did a F-9 branch as it makes little sense not to at this point). 
Comment 34 Michel Alexandre Salim 2008-04-28 16:59:28 EDT
Thanks. That's probably a good thing -- now that Rawhide == future F-10, it's a
bit hard to build against
Comment 35 Fedora Update System 2008-05-16 15:26:32 EDT
Falcon-0.8.8-2.fc9 has been submitted as an update for Fedora 9
Comment 36 Fedora Update System 2008-05-19 16:47:53 EDT
Falcon-0.8.8-2.fc8 has been submitted as an update for Fedora 8
Comment 37 Fedora Update System 2008-05-21 07:07:09 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.