On Thu, 20 Mar 2008 10:35:16 +0100 (CET) Giancarlo Niccolai wrote: > Francesco Poli wrote: [...] > > Frankly speaking, I cannot understand what you are trying to achieve. > > You are trying to create a license which is more restrictive than the > > Apache License v2.0, and you are calling those extra restrictions > > "guarantees to language users"... This is quite confusing, IMHO. I'm > > puzzled. > > > Extra restrictions? -- the definition of Embedded works and scripts are > there *exactly* to FREE THEM from the constraints of the license. Using > *SOLELY* Apache2 license, it would be unclear if an embedding work has to > be considered a derived work. How so? The Apache License v2.0 explicitly states: | For the purposes | of this License, Derivative Works shall not include works that remain | separable from, or merely link (or bind by name) to the interfaces of, | the Work and Derivative Works thereof. and the FPLL v1.0 defines | "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 ... 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. But is this permission *really* required by copyright laws? It seems that the Apache License v2.0 drafters assumed there is no need for this permission (I cannot believe they wanted to forbid such action, so I suppose they assumed there is no need to explicitly allow it!). I hope there is no need for an explicit permission to perform this action. Indeed, if such an action is effectively forbidden for the Apache web server v2.x.y, then I think we have a serious DFSG-freeness issue with some important packages in Debian main! > > 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). If, on the other hand, an explicit permission is really needed, then we have a serious problem with Apache License v2.0, and I think the right solution is contacting the Apache Software Foundation and persuading them to publish a fixed Apache License v2.x (with x > 0). [...] > Well, as other poster have mentioned, this point is debatable. As it is > debatable, I don't see what can be disturbing in saying "hey, you just > *CAN* do it, don't ever worry about it". As I was "clearing ground", I > couldn't see why I should have avoided clearing the ground also for this. The ground is not completely cleared, because it remains unclear whether one is allowed to hide the use of Falcon... The FPLL says it's not allowed, but, if the conditioned permission was superfluous in the first place, then, it's effectively allowed. Standardized disclaimers: IANAL, TINLA, IANADD, TINASOTODP. -- http://frx.netsons.org/progs/scripts/refresh-pubring.html New! Version 0.6 available! What? See for yourself! ..................................................... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
Attachment:
pgpFOkzWZz5rF.pgp
Description: PGP signature