Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#903999: RFC about DFSG-freeness of PHP license [Re: Bug#903999: ITP: php-doc -- Documentation for PHP]

0 views
Skip to first unread message

Nicholas D Steeves

unread,
Jan 8, 2023, 5:40:04 PM1/8/23
to
Hi Athos,

Thank you for working on this RFP, and for doing all the work involved
with reintroduction the package.

I'm CCing the debian-legal team who I hope will be able to help with
the stylesheet question and related issues; I've given it my
best-effort, but would appreciate someone else's perspective

My reply, in context, follow inline:

Athos Ribeiro <athos....@canonical.com> writes:

> On Wed, Sep 28, 2022 at 08:11:14AM +0800, Paul Wise wrote:
>>On Mon, 2022-09-26 at 16:23 -0300, Athos Ribeiro wrote:
>>
>>> As mentioned in the original report (RFP), this package was
>>> originally removed from the archive due to Bug #821695, when it was
>>> not updated during the PHP 7 transition.
>>
>>If you weren't already aware, please note the extra steps needed when
>>reintroducing packages that were removed from Debian (e.g. bug reopen):
>>
>>https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs
>
> Hi Paul, Thanks for the pointers.
>
> While I am working on packaging details, I still want to make sure it is
> OK to re-introduce the package due to the PHP-3.0 issues I pointed
> before.
>

Do you mean the PHP-3.0[-only] issue:

https://lintian.debian.org/tags/license-problem-php-license

which appears to be the same as the PHP-3.1[-or-greater?] issue?

https://ftp-master.debian.org/php-license.html

Is the problem you're referring appears to be that this license places
limitations on the use of the term "PHP"? Were this limitation on
endeavour, it would be non-DFSG, but honestly I'm a bit surprised that
php8.1 is in Debian main...eg: that it's DFSG-free. I'm also not sure
why the Apache license isn't problematic for this same reason.

At any rate, as far as I can tell this is something for the ftpmasters
to worry about, so long as you follow the instructions at the above two
links as well as consulting the PHP package for examples. Ie this means
is that the debian/ subdir must have a more permissive license than the
PHP one (eg: Expat).

> On top of that, I needed to change one of the build time internal
> dependencies so we wouldn't end up with (hundreds of) broken links. This
> led to the need of clarification on
> https://github.com/php/web-php/issues/711 by the upstream project.
> If the stylesheets provided are indeed proprietary, I will need to write
> our own.
>

Oh my! Yes, after reading that issue (quoted below):

>> The following files are referred to and fetched from phd when
>> building with the PHP package (in
>> phpdotnet/phd/Package/PHP/ChunkedXHTML.php):
>>
>> https://www.php.net/styles/theme-base.css (styles/theme-base.css)
>> https://www.php.net/styles/theme-medium.css (styles/theme-medium.css)
>>

The copyright text on the PHP website is

Except as otherwise indicated elsewhere on this Site, you are free
to view, download and print the documents and information available
on this Site subject to the following conditions:

* You may not remove any copyright or other proprietary notices contained
in the documents and information on this Site.

* The rights granted to you constitute a license and not a
transfer of title.

* The rights specified above to view, download and print the
documents and information available on this Site are not
applicable to the graphical elements, design or layout of this
Site. These elements of the Site are protected by trade dress
and other laws and may not be copied or imitated in whole or in
part.
(https://www.php.net/copyright)

To me it sounds like 1. No rights to redistribute the website (in whole
or in part) are granted, except where the part is a separate project
with its own license (php-docs). 2. No one has a license to view,
download, or print the stylesheets.

Were the second claim to be maintained, a consequence of this would
seems to be that only the copyright holder[s] could build the
unpatched documentation without committing copyright infringement.

>> While the phd project is shipped under MIT/BSD licenses, web-php and
>> its files
>> have no other license notices other than the notice on copyright.php
>> which says that the design and layout of php.net is protected by
>> trade dress and should not be copied nor imitated. Does this apply to
>> both files above? In special, styles/theme-base.css seems to be
>> derived from bootstrap, and the apache license disclaimer was
>> kept. Is it still ditributed through the apache license then?

Good point; however, the Apache license allows relicensing (so long as
various conditions are met). Were the PHP project to not do this, they
would be in breach of the Apaache license, and we still wouldn't be able
to redistribute.

Given the copyright notice published to the PHP website, I think you're
right about how the only workaround is to replace their stylesheets!
Please note that network access is blocked during the builds of all
Debian packages (packages in non-free are not part of Debian).

I also wonder if the future php-docs package could download the
stylesheets and build the docs on the end user's machine as part of
package configuration (analogous to how ttf-mscorefonts-installer
works); however, I'm not sure if that's legally permissible in this
case.

Please keep me in CC.

Regards,
Nicholas

P.S. I am not a lawyer and this is not legal advice.
signature.asc

Athos Ribeiro

unread,
Jan 29, 2023, 11:00:04 AM1/29/23
to
On Sun, Jan 08, 2023 at 05:35:09PM -0500, Nicholas D Steeves wrote:
>Hi Athos,

Hi Nicholas,

Thanks for the reply! Comments follow inline.
This seems to be the issue here, unless it is agreed that php-doc is
indeed part of PHP itself. In this case, we should extend lintian's
lib/Lintian/Check/Cruft.pm php_source_whitelist subroutine to also
account for php-doc.

As a side note, it seems that we should also update the text in
https://lintian.debian.org/tags/license-problem-php-license to account
for the version 3.01 of the license, which also seem to apply here.

>At any rate, as far as I can tell this is something for the ftpmasters
>to worry about, so long as you follow the instructions at the above two
>links as well as consulting the PHP package for examples. Ie this means
>is that the debian/ subdir must have a more permissive license than the
>PHP one (eg: Expat).

It is currently licensed as Expat:
https://salsa.debian.org/athos/php-doc/-/blob/debian/main/debian/copyright#L103
This is my understanding of the whole situation. The current workaround
I came up with for now is to replace those stylesheets with the Debian
maintainers guide one:
https://salsa.debian.org/athos/php-doc/-/commit/c5c2f6a96a5fd89b72da89287d53e09f4b191043

This still needs improvements, but it should work for a first version of
the package AFAICT.

>>> While the phd project is shipped under MIT/BSD licenses, web-php and
>>> its files
>>> have no other license notices other than the notice on copyright.php
>>> which says that the design and layout of php.net is protected by
>>> trade dress and should not be copied nor imitated. Does this apply to
>>> both files above? In special, styles/theme-base.css seems to be
>>> derived from bootstrap, and the apache license disclaimer was
>>> kept. Is it still ditributed through the apache license then?
>
>Good point; however, the Apache license allows relicensing (so long as
>various conditions are met). Were the PHP project to not do this, they
>would be in breach of the Apaache license, and we still wouldn't be able
>to redistribute.
>
>Given the copyright notice published to the PHP website, I think you're
>right about how the only workaround is to replace their stylesheets!
>Please note that network access is blocked during the builds of all
>Debian packages (packages in non-free are not part of Debian).
>
>I also wonder if the future php-docs package could download the
>stylesheets and build the docs on the end user's machine as part of
>package configuration (analogous to how ttf-mscorefonts-installer
>works); however, I'm not sure if that's legally permissible in this
>case.

This would be a nice alternative, but in this case, wouldn't we be
forcing users into breaching the PHP license? Or would this only apply
for re-distribution?

This approach wouldn't be needed if we agree to use the maint-guide
stylesheet for now anyway.

Once again, thanks for the reply and the thoughtful input :)

>Please keep me in CC.
>
>Regards,
>Nicholas
>
>P.S. I am not a lawyer and this is not legal advice.

--
Athos Ribeiro

Sergio Durigan Junior

unread,
Sep 26, 2023, 4:40:04 PM9/26/23
to
Hello,

Disclaimer: I am not a lawyer and this is not legal advice.

I talked extensively to Athos during DebConf and, after looking at the
multiple licenses and nuances involved in this problem I believe:

1) Athos followed precisely the instructions from ftp-masters
(https://ftp-master.debian.org/php-license.html). He also followed the
good practices pointed by Lintian.

2) IMO, it is possible to argue that php-doc is actually part of PHP
itself, judging by the fact that the project is hosted under the PHP
umbrella on the Microsoft Github repository. If that's the case, then I
agree with Athos that we should extend the Lintian warning.

3) Ultimately, it is the ftp-master's job to determine whether php-doc's
license is suitable for Debian or not. I don't think it's
necessary/beneficial to extend this discussion here.

Having said that, I will review and sponsor the package for Athos.

Thanks,

--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/
signature.asc
0 new messages