-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 adequate. 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 > permission. ... >> 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. Bests, Giancarlo Niccolai. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH5YJp5nwsoBIDC4YRAo6mAJ96NRiwENLlSI4EvK8MTWd+NAhT1wCfbR6p 7rwktDkbwpTagQWTd3xnZiY= =73w+ -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
