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.
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.ribe...@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.
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
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.
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
