On Sat, 11 Feb 2006 10:20:21 -0500 Charles Fry wrote: > > > Once again, I repeat my claim: that the 3.01 version of the PHP > > > License is equally fit for licensing PHP itself and PHP Group > > > software. This claim has been upheld over months of sporadic > > > discussion on the matter at debian-legal. > > > > So lets look at that license, not only for "allow php group to use > > it in Debian", but also for others who made the mistake to use this > > license. > > First things first. After months of sporadic debian-legal discussion, > it has not been suggested that this license is fit for other software.
Actually it's really inappropriate (besides being non-free).
It would be useful if it were suitable for any piece of software,
though.
> But it has been suggested by multiple people that it is as fit for PHP
> Group software as for PHP itself.
Once again, IMO it's equally non-free for other PHP Group software and
for PHP itself.
> Given that there is a large PHP
> community adopting the PHP License by default (the equivilant of CPAN
> for PHP), this is a significant decision which must be made.
Certainly.
>
> I have worked as much as possible with the PEAR Group in an effort to
> address this. They recognized the problems with the previous license
> (3.0), and were ready to abandon it if unable to get the PHP Group to
> modify the license. Pierre Joye of the PEAR Group took the license
> issues to the PHP Group, who accepted to make minimal possible changes
> to the license to make it equally applicible to PHP Group software as
> to PHP itself, because of the community issues outlined above.
This is appreciated, indeed.
> Pierre
> says that they have made the maximal changes that they are willing to
> make, and that he can not ask for any more from them.
This is unfortunate, since IMO what has been done so far is not enough
to make PHP and other PHP Group software comply with the DFSG...
>
> This leaves us in the position of needing to evaluate the modified PHP
> License (3.01) with respect to all PHP Group software. While someone
> with a close personal relationship with the PHP Group might be able to
> convince them to make further modifications to their license, such a
> person has not yet materialized,
I hope we can find one...
> and so we are left deciding whether
> or not the license is fit as is for the large array of software
> distributed by the PHP Group.
>
> > Point 4 of it, as already pointed out by Don, is broken. Yes, there
> > is other software with a similar problem, but that doesnt mean it
> > shouldnt get fixed too. Drop the "nor may PHP appear anywhere in its
> > name" part to make it better, thats the real bad thing in it.
>
> As previously mentioned by others, your stance on this can't be
> inconsistant. Either you reject all licenses that contain such clauses
> as non-free, or you recognize that this isn't significant enough to be
> a show-stopper for inclusion in Debian.
Of course.
> The latter has been followed
> for all other licenses, and unless that changes I think there is
> substantial precedent to do the same in this case.
Previous mistakes should be fixed, not taken as precedents to justify
reiteration.
Which licenses are you talking about, anyway?
So far only the following ones have been mentioned as having the same
issue, IIRC:
* the PHP license (and we are talking about it)
* the Subversion license (it should be fixed likewise)
* the Apache Software License Version 1.1 (apache2 is under Apache
License Version 2.0[1] that does not have this issue; I think apache1 is
going to be dropped sooner or later[2], so this issue is fading away...)
Any other license with this issue?
[1] apart from one single file (copyrighted by the Apache Software
Foundation) that has probably been left unrelicensed by mistake, I must
find the time to investigate further...
[2] I don't know whether etch is planned to be released with or without
apache1, but I feel that it won't be kept eternally...
>
> > Point 5 the last sentence is bad.
[...]
> This is similar to clause 9 of the GPL, which makes it possible to
> apply future licenses in place of the current license. The difference
> here is that they always give you that option, where as in the GPL (as
> I understand it) that privilege must be explicitely granted.
[...]
It's a significant difference.
It means that anyone who license under the PHP License must trust the
PHP Group to never publish a new version that he/she dislikes.
I personally would rather avoid dual licensing my work under yet unknown
terms and conditions, but apparently many people are OK with this kind
of situation...
It's not a Freeness issue, though.
It could instead help us solving the problems with the PHP License: if
we succeed in persuading the PHP Group to publish a new fixed version of
the license, then every piece of software currently released under any
version of the PHP License will suddenly become DFSG-free.
That's why I'm repeating that the license should be fixed once and for
all by the PHP Group!
--
:-( This Universe is buggy! Where's the Creator's BTS? ;-)
......................................................................
Francesco Poli GnuPG Key ID = DD6DFCF4
Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
pgpacXh2eWRm7.pgp
Description: PGP signature
