Discussion:
[PHP-QA] Debian and the PHP license
(too old to reply)
Ferenc Kovacs
2014-07-29 14:47:34 UTC
Permalink
Hi all,
There seems to be some confusion over the PHP License.
We had this bug report into a PEAR project which outlines that Debian
cannot include any projects that fall under the PHP License.
* https://pear.php.net/bugs/bug.php?id=20172
* https://ftp-master.debian.org/REJECT-FAQ.html
You have a PHP add-on package (any php script/"app"/thing, not PHP
itself) and it's licensed only under the standard PHP license. That
license, up to the 3.x which is actually out, is not really usable
for anything else than PHP itself. I've mailed our -legal list about
that and got only one response, which basically supported my view on
this. Basically this license talks only about PHP, the PHP Group,
and includes Zend Engine, so its not applicable to anything else.
And even worse, older versions include the nice ad-clause.
One good solution here is to suggest a license change to your
upstream, as they clearly wanted a free one. LGPL or BSD seems to be
what they want
After a quick search, I quickly found that this isn't an isolated case...
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728196
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752530
* http://pear.php.net/bugs/bug.php?id=20316
org/msg362847.html
* https://github.com/nicolasff/phpredis/issues/384
Judging by the email to legal sent almost a decade ago this situation is
in need of a review...
* https://lists.debian.org/debian-legal/2005/08/msg00128.html
GPL enforces many restrictions on what can and cannot be done with
the licensed code. The PHP developers decided to release PHP under a
much more loose license (Apache-style), to help PHP become as
popular as possible.
- http://php.net/license/
I also read that Rasmus Lerdorf issued a statement which said that the PHP
license is pretty much identical to the Apache license.
* http://pear.php.net/manual/en/faq.devs.php
I've also discovered that this is not the first instance that this issue
* http://lwn.net/Articles/604630/
1. Is 'The PHP License, version 3.01' an Open Source license, certified by
the Open Source Initiative? Their website only lists 'PHP License 3.0
(PHP-3.0)'.
2. When was 'The PHP License, version 3.01' released?
3. Can 'The PHP License, version 3.01' be used for anything other than PHP
itself?
4. Are there any legal implications of changing a project from 'The PHP
License, version 3.01' to LGPL or BSD?
5. Is the PHP license clear enough to ensure that it is correctly applied
to extensions?
6. Why would the (Apache-style) PHP License be listed by Debian as a
'serious violation' yet the Apache license is not?
Thanks.
Hi,

please see the thread at
http://comments.gmane.org/gmane.comp.php.pecl.devel/11046 and if you want
to reply I think pecl-dev@ is a better place than php-qa@
Most of your links are old and some of the previous problems claimed by
debian was addressed with php license version 3.01.
from the replies on the debian mailing lists it seems that this decision on
dropping any project using the php license distributed outside of php-src
is controversial to say the least.
I've tried to start a discussion to find some kind of resolution, but most
of the replies from php-dev side was that the current license is fine, and
we don't need to change anything, while we didn't got any reply from the
debian-legal (apart from the mail from Francesco Poli who explicitly stated
that not part of the debian project and not speaking on behalf of it).

Based on the lack of clarification and cooperation from their side, I think
the consensus on our part will be to keep everything as-is, and at the end
of the day, it is up to the package maintainer to decide if they take the
advice from the debian package maintainers and change the license for their
project.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Paul Tagliamonte
2014-07-29 15:11:16 UTC
Permalink
debian-legal isn't the body that makes this decision, you might want
***@ftp-master.debian.org

Thanks,
Paul
Post by Ferenc Kovacs
Hi all,
There seems to be some confusion over the PHP License.
We had this bug report into a PEAR project which outlines that Debian
cannot include any projects that fall under the PHP License.
* https://pear.php.net/bugs/bug.php?id=20172
* https://ftp-master.debian.org/REJECT-FAQ.html
You have a PHP add-on package (any php script/"app"/thing, not PHP
itself) and it's licensed only under the standard PHP license. That
license, up to the 3.x which is actually out, is not really usable
for anything else than PHP itself. I've mailed our -legal list about
that and got only one response, which basically supported my view on
this. Basically this license talks only about PHP, the PHP Group,
and includes Zend Engine, so its not applicable to anything else.
And even worse, older versions include the nice ad-clause.
One good solution here is to suggest a license change to your
upstream, as they clearly wanted a free one. LGPL or BSD seems to be
what they want
After a quick search, I quickly found that this isn't an isolated case...
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728196
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752530
* http://pear.php.net/bugs/bug.php?id=20316
*
* https://github.com/nicolasff/phpredis/issues/384
Judging by the email to legal sent almost a decade ago this situation is
in need of a review...
* https://lists.debian.org/debian-legal/2005/08/msg00128.html
GPL enforces many restrictions on what can and cannot be done with
the licensed code. The PHP developers decided to release PHP under a
much more loose license (Apache-style), to help PHP become as
popular as possible.
- http://php.net/license/
I also read that Rasmus Lerdorf issued a statement which said that the PHP
license is pretty much identical to the Apache license.
* http://pear.php.net/manual/en/faq.devs.php
I've also discovered that this is not the first instance that this issue
* http://lwn.net/Articles/604630/
1. Is 'The PHP License, version 3.01' an Open Source license, certified by
the Open Source Initiative? Their website only lists 'PHP License 3.0
(PHP-3.0)'.
2. When was 'The PHP License, version 3.01' released?
3. Can 'The PHP License, version 3.01' be used for anything other than PHP
itself?
4. Are there any legal implications of changing a project from 'The PHP
License, version 3.01' to LGPL or BSD?
5. Is the PHP license clear enough to ensure that it is correctly applied
to extensions?
6. Why would the (Apache-style) PHP License be listed by Debian as a
'serious violation' yet the Apache license is not?
Thanks.
Hi,
please see the thread at
http://comments.gmane.org/gmane.comp.php.pecl.devel/11046 and if you want to
Most of your links are old and some of the previous problems claimed by
debian was addressed with php license version 3.01.
from the replies on the debian mailing lists it seems that this decision on
dropping any project using the php license distributed outside of php-src is
controversial to say the least.
I've tried to start a discussion to find some kind of resolution, but most
of the replies from php-dev side was that the current license is fine, and
we don't need to change anything, while we didn't got any reply from the
debian-legal (apart from the mail from Francesco Poli who explicitly stated
that not part of the debian project and not speaking on behalf of it).
Based on the lack of clarification and cooperation from their side, I think
the consensus on our part will be to keep everything as-is, and at the end
of the day, it is up to the package maintainer to decide if they take the
advice from the debian package maintainers and change the license for their
project.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
All programmers are playwrights, and all computers are lousy actors.

#define sizeof(x) rand()
:wq
Ferenc Kovacs
2014-07-29 15:20:21 UTC
Permalink
Post by Paul Tagliamonte
debian-legal isn't the body that makes this decision, you might want
Thanks,
Paul
Hi Paul,

To quote Ondřej from
http://www.mail-archive.com/debian-bugs-***@lists.debian.org/msg360686.html
"If you feel to dispute this please take your *well-formed* and
*well-thought* arguments to debian-legal."
So I was under the impression that debian-legal is the correct list to
contact.
From the mails from Ondřej it seems that the reject decision was made by
the ftpmaster team, but as the argument for the decision was a legal one,
so I think that debian-legal is appropriate.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Paul Tagliamonte
2014-07-29 15:23:35 UTC
Permalink
Post by Ferenc Kovacs
"If you feel to dispute this please take your *well-formed* and
*well-thought* arguments to debian-legal."
... to discuss it. d-legal is a proper venue for *discussing* it, but
it's not the right one to discuss the actual critera for archive
fitness.

Which is likely why you didn't get a reply.
Post by Ferenc Kovacs
So I was under the impression that debian-legal is the correct list to
contact.
debian-legal has no delegated authority to make such decisions for the
archive.
Post by Ferenc Kovacs
From the mails from Ondřej it seems that the reject decision was made by
the ftpmaster team, but as the argument for the decision was a legal one,
so I think that debian-legal is appropriate.
... to discuss it. Not decide on critera.
Post by Ferenc Kovacs
--
Ferenc Kovács
@Tyr43l - [4]http://tyrael.hu
Cheers,
Paul
--
.''`. Paul Tagliamonte <***@debian.org> | Proud Debian Developer
: :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87
`. `'` http://people.debian.org/~paultag
`- http://people.debian.org/~paultag/conduct-statement.txt
Ferenc Kovacs
2014-07-29 15:46:32 UTC
Permalink
Post by Paul Tagliamonte
Post by Ferenc Kovacs
"If you feel to dispute this please take your *well-formed* and
*well-thought* arguments to debian-legal."
... to discuss it. d-legal is a proper venue for *discussing* it, but
it's not the right one to discuss the actual critera for archive
fitness.
Which is likely why you didn't get a reply.
nobody participated in the discussion from your side.
Post by Paul Tagliamonte
Post by Ferenc Kovacs
So I was under the impression that debian-legal is the correct list to
contact.
debian-legal has no delegated authority to make such decisions for the
archive.
I didn't said anything about debian-legal having the authority to do any
decision.
Ondrej claimed that the decision was made on legal concerns, and that any
further discussion should happen on debian-legal, which kind-of made sense.
From your reply I'm not sure what are you arguing about. That this isn't a
legal problem, so no reason to discuss it on debian-legal, or you think
that there isn't much to discuss there, because you have no power over the
decision?
I've find it a bit disturbing, that ftpmasters can make a decision on legal
grounds(which is the probably the highest priority for debian as far as I'm
concerned), without any backing from debian-legal(the original thread one
debian-legal got a single reply which doesn't supported the reject.
https://lists.debian.org/debian-legal/2005/08/msg00130.html), years later
ftpmasters can decide to drop a bunch of packages based on the legal
problem and point to debian-legal@ for further discussion where first
nobody replies, then we are told that it isn't the proper place to write
and that we should write to the same people who made the decision. o.O
Post by Paul Tagliamonte
Post by Ferenc Kovacs
From the mails from Ondřej it seems that the reject decision was made
by
Post by Ferenc Kovacs
the ftpmaster team, but as the argument for the decision was a legal
one,
Post by Ferenc Kovacs
so I think that debian-legal is appropriate.
... to discuss it. Not decide on critera.
sigh.
you are trying a nice job making any kind of discussion as talking to a
brick wall.
where did I said anything about you making any decision?
I was talking about why did it seemed reasonable to follow Ondrej's advice
and write to debian-legal@ to discuss a decision made on legal grounds to
discuss the decision and find a solution satisfying all parties.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Walter Landry
2014-07-29 19:16:53 UTC
Permalink
Post by Ferenc Kovacs
I've find it a bit disturbing, that ftpmasters can make a decision on legal
grounds(which is the probably the highest priority for debian as far as I'm
concerned), without any backing from debian-legal
debian-legal has no authority to decide anything. It is just a
mailing list. We can discuss things here day and night and
ftp-masters can ignore it.

With that said, debian-legal can be useful when issues are clear-cut.
For example, if someone asks if the Apache 2.0 license is compatible
with the GPL (no for GPL 2.0, yes for GPL 3.0). Think of debian-legal
as the secretary for ftp-masters. We can sometimes divine what they
are thinking, but the final word belongs to ftp-masters.

In any case, in the interest of making this email constructive, my
take on the PHP license is that it does need to be fixed. From
ftp-masters REJECT-FAQ, they also think so. So my advice would be to
just use a well known, existing license and be done with it. Judging
from the existing PHP license, the closest thing would be the 3 clause
BSD license

http://opensource.org/licenses/BSD-3-Clause

Apache 2.0 would also be a good choice.

Now, I understand that changing licenses is a huge chore, and the
benefits can sometimes be intangible. The main benefit is that you
will never have to deal with us again ;)

Cheers,
Walter Landry
***@caltech.edu
Rasmus Lerdorf
2014-07-29 21:36:37 UTC
Permalink
Post by Walter Landry
Post by Ferenc Kovacs
I've find it a bit disturbing, that ftpmasters can make a decision on legal
grounds(which is the probably the highest priority for debian as far as I'm
concerned), without any backing from debian-legal
debian-legal has no authority to decide anything. It is just a
mailing list. We can discuss things here day and night and
ftp-masters can ignore it.
With that said, debian-legal can be useful when issues are clear-cut.
For example, if someone asks if the Apache 2.0 license is compatible
with the GPL (no for GPL 2.0, yes for GPL 3.0). Think of debian-legal
as the secretary for ftp-masters. We can sometimes divine what they
are thinking, but the final word belongs to ftp-masters.
In any case, in the interest of making this email constructive, my
take on the PHP license is that it does need to be fixed. From
ftp-masters REJECT-FAQ, they also think so. So my advice would be to
just use a well known, existing license and be done with it. Judging
from the existing PHP license, the closest thing would be the 3 clause
BSD license
http://opensource.org/licenses/BSD-3-Clause
Apache 2.0 would also be a good choice.
Now, I understand that changing licenses is a huge chore, and the
benefits can sometimes be intangible. The main benefit is that you
will never have to deal with us again ;)
We will not be changing the license to Apache 2.0

I see absolutely no problem with PHP projects distributed from *.php.net
carrying the PHP license. The license talks about "PHP Software" which
we define as software you get from/via *.php.net. We support external
repos such as github, but they are still linked back to php.net via
their pecl.php.net entries, for example. For things that aren't
distributed via pecl.php.net, pear.php.net or www.php.net itself, I can
see the argument, but those are not projects we can do anything about.

-Rasmus
Ben Finney
2014-07-30 00:21:27 UTC
Permalink
Post by Rasmus Lerdorf
I see absolutely no problem with PHP projects distributed from
*.php.net carrying the PHP license. The license talks about "PHP
Software" which we define as software you get from/via *.php.net.
Specifically, the license text <URL:http://php.net/license/3_01.txt> has
this clause:

6. Redistributions of any form whatsoever must retain the following
acknowledgment:
"This product includes PHP software, freely available from
<http://www.php.net/software/>".

Nowhere is “PHP software” defined in the license. Will you update the
license to make your above definition explicit in the license terms?
Post by Rasmus Lerdorf
We support external repos such as github, but they are still linked
back to php.net via their pecl.php.net entries, for example. For
things that aren't distributed via pecl.php.net, pear.php.net or
www.php.net itself, I can see the argument, but those are not projects
we can do anything about.
The problem is exacerbated, though, by the specific license terms.

The license terms do not apply sensibly outside your stated definition;
yet many software works begin outside that definition, and only later
make their way to the locations you mention. This distinction is *not*
the case for more widely-accepted license terms, so the distinction is
easy to miss.

This does not need to be the case; it is made the case by the specific
terms of this license. That is a problem which can be addressed by
changing the terms of the license to be generally applicable.
--
\ “Those who write software only for pay should go hurt some |
`\ other field.” —Erik Naggum, in _gnu.misc.discuss_ |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to debian-legal-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@benfinney.id.au
Riley Baird
2014-07-30 05:03:28 UTC
Permalink
Post by Ben Finney
Post by Rasmus Lerdorf
I see absolutely no problem with PHP projects distributed from
*.php.net carrying the PHP license. The license talks about "PHP
Software" which we define as software you get from/via *.php.net.
Specifically, the license text <URL:http://php.net/license/3_01.txt> has
6. Redistributions of any form whatsoever must retain the following
"This product includes PHP software, freely available from
<http://www.php.net/software/>".
Nowhere is “PHP software” defined in the license. Will you update the
license to make your above definition explicit in the license terms?
"PHP software" doesn't need to be defined. The phrase is not used in the
license except as an acknowledgement that must accompany any
redistributions.

It could just as easily require that any redistributions must have the
acknowledgement "This project contains giraffes, which are a type of
fish", and the software could still be considered free.

If you're worried about having to include false information with your
software product, you could say something along the lines of "The below
notices are untrue, but are requirements of various FOSS licenses".
Post by Ben Finney
The license terms do not apply sensibly outside your stated definition;
yet many software works begin outside that definition, and only later
make their way to the locations you mention. This distinction is *not*
the case for more widely-accepted license terms, so the distinction is
easy to miss.
When applied to software that is not available from *.php.net, the
license terms may not be sensible, but they still can be followed. The
only problem that I can see with the license is the phrase:

This software consists of voluntary contributions made by many
individuals on behalf of the PHP Group.

The word 'voluntary' may not apply to all contributions made by
individuals made on behalf on the PHP group.

Also, not everyone that uses the PHP license is able to act on behalf of
the PHP group.
--
To UNSUBSCRIBE, email to debian-legal-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@bitmessage.ch
Ben Finney
2014-07-30 05:29:24 UTC
Permalink
Post by Riley Baird
Post by Rasmus Lerdorf
I see absolutely no problem with PHP projects distributed from
*.php.net carrying the PHP license. The license talks about "PHP
Software" which we define as software you get from/via *.php.net.
[…]
Post by Riley Baird
It could just as easily require that any redistributions must have the
acknowledgement "This project contains giraffes, which are a type of
fish", and the software could still be considered free.
If you're worried about having to include false information with your
software product, you could say something along the lines of "The
below notices are untrue, but are requirements of various FOSS
licenses".
You're advocating a position, then, that the PHP license can require
recipients to make false, and even nonsensical, claims, and that this is
not a problem to be addressed by improving the license terms.

Is that the position of the PHP Group: that a requirement for the
recipient to make false claims is “absolutely no problem” of the
license?

[…]
Post by Riley Baird
When applied to software that is not available from *.php.net, the
license terms may not be sensible, but they still can be followed.
Is the fact they can't sensibly be followed not a problem to be
addressed by improving the license terms?
Post by Riley Baird
This software consists of voluntary contributions made by many
individuals on behalf of the PHP Group.
Thanks, I agree that's a problem. It doesn't belong in the license (it
has nothing to do with the permissions granted to the recipient), but
rather belongs in the copyright statement for the specific work.

The license would be improved – made clearer and more generally
applicable – by removing that clause from the license and placing it
instead in the copyright statement.
--
\ “I put contact lenses in my dog's eyes. They had little |
`\ pictures of cats on them. Then I took one out and he ran around |
_o__) in circles.” —Steven Wright |
Ben Finney
--
To UNSUBSCRIBE, email to debian-legal-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@benfinney.id.au
Riley Baird
2014-07-30 06:19:50 UTC
Permalink
Post by Ben Finney
You're advocating a position, then, that the PHP license can require
recipients to make false, and even nonsensical, claims, and that this is
not a problem to be addressed by improving the license terms.
I think that this is similar to the BSD licenses. Look at
/usr/share/common-licenses/BSD. It specifically states:

Neither the name of the University nor the names of its contributors may
be used to endorse or promote products derived from this software
without specific prior written permission.
Post by Ben Finney
From this, it would seem that it is possible to use this license even if
you are not the University. Why else would Debian keep this in
/usr/share/common-licenses?
Post by Ben Finney
Is that the position of the PHP Group: that a requirement for the
recipient to make false claims is “absolutely no problem” of the
license?
I don't think that the position of the PHP Group is that requiring the
recipient to make false claims is "absolutely no problem"; the license
works for *them*; it just doesn't work for anyone else who chooses to
use their license
Post by Ben Finney
Post by Riley Baird
When applied to software that is not available from *.php.net, the
license terms may not be sensible, but they still can be followed.
Is the fact they can't sensibly be followed not a problem to be
addressed by improving the license terms?
It could be addressed by improving the licensing terms, but it isn't
necessary, and the PHP Group seems very unwilling to do so.
--
To UNSUBSCRIBE, email to debian-legal-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@bitmessage.ch
Ferenc Kovacs
2014-07-30 06:51:51 UTC
Permalink
Post by Ben Finney
Post by Rasmus Lerdorf
I see absolutely no problem with PHP projects distributed from
*.php.net carrying the PHP license. The license talks about "PHP
Software" which we define as software you get from/via *.php.net.
Specifically, the license text <URL:http://php.net/license/3_01.txt> has
6. Redistributions of any form whatsoever must retain the following
"This product includes PHP software, freely available from
<http://www.php.net/software/>".
Nowhere is “PHP software” defined in the license. Will you update the
license to make your above definition explicit in the license terms?
for the record: http://www.php.net/software.php explicitly lists php.net,
pear.php.net and pecl.php.net as the places you can get the Software from.
Pierre Joye
2014-07-30 05:09:19 UTC
Permalink
hi Walter,
Post by Walter Landry
Post by Ferenc Kovacs
I've find it a bit disturbing, that ftpmasters can make a decision on legal
grounds(which is the probably the highest priority for debian as far as I'm
concerned), without any backing from debian-legal
debian-legal has no authority to decide anything. It is just a
mailing list. We can discuss things here day and night and
ftp-masters can ignore it.
With that said, debian-legal can be useful when issues are clear-cut.
For example, if someone asks if the Apache 2.0 license is compatible
with the GPL (no for GPL 2.0, yes for GPL 3.0). Think of debian-legal
as the secretary for ftp-masters. We can sometimes divine what they
are thinking, but the final word belongs to ftp-masters.
In any case, in the interest of making this email constructive, my
take on the PHP license is that it does need to be fixed. From
ftp-masters REJECT-FAQ, they also think so. So my advice would be to
just use a well known, existing license and be done with it. Judging
from the existing PHP license, the closest thing would be the 3 clause
BSD license
http://opensource.org/licenses/BSD-3-Clause
Apache 2.0 would also be a good choice.
Now, I understand that changing licenses is a huge chore, and the
benefits can sometimes be intangible. The main benefit is that you
will never have to deal with us again ;)
As Rasmus, and I, said numerous times, the PHP License is a perfectly
valid choice as long as the software are distributed under *.php.net.
I see this move as yet another attempt to force developers to abandon
a totally valid license in the name of the Debian ideal, Free
Softwares. I cannot blame anyone willing to reach this goal but as a
matter of fact, there is no issue with the PHP license, not anymore
since 3.01.

And about dealing with Debian about that, well, Debian has actually
more to lose than any other 3rd parties. Let focus on getting the web
stack rocks on Debian instead.

Cheers,
--
Pierre

@pierrejoye | http://www.libgd.org
Thorsten Glaser
2014-07-30 11:07:53 UTC
Permalink
Post by Pierre Joye
As Rasmus, and I, said numerous times, the PHP License is a perfectly
valid choice as long as the software are distributed under *.php.net.
This reading clearly fails DFSG#3 and OSD#3 at the very least, and makes
*all* software using the PHP Licence non-free, because redistribution of
derived works is only permitted from *.php.net which is clearly inaccep-
table. This makes not just forking the software impossible but also dis-
tribution of binaries made from modified sources, for example.

On the other hand, my own reading of the PHP Licence is that we may not,
in fact, distribute (binaries of) modified versions of PHP software (the
interpreter as well as everything else under that licence), period - but
that distributing the original source alongside patches is okay (e.g. as
3.0 (quilt) source package). Since Debian isn't distributing source pak-
kages, this does not help us. A written permission from ***@php.net is
not helpful either, because of DFSG#8.

(In BSD ports, we also do not distribute binaries of PHP.)

I think you should rethink your stance and the PHP licence on all of the
issues listed. Similar issues arose from the Firefox trademark after all
(and it would be fun if Debian distributed Icescriptinglanguage, instead
of PHP, except for those affected).

bye,
//mirabilos
Riley Baird
2014-07-30 11:30:06 UTC
Permalink
Post by Thorsten Glaser
Post by Pierre Joye
As Rasmus, and I, said numerous times, the PHP License is a perfectly
valid choice as long as the software are distributed under *.php.net.
This reading clearly fails DFSG#3 and OSD#3 at the very least, and makes
*all* software using the PHP Licence non-free, because redistribution of
derived works is only permitted from *.php.net which is clearly inaccep-
table. This makes not just forking the software impossible but also dis-
tribution of binaries made from modified sources, for example.
I agree that this would violate DFSG#3.

However, I'm not convinced that the PHP license is only valid if the
software is distributed under *.php.net. Nowhere within the license does
it say that the program being licensed is PHP software, so the PHP
Group's definition of PHP software is irrelevant.
Post by Thorsten Glaser
On the other hand, my own reading of the PHP Licence is that we may not,
in fact, distribute (binaries of) modified versions of PHP software (the
interpreter as well as everything else under that licence), period - but
that distributing the original source alongside patches is okay (e.g. as
3.0 (quilt) source package). Since Debian isn't distributing source pak-
not helpful either, because of DFSG#8.
Good point. (I think you're referring to section 4; correct me if I'm
wrong.) This would make PHP-licensed software *with PHP in the title*
non-free until rebranded, like firefox was until rebranded to iceweasel.

This would not, however, make the license non-free, it would just make
for some annoying rebranding, which should be much more manageable.
Thorsten Glaser
2014-07-30 11:47:14 UTC
Permalink
Post by Riley Baird
I agree that this would violate DFSG#3.
However, I'm not convinced that the PHP license is only valid if the
software is distributed under *.php.net. Nowhere within the license does
it say that the program being licensed is PHP software, so the PHP
Group's definition of PHP software is irrelevant.
Yes. I also think that this is merely the case of a (possibly
factually incorrect) advertising clause. Similar to, if you
take say the BIO_* code from OpenSSL, and make that into a
stand-alone library, that library's licence would still require
mentioning that the product includes crypto code from EAY even
though the code is not crypto code.

This can be ameliorated by prefixing that advertising remark
with a comment about its factual wrongness. This is something
I would prefer the upstream developers to do, but can, IMHO,
also be done within Debian, if needed.
Post by Riley Baird
Post by Thorsten Glaser
On the other hand, my own reading of the PHP Licence is that we may not,
in fact, distribute (binaries of) modified versions of PHP software (the
interpreter as well as everything else under that licence), period - but
that distributing the original source alongside patches is okay (e.g. as
3.0 (quilt) source package). Since Debian isn't distributing source pak-
not helpful either, because of DFSG#8.
Good point. (I think you're referring to section 4; correct me if I'm
Right.
Post by Riley Baird
wrong.) This would make PHP-licensed software *with PHP in the title*
non-free until rebranded, like firefox was until rebranded to iceweasel.
Indeed. And seeing this, I think that Debian may ship neither the
PHP interpreter nor anything else under PHP licence without doing
a rebranding.
Post by Riley Baird
This would not, however, make the license non-free, it would just make
for some annoying rebranding, which should be much more manageable.
It would, however, make the licence inacceptable for Debian for
anything bearing PHP in its name, which is kinda the point of
the PHP licence.

This is why I would like to ask the people in charge of PHP to
reconsider licencing. Other BSD-style licences that seek to
protect the integrity of the author's source code request or
require mentioning, somewhere user-visible but not as annoying
as doing a total rebranding, that the version is modified. (In
the case of the original UW pine, for example, it was sufficient
and, in fact, suggested, to merely add the letter 'L' (for local
patches) to the version number, so "pine 4.64L" it is. In Debian,
we have modified version numbers already anyway, and can add a
note about this being a patched version of PHP in enough places.
For software that is not the PHP interpreter, this is even more
(or less, depending on the PoV and how close one is to the issue)
weird/funny.)

bye,
//mirabilos
Pierre Joye
2014-07-30 15:52:32 UTC
Permalink
Post by Thorsten Glaser
Post by Riley Baird
Post by Thorsten Glaser
On the other hand, my own reading of the PHP Licence is that we may not,
in fact, distribute (binaries of) modified versions of PHP software (the
interpreter as well as everything else under that licence), period - but
that distributing the original source alongside patches is okay (e.g. as
3.0 (quilt) source package). Since Debian isn't distributing source pak-
not helpful either, because of DFSG#8.
Good point. (I think you're referring to section 4; correct me if I'm
Right.
Post by Riley Baird
wrong.) This would make PHP-licensed software *with PHP in the title*
non-free until rebranded, like firefox was until rebranded to iceweasel.
Indeed. And seeing this, I think that Debian may ship neither the
PHP interpreter nor anything else under PHP licence without doing
a rebranding.
Post by Riley Baird
This would not, however, make the license non-free, it would just make
for some annoying rebranding, which should be much more manageable.
It would, however, make the licence inacceptable for Debian for
anything bearing PHP in its name, which is kinda the point of
the PHP licence.
This is not what the license says. The license says you cannot create
a derivative project and use PHP in its name. hhvm is a derivative
work for example. Distributing php, even by back porting patches, is
not a derivative work.

Cheers,
--
Pierre

@pierrejoye | http://www.libgd.org
Pierre Joye
2014-07-30 15:49:20 UTC
Permalink
Post by Thorsten Glaser
Post by Pierre Joye
As Rasmus, and I, said numerous times, the PHP License is a perfectly
valid choice as long as the software are distributed under *.php.net.
This reading clearly fails DFSG#3 and OSD#3 at the very least, and makes
*all* software using the PHP Licence non-free, because redistribution of
derived works is only permitted from *.php.net which is clearly inaccep-
table. This makes not just forking the software impossible but also dis-
tribution of binaries made from modified sources, for example.
This is a wrong interpretation. The releases are/must be distributed
under *.php.net to be able to use the PHP License. It means that one
reading the license after having installed php using apt-get php5 will
find all software installed with php5. There is nothing wrong here and
nothing about the location of the software release is against Free
Software.

The incompatibility between Free Software's GPL and the PHP license is
only due to the naming restriction and nothing else.

Cheers,
--
Pierre

@pierrejoye | http://www.libgd.org
Stas Malyshev
2014-07-30 20:00:17 UTC
Permalink
Hi!
Post by Thorsten Glaser
This reading clearly fails DFSG#3 and OSD#3 at the very least, and makes
*all* software using the PHP Licence non-free, because redistribution of
derived works is only permitted from *.php.net which is clearly inaccep-
table. This makes not just forking the software impossible but also dis-
tribution of binaries made from modified sources, for example.
I've by now read the PHP license here:
http://php.net/license/3_01.txt
about a dozen times and I still can't figure out where the claim
"redistribution of derived works is only permitted from *.php.net" could
come from. This of course is false both theoretically and practically.
Post by Thorsten Glaser
On the other hand, my own reading of the PHP Licence is that we may not,
in fact, distribute (binaries of) modified versions of PHP software (the
interpreter as well as everything else under that licence), period - but
You could not distribute other derived products bearing the name of PHP
- but distributing PHP itself is fine, since it's not a "product derived
from PHP" but the actual PHP. If Debian OTOH decides to make their own
fork of PHP, they can distribute it still, but not under the name of
"PHP". I don't think Debian even claimed that the thing they distribute
under the name of PHP is anything but the original product, so I don't
see a problem here. I'm not sure why there's an effort to seek maximally
contorted interpretation of the rules that would appear to disallow
Debian to do something that Debian is already doing, has been doing for
years, and nobody ever objected to Debian doing and nobody ever intends
to object. To me this effort does not seem to be constructive, and not
leading to any improvement of anything, but only to more inconvenience
and annoyance to everybody involved.
Post by Thorsten Glaser
(and it would be fun if Debian distributed Icescriptinglanguage, instead
of PHP, except for those affected).
I think taking this route would make Debian a huge disservice. Of
course, 99.999% of Debian users would immediately switch to using a
third-party repo that would include actual PHP packages instead of that
contraption, but there's no reason to inflict this onto Debian users.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
MJ Ray
2014-07-30 20:54:07 UTC
Permalink
Post by Stas Malyshev
If Debian OTOH decides to make their own
fork of PHP, they can distribute it still, but not under the name of
"PHP". I don't think Debian even claimed that the thing they distribute
under the name of PHP is anything but the original product, so I don't
see a problem here. I'm not sure why there's an effort to seek
maximally
contorted interpretation of the rules that would appear to disallow
Debian to do something that Debian is already doing, has been doing for
years, and nobody ever objected to Debian doing and nobody ever intends
to object. To me this effort does not seem to be constructive, and not
leading to any improvement of anything, but only to more inconvenience
and annoyance to everybody involved.
I think everyone does claim that. You do know Debian doesn't just distribute the binaries from Php.net, right? No contortion: the php5 in Debian is a derived work. Here's a list of patches http://sources.debian.net/src/php5/5.6.0%7Erc2%2Bdfsg-5/debian/patches

I agree that renaming would not be constructive. Why can't people call this PHP, please, PHP project? Would you change the licence to something more usual, like MIT/X style?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Stas Malyshev
2014-07-30 23:54:35 UTC
Permalink
Hi!
Post by MJ Ray
I think everyone does claim that. You do know Debian doesn't just
Everyone being whom specifically?
Post by MJ Ray
distribute the binaries from Php.net, right? No contortion: the php5
in Debian is a derived work. Here's a list of patches
http://sources.debian.net/src/php5/5.6.0%7Erc2%2Bdfsg-5/debian/patches
There is no such thing as "binaries from php.net", at least when
Debian-supported OSes are concerned. But even if they were, it's not a
separate product in any sane meaning of a product. Adding a config file
does not make it into a new product. Neither I have ever seen any
communication from Debian claiming it is anything but the product we all
know and love as "PHP". One could invent a thousand of contorted
definition of "product", including defining every binary with different
sha1 checksum as separate product, but this pointless exercise has
nothing to do with PHP and is just that - pointless.
Post by MJ Ray
I agree that renaming would not be constructive. Why can't people
call this PHP, please, PHP project?
They can, and they were told so many, many times.
Post by MJ Ray
Would you change the licence to something more usual, like MIT/X style?
No, this is completely infeasible - this would require asking permission
from every contributor from the start of the project. Moreover, this
titanic effort would be completely useless as it would achieve no useful
purpose, because everybody - including Debian - is free to distribute
PHP under PHP license right now, and nobody ever tried to prevent
anybody from doing so. Literally nobody except Debian people ever said
there's any problem in that. Frankly, I am astonished at how much effort
is spend to find trouble where there was not ever one. Can't we spend
our time on something more useful?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Walter Landry
2014-07-31 00:54:10 UTC
Permalink
Post by Stas Malyshev
Post by MJ Ray
Would you change the licence to something more usual, like MIT/X style?
No, this is completely infeasible
That is not correct. It is very easy to change the license because
the license has an upgrade clause (condition #5).

Cheers,
Walter Landry
Riley Baird
2014-07-31 06:25:46 UTC
Permalink
Post by Walter Landry
Post by Stas Malyshev
Post by MJ Ray
Would you change the licence to something more usual, like MIT/X style?
No, this is completely infeasible
That is not correct. It is very easy to change the license because
the license has an upgrade clause (condition #5).
Of course, if the license is changed, then it shouldn't be MIT/X
exactly, but it should be MIT/X plus an upgrade clause.
Ángel González
2014-07-30 21:55:59 UTC
Permalink
Post by Stas Malyshev
Post by Thorsten Glaser
On the other hand, my own reading of the PHP Licence is that we may not,
in fact, distribute (binaries of) modified versions of PHP software (the
interpreter as well as everything else under that licence), period - but
You could not distribute other derived products bearing the name of PHP
- but distributing PHP itself is fine, since it's not a "product derived
from PHP" but the actual PHP. If Debian OTOH decides to make their own
fork of PHP, they can distribute it still, but not under the name of
"PHP". I don't think Debian even claimed that the thing they distribute
under the name of PHP is anything but the original product, so I don't
see a problem here. I'm not sure why there's an effort to seek maximally
contorted interpretation of the rules that would appear to disallow
Debian to do something that Debian is already doing, has been doing for
years, and nobody ever objected to Debian doing and nobody ever intends
to object. To me this effort does not seem to be constructive, and not
leading to any improvement of anything, but only to more inconvenience
and annoyance to everybody involved.
They have a point. A buggy php version with an added patch that avoids
that it crashes when run on even dates could be considered -from a legal
POV- a «derivative product of PHP». Legal-speak is quite different than
common sense.

Trying to keep the spirit of the PHP License and at the same time solve
that
strict interpretation, I propose the following change to the PHP License
3.01,
which will hopefully please both parties:


--- 3_01.txt 2014-07-30 22:58:13.682449866 +0200
+++ 3_02.txt 2014-07-30 23:20:07.332445907 +0200
@@ -24,6 +24,13 @@
from ***@php.net. You may indicate that your software works in
conjunction with PHP by saying "Foo for PHP" instead of calling
it "PHP Foo" or "phpfoo"
+
+ 4½ On the other hand, minor patches to products already containing
+ the "PHP" label, including without exception those fixing its
+ security and/or functionality, are not considered a new product
+ and do not require any additional permission. Nonetheless their
+ version string should be modified in order to clearly differenciate
+ them from the official versions published by the original author(s).

5. The PHP Group may publish revised and/or new versions of the
license from time to time. Each version will be given a

Notes:
There is some ambiguity on what is a «minor patch», but I feel it's better
to leave that to the courts should a lawsuit really arise (which would be a
non-clear case) than attempting to set an arbitrary limit on number of diff
lines or an appropiate ratio with the original code, which would fail sooner
or later. Use Common Sense for determining if it's a minor patch.

Still, bugfixes are explicitely listed as minor, given that they will be
the most
common case and the one which concerns Debian modifications.

The result of those small modifications of PHP-labeled products is that
requisites
of §3 and §4 are waived, which IMHO is in the spirit of the PHP License
as asserted
by the current usage.

The mention for modifying the version string was inspired by Thorsten
email, and
is related to the clause present on other licenses that a Modified work
should be
presented as such. A variant would be changing the "should" into
"shall". I chose
the former version to allow waiving the requirement for trivial changes
or those
without a clear version string (think on builds from git or from
proposed patches).

The term “original author(s)” was preferred over “The PHP Group” for
including works
by third parties.

PS: 4½ is just a placeholder for discussion, the final version would
need renumbering.


Would this change have the blessing of Debian and the approval of PHP?
--
To UNSUBSCRIBE, email to debian-legal-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gmail.com
Walter Landry
2014-07-30 22:34:51 UTC
Permalink
Post by Ángel González
Trying to keep the spirit of the PHP License and at the same time
solve that strict interpretation, I propose the following change to
Stop. Please just stop. Please pick an existing, well known license
so that we do not have to argue *again* over whether this really
solves a
Alejandro Michelin Salomon (GMAIL)
2014-07-30 22:43:49 UTC
Permalink
Walter :

I agree to stop discussing this.

The problem is not PHP.

Only Debian can't accept de PHP license.

The PHP License is good for PHP as is? YES!!! that's all.

Alejandro M.S

-----Mensagem original-----
De: Walter Landry [mailto:***@caltech.edu]
Enviada em: quarta-feira, 30 de julho de 2014 19:35
Para: ***@gmail.com
Cc: ***@sugarcrm.com; ***@debian.org; pecl-***@lists.php.net; debian-***@lists.debian.org
Assunto: Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license
Post by Ángel González
Trying to keep the spirit of the PHP License and at the same time
solve that strict interpretation, I propose the following change to
Stop. Please just stop. Please pick an existing, well known license so that we do not have to argue *again* over whether this really solves all of the problems.

Thanks,
Walter Landry


---
Este email está limpo de vírus e malwares porque a proteção do avast! Antivírus está ativa.
http://www.avast.com
Thorsten Glaser
2014-07-31 07:28:34 UTC
Permalink
Post by Stas Malyshev
You could not distribute other derived products bearing the name of PHP
- but distributing PHP itself is fine, since it's not a "product derived
from PHP" but the actual PHP. If Debian OTOH decides to make their own
The actual PHP is still normally patched in a distribution.
+ 4B=3D On the other hand, minor patches to products already containing
Absolutely no! That would make the situation much worse.
This is very vague language, which will not help but
add insecurities.
There is some ambiguity on what is a B+minor patchB;, but I feel it's bet=
ter
to leave that to the courts should a lawsuit really arise (which would be=
a

The very idea of a distribution doing licence review is to
avoid things that could possibly, ever, go to court.
or later. Use Common Sense for determining if it's a minor patch.
That does not work in a legal environment, unfortunately.

This is why the OSI (and many others) say to please leave
writing licences (code for the scripting language called
legalese) to experts (lawyers), just as we=E2=80=99d not want the
lawyers to write C code.
Would this change have the blessing of Debian and the approval of PHP?
I highly doubt it. The current php5 source package in Debian
has 49 patches=E2=80=A6 on top of a 5.6 release candidate. Things like
porting to new platforms, etc. are not minor. One is named
=E2=80=9Chack-phpdbg-to-explicitly-link-with-libedit.patch=E2=80=9D. You co=
uld
say that every distribution makes a fork.

Looking at a BSD=E2=80=A6 there are 34 patches in MirPorts for PHP
as well, though the licence information there is set to say
that binaries may not be redistributed. Another option would
be to simply rename PHP to=E2=80=A6 Icescriptinglanguage? ;-)

bye,
//mirabilos (Debian Developer, but also MirBSD founder)
=09who=E2=80=99d personally prefer to just shut up and hack
=09instead of dealing with legal issues=E2=80=A6
--=20
=E2=80=9Cah that reminds me, thanks for the stellar entertainment that you =
and certain
other people provide on the Debian mailing lists =E2=94=82 sole reason I su=
bscribed to
them (I'm not using Debian anywhere) is the entertainment factor =E2=94=82 =
Debian does
not strike me as a place for good humour, much less German admin-style humo=
ur=E2=80=9D
Ángel González
2014-07-31 19:53:40 UTC
Permalink
Post by Thorsten Glaser
Post by Stas Malyshev
You could not distribute other derived products bearing the name of PHP
- but distributing PHP itself is fine, since it's not a "product derived
from PHP" but the actual PHP. If Debian OTOH decides to make their own
The actual PHP is still normally patched in a distribution.
+ 4B= On the other hand, minor patches to products already containing
Absolutely no! That would make the situation much worse.
This is very vague language, which will not help but
add insecurities.
I understand that's what the PHP developers are trying to express with
the PHP License
(although it's not explictely named as such). You may prefer a term like
"substantially
modified" but it's the same thing.
Post by Thorsten Glaser
There is some ambiguity on what is a B+minor patchB;, but I feel it's better
to leave that to the courts should a lawsuit really arise (which would be a
The very idea of a distribution doing licence review is to
avoid things that could possibly, ever, go to court.
There are clear cases of minor changes (eg. it applies some three-line
patches), clear
cases of major changes (suppose that the php engine was changed to run
javascript
instead!) and cases where it's not that clear (and should thus be
avoided without a
package rename).

You can see Scratch_Trademark_Policy for an example of lawyer-written
text using similar terms.
http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code#Scratch_Trademark_Policy

Please remember that we are just talking about changes that Debian
itself may want to
perform (so it doesn't require a renaming which would be bad both for
PHP and Debian
users).
Post by Thorsten Glaser
or later. Use Common Sense for determining if it's a minor patch.
That does not work in a legal environment, unfortunately.
That tried to explain the . Yet some dumb could that their
javascript-running engine
can be named php-foo because he has a series of three-line patches
converting one
into the other.
Post by Thorsten Glaser
This is why the OSI (and many others) say to please leave
writing licences (code for the scripting language called
legalese) to experts (lawyers), just as we’d not want the
lawyers to write C code.
This was just a proposal that could serve as starting point. I wouldn't
expect that PHP
blindly accepted it without consulting a lawyer!
Post by Thorsten Glaser
Would this change have the blessing of Debian and the approval of PHP?
I highly doubt it. The current php5 source package in Debian
has 49 patches
 on top of a 5.6 release candidate. Things like
porting to new platforms, etc. are not minor. One is named
“hack-phpdbg-to-explicitly-link-with-libedit.patch”. You could
say that every distribution makes a fork.
Even with that funny name, it only changes
PHPDBG_EXTRA_LIBS="$PHP_READLINE_LIBS" to PHPDBG_EXTRA_LIBS="-ledit
-ltermcap".
I have reviewed them. Most are trivial-minor at first sight, often
chanes to m4s.
Some fpm patches do define new functions and may deserve a second look (but
are still simple, specially when compared to the full codebase).
use_embedded_timezonedb.patch does , although .

You raise a good point about porting, although it doesn't seem so bad.
Those
should be small changes (perhaps problems would appear if you needed to
include a lot of patches copying libc functions not available natively

but instead of copyng them on each program, they should be a library).


At the end of the day, php is substantially the same software on Linux
or Hurd
(where ptrace(2) doesn't work so Debian patched it), using date.timezone
or getting
it from /etc/localtime
Changes to the build system seem specially clear as “not changing too
much” the program itself.
Post by Thorsten Glaser
Looking at a BSD
 there are 34 patches in MirPorts for PHP
as well,
I count only 20 :S (all minor things, some that should have been done at
PHP)

(As an aside, it's sad in general to check package patches, since most
of them
should really be at upstream
)
Post by Thorsten Glaser
though the licence information there is set to say
that binaries may not be redistributed.
You are creating the patches with a license not allowing binary
redistribution?? You leave me
speechless.
Post by Thorsten Glaser
Another option would be to simply rename PHP to
 Icescriptinglanguage? ;-)
Well, that would be bad for Debian users just due to not fixing the
license to say what they
mean. Quite similar to the problem a few years back of djb programs
(considered
uncopyrightable by himself) which could not be considered PD due to lack
of an explicit
license.


Thanks for your insights, Thorsten



PS: The cvs daemon at anoncvs.mirbsd.org doesn't seem to be listening on
its IPv4 interface (81.169.181.30).
Thorsten Glaser
2014-07-31 20:38:18 UTC
Permalink
Post by Ángel González
Please remember that we are just talking about changes that Debian
itself may want to perform (so it doesn't require a renaming which
would be bad both for PHP and Debian users).
Right, but Debian probably (though it=E2=80=99s up to Ond=C5=99ej Sur=C3=BD=
, the
maintainer; there is no central instance) would not want to accept
a licence that says =E2=80=9Cyou may keep the name if your patches are
only this small, and if they get bigger or disagree with what
we say, you may not keep the name=E2=80=9D.

There is innovation, writing of new code, and patching code when
the packager disagrees with upstream (or =E2=80=93 worse =E2=80=93 when tec=
h-ctte
says so because some *other* maintainer within Debian is important
enough for them to judge to not force him to fix the bugs in *his*
package instead, and so the packager is in the minority and forced
to deviate from upstream, so that the package still fits into the
distro).

Also, Debian is a bit of promise to downstreams. I am not sure (I
did not specifically look at this part), but I think downstreams
should be able to not need to look at how _much_ patching the
licence allows=E2=80=A6
Post by Ángel González
Looking at a BSDb> as well,
I count only 20 :S (all minor things, some that should have been done at =
PHP)

There are some hidden in ../{core,extensions}/patches/
Post by Ángel González
(As an aside, it's sad in general to check package patches, since most of=
them
Post by Ángel González
should really be at upstreamb
Right. It=E2=80=99s been problematic (and doesn=E2=80=99t scale well when
you=E2=80=99re a small project) to get patches for a non-mainstream
OS into upstream (though the situation did get better over
the years). In fact, most of our patches are carried over
from OpenBSD, who also either did not submit them or did
not have luck with that. (Though their relationship to both
their upstreams and downstreams is a bit special anyway.)
Post by Ángel González
though the licence information there is set to say
that binaries may not be redistributed.
You are creating the patches with a license not allowing binary
redistribution?? You leave me speechless.
No, what I meant is: the port metadata says that we may not
distribute the binary packages.

It=E2=80=99s your licence which forbids that ;-)
Post by Ángel González
PS: The cvs daemon at anoncvs.mirbsd.org doesn't seem to be listening on =
its
Post by Ángel González
IPv4 interface (81.169.181.30).
There is no cvs d=C3=A6mon, it=E2=80=99s anonymous CVS over ssh. (Nobody
sane uses pserver =E2=80=93 it=E2=80=99s susceptible to MITM and all.)

(And yes, I=E2=80=99m gonna update that thing some day=E2=80=A6 but for wha=
t
I=E2=80=99m currently using it, that old beast serves well enough=E2=80=A6)

bye,
//mirabilos
--=20
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
=09-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
James Wade
2014-07-30 11:13:49 UTC
Permalink
Post by Pierre Joye
hi Walter,
Post by Walter Landry
Post by Ferenc Kovacs
I've find it a bit disturbing, that ftpmasters can make a decision on legal
grounds(which is the probably the highest priority for debian as far as I'm
concerned), without any backing from debian-legal
debian-legal has no authority to decide anything. It is just a
mailing list. We can discuss things here day and night and
ftp-masters can ignore it.
With that said, debian-legal can be useful when issues are clear-cut.
For example, if someone asks if the Apache 2.0 license is compatible
with the GPL (no for GPL 2.0, yes for GPL 3.0). Think of debian-legal
as the secretary for ftp-masters. We can sometimes divine what they
are thinking, but the final word belongs to ftp-masters.
In any case, in the interest of making this email constructive, my
take on the PHP license is that it does need to be fixed. From
ftp-masters REJECT-FAQ, they also think so. So my advice would be to
just use a well known, existing license and be done with it. Judging
from the existing PHP license, the closest thing would be the 3 clause
BSD license
http://opensource.org/licenses/BSD-3-Clause
Apache 2.0 would also be a good choice.
Now, I understand that changing licenses is a huge chore, and the
benefits can sometimes be intangible. The main benefit is that you
will never have to deal with us again ;)
As Rasmus, and I, said numerous times, the PHP License is a perfectly
valid choice as long as the software are distributed under *.php.net.
I see this move as yet another attempt to force developers to abandon
a totally valid license in the name of the Debian ideal, Free
Softwares. I cannot blame anyone willing to reach this goal but as a
matter of fact, there is no issue with the PHP license, not anymore
since 3.01.
And about dealing with Debian about that, well, Debian has actually
more to lose than any other 3rd parties. Let focus on getting the web
stack rocks on Debian instead.
Cheers,
Hi all,

Is it possible we can then work towards a resolution on this near decade
old problem?

Now we've established that the PHP License v3.01 resolves the problem
outlined in the 2005 email, surely the PHP License can be removed from
the "Serious violations" list on the Debian FTP.

https://ftp-master.debian.org/REJECT-FAQ.html

Thanks.
Riley Baird
2014-07-30 11:56:43 UTC
Permalink
Hi all,
Is it possible we can then work towards a resolution on this near decade
old problem?
Now we've established that the PHP License v3.01 resolves the problem
outlined in the 2005 email, surely the PHP License can be removed from
the "Serious violations" list on the Debian FTP.
https://ftp-master.debian.org/REJECT-FAQ.html
Thanks.
When was the problem outlined in the 2005 email resolved? The debate is
still very much going on on -legal, at least.
Ferenc Kovacs
2014-07-30 12:21:09 UTC
Permalink
On Wed, Jul 30, 2014 at 1:56 PM, Riley Baird <
Post by Riley Baird
Hi all,
Is it possible we can then work towards a resolution on this near decade
old problem?
Now we've established that the PHP License v3.01 resolves the problem
outlined in the 2005 email, surely the PHP License can be removed from
the "Serious violations" list on the Debian FTP.
https://ftp-master.debian.org/REJECT-FAQ.html
Thanks.
When was the problem outlined in the 2005 email resolved? The debate is
still very much going on on -legal, at least.
here:
https://lists.debian.org/debian-legal/2006/02/msg00017.html

basically what happened is that it was a long discussion back in 2005/2006
which resulted in the creation of the php license version 3.01 and albeit
some people (on debian-legal) didn't agreed that it is resolves the issue,
the case discussion died and the packages were accepted.
some years passed and recently php packages started to get rejected based
on the original reject-faq entry dating back to 2005 (before the release of
the 3.01 php license version).
the debate only resurrected after that move to start rejecting the packages.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Charles Plessy
2014-07-29 22:38:24 UTC
Permalink
Post by Ferenc Kovacs
from the replies on the debian mailing lists it seems that this decision on
dropping any project using the php license distributed outside of php-src
is controversial to say the least.
Hello Ferenc,

from an outsider point of view (I do not maintain PHP packages in Debian),
my impresssion is also that the removal of PHP packages is controversial.
I guess you also saw the LWN article here: http://lwn.net/Articles/604630/

The good news is that things can resolve without formal decision: the immediate
cause for removing some PHP packages from our Testing distribution (that
represents our future release, not the Debian archive as a whole) is that bugs
of severity serious were filed against them to represent the licensing
question. If one closes these bugs or downgrade their severity, then the
packages automatically (modulo a small delay) become part of Testing again.
This already has been done for packages such as php-memcached, and could be
done for others.

Thank you for your patience !
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-legal-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@falafel.plessy.net
Ian Jackson
2014-07-30 12:09:22 UTC
Permalink
There has been an ongoing and wholly unproductive conversation on
-legal about some difficulties with the PHP licence.

Would it be possible for us to obtain some proper legal advice ?
Do we have a relationship with the SFLC we could use for this ?

If so I would be happy to write up a summary of the facts and the
questions to put to our lawyers. I think this is likely to be
straightforward but I would send a draft to -legal and ftpmaster@ to
check that the answer would actually resolve the problem one way or
another.

Ian.
Lucas Nussbaum
2014-07-30 13:06:00 UTC
Permalink
Hi Ian,

Thanks for bringing this up.
Post by Ian Jackson
There has been an ongoing and wholly unproductive conversation on
-legal about some difficulties with the PHP licence.
Would it be possible for us to obtain some proper legal advice ?
Do we have a relationship with the SFLC we could use for this ?
Sure, we could ask for advice from SFLC about this.
Post by Ian Jackson
If so I would be happy to write up a summary of the facts and the
questions to put to our lawyers. I think this is likely to be
check that the answer would actually resolve the problem one way or
another.
I think that such a summary would be very useful, at least to increase
the awareness about the issue, and to improve the description of the
violation on ftpmasters' REJECT FAQ.

However, based on my own (possibly limited) understanding of the
issue[1], this is case of a license (the PHP License) with sub-optimal
wording that is misused by third parties, as it was initially designed
for PHP itself, and is used for random software written in PHP.
As a result, the license adds some restrictions for derivative works
that could prevent software under that license to meet the DFSG.

So I think that it is important to distinguish between two different
questions:
(1) Is there a legal risk for Debian to distribute such software?
(2) Does the Debian project want to tolerate and ignore this sad
situation, or try to make the world a better place by working
on fixing this mess?

[1] built on reading #728196, the thread starting at
https://lists.debian.org/debian-devel/2014/06/msg00493.html
and the one starting at
https://lists.debian.org/debian-legal/2014/07/msg00024.html

When you have a summary and questions ready, we can work together on
forwarding them to SFLC for legal advice.

Lucas
Ian Jackson
2014-07-30 13:58:21 UTC
Permalink
Post by Lucas Nussbaum
Post by Ian Jackson
Would it be possible for us to obtain some proper legal advice ?
Do we have a relationship with the SFLC we could use for this ?
Sure, we could ask for advice from SFLC about this.
OK, good.
Post by Lucas Nussbaum
Post by Ian Jackson
If so I would be happy to write up a summary of the facts and the
questions to put to our lawyers. I think this is likely to be
check that the answer would actually resolve the problem one way or
another.
I think that such a summary would be very useful, at least to increase
the awareness about the issue, and to improve the description of the
violation on ftpmasters' REJECT FAQ.
Yes.
Post by Lucas Nussbaum
However, based on my own (possibly limited) understanding of the
issue[1], this is case of a license (the PHP License) with sub-optimal
wording that is misused by third parties, as it was initially designed
for PHP itself, and is used for random software written in PHP.
As a result, the license adds some restrictions for derivative works
that could prevent software under that license to meet the DFSG.
That is the contention of the critics, yes.
Post by Lucas Nussbaum
So I think that it is important to distinguish between two different
(1) Is there a legal risk for Debian to distribute such software?
I would want to ask whether there is a risk for others, too.
Post by Lucas Nussbaum
(2) Does the Debian project want to tolerate and ignore this sad
situation, or try to make the world a better place by working
on fixing this mess?
If we have a piece of legal advice which says that the risk is
minimal, then surely that would be sufficient to make the world a
place.

It would surely be nice to fix this wrinkle in the PHP licence but if
it doesn't actually meaningfully prevent anyone from doing anything
they would want to, then no-one's actual freedom is impinged and
reacting to it by throwing this software out of the archive is quite
disproportionate.

On the other hand if it _does_ pose a legal risk, then a legal opinion
to say so would be very helpful in persuading the software's upstreams
that it needs to be fixed.
Post by Lucas Nussbaum
When you have a summary and questions ready, we can work together on
forwarding them to SFLC for legal advice.
I will get back to you.

Ian.
Ian Jackson
2014-08-01 13:22:50 UTC
Permalink
Draft question for SFLC:


Some members of the Debian project have some concerns about the PHP
licence. These worries are dismissed by other members and by relevant
upstreams.

We are concerned here with the PHP 3.0 Licence, which can be found
here: http://php.net/license/3_0.txt

There are two concerns (I and II, below), which need to be read with
some context (III, below):


I. Requirement to perhaps-falsely acknowledge:

Paragraph 6 of the main licence text requires this notice:

"This product includes PHP, freely available from
<http://www.php.net/>".

This is unproblematic for PHP itself. However, most PHP addons are
also distributed under the PHP licence. The worry is that putting
`This product includes PHP' in the copyright information for a PHP
addon package is in fact making a false statement, since the package
itself does not include PHP.

Counterarguments which may be relevant or have been put forward
include:

(a) When a PHP addon is distributed under the PHP licence, the
licensor obviously did not intend the licencees to make a false
statement, and the requirement in the licence should be read down
accordingly.

(b) The word `product' does not refer to a specific package but the to
the system as a whole, including PHP.

(c) PHP addon packages are often distributed from www.php.net and
those packages therefore be regarded as `PHP' for the purposes of this
statement. (But what if the addon later ceases to be distributed from
www.php.net, or was never so distributed?)

We have the following questions:

Q1. What is the best approach for Debian and its downstreams to take
to comply with this licence ? Specifically, when preparing and
distributing Debian package of PHP addon, should we include the
statement:
This product includes PHP, freely available from
<http://www.php.net/>
?

Q2. If the answer to Q1 is to include the statement, does including
this statement pose any ethical, legal or practical risk to anyone
in the Free Software community ? Is it fair to say that the
statement is materially false or misleading ?

Q3. If the answer to Q1 is to NOT include the statement, does that
present a risk that the copyrightholders of a PHP addon might be
able to effectively revoke the Free Software community's ability to
rely on the licence for existing versions of the addon, by
insisting on strict compliance with paragraph 6, or by issuing a
statement `clarifying' their licence ?


II. Restrictions on the name `PHP'

Debian routinely modifies all the software that we distribute, and we
expect our downstreams to further modify it.

(Because we want the freedom to modify to be available not only to us,
but also to all of those downstreams, we have a practice of refusing
to submit our modifications for approval and declining to accept any
Debian-specific permissions.)

Paragraphs 3 and 4 can be read to mean that Debian should not be
distributing its modified version of PHP under the name `PHP'.

We have been informally assured by members of the PHP community that
this is not the intent and that the PHP project does not want us to
rename things.

Similar situations often arise in relation to trademarks. Our usual
approach in such cases has been to rely on the informal assurances,
and not seek any kind of formal trademark licence amendment.

However, we remain prepared to rename the software. If we receive a
formal legal request or threat from a trademark holder, or we hear of
our downstreams receiving such communications, we will rename the
software to avoid any potential infringement of the trademark. For
example, Mozilla insisted on prior written approval of patches, so our
version of Firefox is called Iceweasel. Our reactive rather than
proactive approach has served us and our downstreams very well.

Q4. Does the fact that the PHP licence conditions about the use of the
PHP name are contained in the actual copyright licence, rather than
in a separate trademark licence, significantly increase the risks
we would face if we had a disagreement with upstream about our
modifications (or our failure to seek approval) ?


III. Context

When answering these questions, please have regard to this context:

Firstly, as we say above, we are concerned not just about the risk to
contributors to and participants in Debian, but also about risks to
our downstreams. Our downstreams include derivative distros,
individual users, and also other contributors who may simply produce
and distribute further-modified versions of some package(s). As a
matter of principle, we don't want to expose our downstreams to risks
we judge unacceptable for ourselves.

Sadly we must consider in this context the fact that it does happen -
thankfully rarely - that an upstream takes offence to something Debian
does and attempts to revoke or renounce the licence or claim that the
licence forbids. It is important to us that we can still, under such
conditions, continue to distribute the software (perhaps under a
different name), since we may have come to rely on it.

However, in general we do not concern ourselves with the risk that
future upstream versions of a program will be insufficiently free. It
is enough that we and our downstreams have the relevant freedoms in
relation to the upstream versions we actually use. In extremis we
deal with unfavourable upstream licence changes by forking from the
last sufficiently free version.


Thanks,
Ian.
Francesco Poli
2014-08-01 14:13:57 UTC
Permalink
[...]
Post by Ian Jackson
We are concerned here with the PHP 3.0 Licence, which can be found
here: http://php.net/license/3_0.txt
Wait! This license version is already obsolete!

Please revise your draft in light of the current
PHP License, version 3.01:
http://php.net/license/3_01.txt
https://lists.debian.org/debian-legal/2005/11/msg00271.html

For the record, my own personal concerns about the PHP License are
described in
https://lists.debian.org/debian-legal/2005/11/msg00272.html


Thanks for your time!
--
http://www.inventati.org/frx/
fsck is a four letter word...
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Ian Jackson
2014-08-01 15:59:11 UTC
Permalink
Post by Francesco Poli
Wait! This license version is already obsolete!
Thanks for pointing that out.
Post by Francesco Poli
Please revise your draft in light of the current
http://php.net/license/3_01.txt
https://lists.debian.org/debian-legal/2005/11/msg00271.html
Done - see below.
Post by Francesco Poli
For the record, my own personal concerns about the PHP License are
described in
https://lists.debian.org/debian-legal/2005/11/msg00272.html
I hope I have dealt with these adequately in my draft below.

(Your point about the overreach of perhaps forbidding `php' in the
names of addons isn't a legal one AFAICT, so I haven't asked anything
about it in my draft. It doesn't appear that the ftpmasters agree
with your point.)



Draft question for SFLC:


Some members of the Debian project have some concerns about the PHP
licence. These worries are dismissed by other members and by relevant
upstreams. We would like some advice.

We are concerned here with the PHP 3.01 Licences, which can be
found here: http://php.net/license/3_01.txt

There are two concerns (I and II, below), which need to be read with
some context (III, below):


I. Requirement to perhaps-falsely acknowledge:

Paragraph 6 of the main licence text requires this notice:

"This product includes PHP software, freely available from
<http://www.php.net/software/>".

This is probably unproblematic for PHP itself. However, most PHP
addons are also distributed under the PHP licence. The worry is that
putting that statement in the copyright information for a PHP addon
package is might be making a false statement, since (i) the package
itself does not include PHP and (ii) the addon may not in fact be
available via that URL.

Counterarguments which may be relevant or have been put forward
include:

(a) A licensor who uses this licence obviously did not intend the
licencees to make a false statement, and the requirement in the
licence should be read down accordingly.

(b) The word `product' does not refer to a specific package but the to
the system as a whole, including PHP itself.

(c) PHP addon packages (at least those whose upstream versions are
available from www.php.net) should be regarded as `PHP software' for
the purposes of this statement. (But what if the addon later ceases
to be distributed from www.php.net, or was never so distributed?)

We have the following questions:

Q1. What is the best approach for Debian and its downstreams to take
to comply with this licence ? Should we always include the
statement as requested ?

Q2. If the answer to Q1 is to always include the statement, does
including this statement pose any ethical, legal or practical risk
to anyone in the Free Software community ? Is it fair to say that
the statement is or can be materially false or misleading ?

Q3. Does the answers to these questions depend on whether the addon is
currently, or was ever, distributed via
http://www.php.net/software/ ?


II. Restrictions on the name `PHP'

Debian routinely modifies all the software that we distribute, and we
expect our downstreams to further modify it.

(Because we want the freedom to modify to be available not only to us,
but also to all of those downstreams, we have a practice of refusing
to submit our modifications for approval and declining to accept any
Debian-specific permissions.)

Paragraphs 3 and 4 can be read to mean that Debian should not be
distributing its modified versions of PHP itself, and of PHP addons,
under the name `PHP'.

We have been informally assured by members of the PHP community that
this is not the intent and that the PHP project does not want us to
rename things.

Similar situations often arise in relation to trademarks. Our usual
approach in such cases has been to rely on the informal assurances,
and not seek any kind of formal trademark licence amendment.

However, we remain prepared to rename the software. If we receive a
formal legal request or threat from a trademark holder, or we hear of
our downstreams receiving such communications, we will rename the
software to avoid any potential infringement of the trademark. For
example, Mozilla insisted on prior written approval of patches, so our
version of Firefox is called Iceweasel. Our reactive rather than
proactive approach has served us and our downstreams very well.

Q4. Does the fact that the PHP licence conditions about the use of the
PHP name are contained in the actual copyright licence, rather than
in a separate trademark licence, significantly increase the risks
we would face if we had a disagreement with upstream about our
modifications (or our failure to seek approval) ?


III. Context

When answering these questions, please have regard to this context:

Firstly, as we say above, we are concerned not just about the risk to
contributors to and participants in Debian, but also about risks to
our downstreams. Our downstreams include derivative distros,
individual users, and also other contributors who may simply produce
and distribute further-modified versions of some package(s). As a
matter of principle, we don't want to expose our downstreams to risks
we judge unacceptable for ourselves.

Sadly we must consider in this context the fact that it does happen -
thankfully rarely - that an upstream takes offence to something Debian
does and attempts to revoke or renounce the licence or claim that the
licence forbids. It is important to us that we can still, under such
conditions, continue to distribute the software (perhaps under a
different name), since we may have come to rely on it.

However, in general we do not concern ourselves with the risk that
future upstream versions of a program will be insufficiently free. It
is enough that we and our downstreams have the relevant freedoms in
relation to the upstream versions we actually use. In extremis we
deal with unfavourable upstream licence changes by forking from the
last sufficiently free version.


Thanks,
Ian.
MJ Ray
2014-08-01 20:36:27 UTC
Permalink
Post by Ian Jackson
Similar situations often arise in relation to trademarks. Our usual
approach in such cases has been to rely on the informal assurances,
and not seek any kind of formal trademark licence amendment.
I thought we relied on the fact that trademark law isn't as brain dead as copyright laws and actually allows honest description, functional uses and other things that we do.

Firefox's renaming was more to do with the trademark licence being used to try to force in a few non free files and restrict downstream autonomy IIRC.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Charles Plessy
2014-08-01 23:10:49 UTC
Permalink
Post by Ian Jackson
Some members of the Debian project have some concerns about the PHP
licence. These worries are dismissed by other members and by relevant
upstreams. We would like some advice.
Hello Ian and everybody,

I think that it is important that a few of the ‘some members’ would identify
themselves in support for that request, and explain what they would do if the
worries expressed below turned out to be true.

Among the Debian Developers, some have more stakes in the packages than others.
Members of the FTP team may remove the packages or ask them to move to
non-free; members of the release team can remove them from Stable and Testing;
members from the security team can refuse to support the packages; the
maintainers of the packages can orphan or abandon them. Lastly, any Debian
Developer can start a General Resolution.

If the only support for contacting lawyers comes from Developers who have the
least stakes in the question (GR only), then we should really consider if the
work that we are about to ask to the lawyers will be wasted in the trash bin
instead of being seriously considered.

Here are two other coments on the text itself.
Post by Ian Jackson
Q4. Does the fact that the PHP licence conditions about the use of the
PHP name are contained in the actual copyright licence, rather than
in a separate trademark licence, significantly increase the risks
we would face if we had a disagreement with upstream about our
modifications (or our failure to seek approval) ?
Note that PHP does not hold a trademark on the PHP name and therefore
can not grant a trademark license.
Post by Ian Jackson
Sadly we must consider in this context the fact that it does happen -
thankfully rarely - that an upstream takes offence to something Debian
does and attempts to revoke or renounce the licence or claim that the
licence forbids. It is important to us that we can still, under such
conditions, continue to distribute the software (perhaps under a
different name), since we may have come to rely on it.
It is important to note that clarifications on the PHP license have already
been given by PHP developers. The question is then if they are free to revert
their clarifications and use a new interpretation of their license to force
Debian to stop distributing or modifying PHP and its modules.

Have a nice week-end,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-legal-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@falafel.plessy.net
Charles Plessy
2014-08-01 23:57:12 UTC
Permalink
Post by Charles Plessy
I think that it is important that a few of the ‘some members’ would identify
themselves in support for that request, and explain what they would do if the
worries expressed below turned out to be true.
Sorry for the extra mail; I just would like to clarify that by “Developers in
support”, I mean: “Developers who think that the PHP license may be
problematic”, not “Developers who think that calling lawyers will be an
efficient mean to resolve the disagreements”.

Cheers,
--
Charles
--
To UNSUBSCRIBE, email to debian-legal-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@falafel.plessy.net
Ian Jackson
2014-08-04 12:11:25 UTC
Permalink
Post by Charles Plessy
I think that it is important that a few of the ‘some members’ would
identify themselves in support for that request, and explain what
they would do if the worries expressed below turned out to be true.
At the moment people are playing bug tag, and packages are being
sometimes rejected or sometimes prevented from migrating to testing.

If the worries turn out to be justified then we should apply that same
policy to all of the affected packages - but in fact, I would hope
that given an unequivocal statement from actual laywers it would be
easy to persuade the PHP developers to change the licence.
Post by Charles Plessy
If the only support for contacting lawyers comes from Developers who
have the least stakes in the question (GR only), then we should
really consider if the work that we are about to ask to the lawyers
will be wasted in the trash bin instead of being seriously
considered.
If the worries turn out to be unjustified then I hope that the people
who have been complaining would stop doing so.
Post by Charles Plessy
Here are two other coments on the text itself.
Post by Ian Jackson
Q4. Does the fact that the PHP licence conditions about the use of the
PHP name are contained in the actual copyright licence, rather than
in a separate trademark licence, significantly increase the risks
we would face if we had a disagreement with upstream about our
modifications (or our failure to seek approval) ?
Note that PHP does not hold a trademark on the PHP name and therefore
can not grant a trademark license.
I will mention this.
Post by Charles Plessy
It is important to note that clarifications on the PHP license have
already been given by PHP developers. The question is then if they
are free to revert their clarifications and use a new interpretation
of their license to force Debian to stop distributing or modifying
PHP and its modules.
This clarification is not sufficient because in the general case the
copyright to a PHP addons is not held by the PHP developers and so the
actual copyrightholders of the addon haven't issued the clarification.
And future joint copyrightholders of PHP itself may not have
participated in the clarification.

If you disagree, perhaps you'd like to suggest a workable process to
distinguish addons for which we can rely on the clarification, from
ones where we can't.

Personally I think that is a daft way to carry on and we (the Free
Software community as a whole including Debian and the PHP community)
should either dismiss these concerns (if they are unfounded), or fix
them properly (if they are well-founded).

Thanks,
Ian.
Francesco Poli
2014-08-02 16:28:41 UTC
Permalink
Post by Ian Jackson
Post by Francesco Poli
Wait! This license version is already obsolete!
Thanks for pointing that out.
You're welcome!
Post by Ian Jackson
Post by Francesco Poli
Please revise your draft in light of the current
http://php.net/license/3_01.txt
https://lists.debian.org/debian-legal/2005/11/msg00271.html
Done - see below.
Good, many thanks for doing so.
Post by Ian Jackson
Post by Francesco Poli
For the record, my own personal concerns about the PHP License are
described in
https://lists.debian.org/debian-legal/2005/11/msg00272.html
I hope I have dealt with these adequately in my draft below.
Please see my comments below.
Post by Ian Jackson
(Your point about the overreach of perhaps forbidding `php' in the
names of addons isn't a legal one AFAICT, so I haven't asked anything
about it in my draft. It doesn't appear that the ftpmasters agree
with your point.)
You're right that the FTP Masters seem to disagree with me on the
non-freeness of PHP itself: I think that clause 4 of the PHP License
version 3.01 makes PHP non-free, while FTP Masters seem to have issues
with the PHP License only when it is applied to software not provided
by the PHP Group.

I think you are also right that legal advice would not help to clarify
this specific freeness point.
[...]
Post by Ian Jackson
"This product includes PHP software, freely available from
<http://www.php.net/software/>".
I would also add some mention of the final disclaimers (the text in
capital letters and the text under the separation lines in the
license), which also risk to become false or irrilevant for software
not written by (or on behalf of) the PHP Group.
Post by Ian Jackson
This is probably unproblematic for PHP itself. However, most PHP
addons are also distributed under the PHP licence. The worry is that
putting that statement in the copyright information for a PHP addon
package is might be making a false statement, since (i) the package
Probably s/is might/might/
Post by Ian Jackson
itself does not include PHP and (ii) the addon may not in fact be
available via that URL.
[...]
--
http://www.inventati.org/frx/
fsck is a four letter word...
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Ian Jackson
2014-08-04 12:22:31 UTC
Permalink
Post by Francesco Poli
Post by Ben Finney
"This product includes PHP software, freely available from
<http://www.php.net/software/>".
I would also add some mention of the final disclaimers (the text in
capital letters and the text under the separation lines in the
license), which also risk to become false or irrilevant for software
not written by (or on behalf of) the PHP Group.
I have added a new section and a new question about this.
Post by Francesco Poli
Post by Ben Finney
This is probably unproblematic for PHP itself. However, most PHP
addons are also distributed under the PHP licence. The worry is that
putting that statement in the copyright information for a PHP addon
package is might be making a false statement, since (i) the package
Probably s/is might/might/
Fixed.

Thanks,
Ian.
Riley Baird
2014-08-01 21:52:28 UTC
Permalink
Last minute concerns:

The warranty disclaimer states that the software is provided by the PHP
development team. What if it isn't? Do people that are not members of
the PHP development team have the right to make that claim on their behalf?

Similarly, the license includes the phrase "This software consists of
voluntary contributions made by many individuals on behalf of the PHP
Group." (However, this may already be covered by the "false statements"
clause)
Thorsten Glaser
2014-07-30 14:38:58 UTC
Permalink
Post by Lucas Nussbaum
However, based on my own (possibly limited) understanding of the
issue[1], this is case of a license (the PHP License) with sub-optimal
wording that is misused by third parties, as it was initially designed
for PHP itself, and is used for random software written in PHP.
That, too. But AIUI that licence also forbids us from shipping
a modified version of PHP without rebranding (like Firefox(tm)).

bye,
//mirabilos
Charles Plessy
2014-07-30 23:03:00 UTC
Permalink
Post by Thorsten Glaser
That, too. But AIUI that licence also forbids us from shipping
a modified version of PHP without rebranding (like Firefox(tm)).
I think that we are ridiculing ourselves by ignoring the arguments that have
been given to us by the PHP developers in the past.

See, we are getting famous in Wikipedia:

https://en.wikipedia.org/wiki/PHP_License#Debian_packaging_controversy

Debian maintainers have had a long-standing discussion (since at least 2005)
about the validity of the PHP license.[4] Expressed concerns include that the
license "contains statements about the software it covers that are specific to
distributing PHP itself", which, for other software than PHP itself therefore
would be "false statements".

I think that the situation is different:

- It has been proposed by a developer to remove PHP modules licensed under the
PHP license, in application of a policy that had been neglected for years.
This proposition was eventually represented by release-critical bugs.

- For some PHP modules, the bugs have been closed, and there was no further
reaction.

- In the meantime the usual vocal people sending the majority of emails on our
mailing lists are giving the impression that removing PHP modules is a position
of Debian as a whole, while it is definitely not.

This drama can be ended by closing the remaining bugs and going back to work.
This has been done for packages that some people care most, like php-memcached,
and could be done for other packages. When things have cooled down, it can
be proposed to correct the REJECT-FAQ according to current practice of accepting
PHP-licensed code.

Back to the question of rebranding, the PHP developers have already explained
that because PHP is a three-letter word, they are not in a position to
protect their name with a trademark. Therefore, they do it with a license.

We can not take Mate and distribute it as “Gnome Plus”. We can not take a fork
of PHP and call it “BetterPhp”. People can not take a Debian CD, add non-free
software, and sell it as “Debian Enhanced”. We and other protect our names,
and PHP does it too. I do not see a problem.

Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-project-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@falafel.plessy.net
MJ Ray
2014-08-02 07:28:12 UTC
Permalink
Post by Charles Plessy
Back to the question of rebranding, the PHP developers have already explained
that because PHP is a three-letter word, they are not in a position to
protect their name with a trademark. Therefore, they do it with a license.
We can not take Mate and distribute it as “Gnome Plus”. We can not take a fork
of PHP and call it “BetterPhp”. People can not take a Debian CD, add non-free
software, and sell it as “Debian Enhanced”. We and other protect our names,
and PHP does it too. I do not see a problem.
There are two problems with trying to use a copyright licence to do the job of a trademark. It's like trying to use a gun to cut your steak.

One, it doesn't affect people who write something without using your code. We could clean- room write the perfect hamster punisher and then distribute it as PHP, possibly harming their reputation, but their licence would do nothing to stop us. This is not a worry for Debian but it does show why the licence term is not much like a trademark.

Secondly, unless it says otherwise, a naming restriction in a copyright licence doesn't permit honest source attribution and all the other nominative and fair uses that a trademark would. This is more of a problem for Debian.

Isn't part of the reason why the name PHP cannot be trademarked that restricting use of such a simple name is obnoxious?

There are many ways this could be solved, but the ostrich approach of closing the bugs without fixing them and hiding this from users must be one of the worst. Please support another approach.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Ian Jackson
2014-08-04 12:26:11 UTC
Permalink
(-project dropped from the CC)
Post by MJ Ray
Secondly, unless it says otherwise, a naming restriction in a
copyright licence doesn't permit honest source attribution and all
the other nominative and fair uses that a trademark would. This is
more of a problem for Debian.
Can you please confirm that the question I put in my draft questions
for SFLC, on this subject, addresses this point ? If I haven't
fully captured your understanding of the problem then my draft needs
to be updated.

(I'm about to post a v3 but it's essentially identical on this point.)
Post by MJ Ray
There are many ways this could be solved, but the ostrich approach
of closing the bugs without fixing them and hiding this from users
must be one of the worst. Please support another approach.
I think you're being rather rude here. It's not the case that people
are deliberately `hiding' these `bugs'. Rather, they disagree whether
the problem is real or imaginary.

Ian.
MJ Ray
2014-08-04 21:14:46 UTC
Permalink
Post by Ian Jackson
(-project dropped from the CC)
Post by MJ Ray
Secondly, unless it says otherwise, a naming restriction in a
copyright licence doesn't permit honest source attribution and all
the other nominative and fair uses that a trademark would. This is
more of a problem for Debian.
Can you please confirm that the question I put in my draft questions
for SFLC, on this subject, addresses this point ? If I haven't
fully captured your understanding of the problem then my draft needs
to be updated.
I'm not sure it does. The question to me should be more like "does putting a name restriction in the copyright licence rather than using a trademark licence mean we lose any ability to package this software under its own name and if so, how?" but worded more slickly like you do.

At best, the earlier paragraph suggesting we rely on assurances from trademark holders rather than usual rights in law, just for packaging, seems beside the point. At worst, it could mislead about the question.

I take your point about rudeness. I shouldn't fight fire with fire. Sorry.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Ian Jackson
2014-08-05 10:54:40 UTC
Permalink
Post by MJ Ray
Post by Ian Jackson
Can you please confirm that the question I put in my draft questions
for SFLC, on this subject, addresses this point ? If I haven't
fully captured your understanding of the problem then my draft needs
to be updated.
I'm not sure it does. The question to me should be more like "does
putting a name restriction in the copyright licence rather than
using a trademark licence mean we lose any ability to package this
software under its own name and if so, how?" but worded more slickly
like you do.
I think that's exactly what my question (Q5) is asking:

Q5. Does the fact that the PHP licence conditions about the use of the
PHP name are contained in the actual copyright licence, rather than
in a separate trademark licence, significantly increase the risks
we would face if we had a disagreement with upstream about our
modifications (or our failure to seek approval) ?
Post by MJ Ray
At best, the earlier paragraph suggesting we rely on assurances from
trademark holders rather than usual rights in law, just for
packaging, seems beside the point. At worst, it could mislead about
the question.
I think it is an important point. Many of the projects whose software
we use have trademarks. Those trademarks often come with a
restrictive trademark licence which says that we have to submit
changes for approval, or some other unacceptable conditions.

We often ignore those trademarks because the upstream community
doesn't appear to actually mean what the project's laywers have
written. We can afford to do this because, if we are wrong, the
result is that we must rename the software. Renaming it is annoying
but it doesn't leave us high and dry.

So the real concern about the name restriction being in the copyright
licence is not that it might be used, at some point in the future, to
force us to rename. We already tolerate exactly that situation with
trademarks.

It is also not that we might be in technical break of the condition
(eg, to seek written approval) right now. We already take exactly
that risk with trademarks.

The concern is this: should upstream have a problem with some of our
changes, or our failure to formally get approval, they may seek to
apply legal pressure based on the name restriction clause. In that
case if it were a trademark problem we would rename the software and
carry on. We need to know that this is a sufficient response when the
name restriction is in a copyright clause.
Post by MJ Ray
I'm not sure it does. The question to me should be more like "does
putting a name restriction in the copyright licence rather than
using a trademark licence mean we lose any ability to package this
software under its own name and if so, how?" but worded more slickly
like you do.
The question is not about some kind of abstract `ability', as if law
was always hard-edged and clear.

The question is our _practical_ ability. What can we (by which I
include Debian and all of our downstreams) do without incurring
significant risk ?

If you disagree with me on this point then you probably disagree with
the Debian project's existing approach to troublesome trademarks. For
example, when there is a trademark whose licence requires us to seek
approval, but where the trademark holder and their community don't
appear to want to enforce this rule.

If you think that in that situation we should decline to package the
software, or rename it right away, then that is a coherent position.

But that is not our current practice. If you want to change that you
will need a GR, I think.


But perhaps I have misunderstood. If my reply doesn't seem to make
sense perhaps you would like to suggest an alternative wording for
this part of the question email.


Thanks,
Ian.

Loading...