[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ITP:Bug#460591 - Falcon P.L. license



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


Reply to: