Re: ITP:Bug#460591 - Falcon P.L. license
-----BEGIN PGP SIGNED MESSAGE-----
Francesco Poli wrote:
> On Thu, 20 Mar 2008 10:35:16 +0100 (CET) Giancarlo Niccolai wrote:
> | "Embedding Works" shall mean any work, whether in Source | or
> Object form, that links (or binds by name) to the | interface of
> the Work and Derivative Works.
> I think it's pretty clear that what you call "Embedding Works" are
> not "Derivative Works" for the purposes of the Apache License v2.0
Unluckily, Apache is C, and Falcon is C++. Much code is inlined, so it
is not possible to use the mere "link by name" criterion as a clear
cut between derivative works (that would fall under FPLL) and
embedding works and modules (that won't fall under that, but are
required to tell they're using Falcon).
I agree that we coders know what an inline is, and we can draw a clear
equivalence between using inline code and name-linking; just, I was
afraid that there could have some illicit extension of the concept of
"derivative work" beyond the limit we, the coders, would consider
Or put down more simply; the "name linking" criterion proved a bit
controversial on the ground. FSF had long talks about that, it can be
easily browsed on the net. And anyhow, it may be ok for things as an
external service, but when it comes to a scripting engine, which do
certain things inside your own application, I thought that a more
precise and functional-oriented distinction was needed.
> What may be less clear is whether I'm allowed to create and
> distribute a work that merely links to the Apache web server
> v2.x.y. The Apache License v2.0 does *not* explicitly grant this
>> This license (FPLL) was made EXACTLY to state that it does not
>> apply to embedders and scripters, except for one thing: they have
>> *NOT to hide* the fact that they are using Falcon.
> If there's no need for an explicit permission, then your
> conditioned permission is superfluous (and everybody can perform
> those actions, even while *hiding* the use of Falcon).
Sorry, I can't follow your points anymore.
I said that I am ready to change any part of the license, if
1) it restricts freedom of users/coders (more than other widely
accepted open source license) rather than defending them; and
2) its wording/structure are inadequate to pursue the declared aims
(which are listed in the commentary).
Otherwise, I require this license to be accepted by Debian as I am
proposing a package under that license. If this is plainly not
possible regardless of points 1 and 2, in example, because Debian
doesn't accept new licenses unless approved i.e. by OSI and/or FSF,
then I am asking for an alternative measure. In example, I can
release Falcon as a Debian package under GPL, and let users pick FPLL
if they wish.
Please, let's concentrate on this topics.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----