Bunling differently-licensed code for unit tests

[Mathieu Bridon]

Hi,

I did the review of php-bartlett-PHP-CompatInfo for Remi (CCed, but he
is on the list anyway), and a licensing issue arose. Remi removed the
files from the package so that we wouldn't delay the review, but now
comes the time to fix the issue.

The situation is as follows:
1. PHP_CompatInfo is BSD-licensed.
2. In its unit tests it has a copy of a file from the PHP source code,
which is PHP-licensed.
3. This file is not used at run time by PHP_CompatInfo. It is not even
run during the unit tests, only parsed, as it presents an interesting
reproducer for a bug that had been reported to PHP_CompatInfo:
    http://pear.php.net/bugs/bug.php?id=3657
(it is actually not even usable at all outside of the rest of the PHP
tree)

As such, what would be the license of the php-bartlett-PHP-CompatInfo
package if Remi adds this file back:
 - "BSD and PHP"?
 - or simply "BSD", because parsing a file as a regression
   unit test is not considered the same way as running code?

Also, I am personally a bit worried about those two paragraphs in the
PHP license:
  3. The name "PHP" must not be used to endorse or promote products
     derived from this software without prior written permission. For
     written permission, please contact [e-mail].

4. Products derived from this software may not be called "PHP", nor
     may "PHP" appear in their name, without prior written permission
     from [e-mail].  You may indicate that your software works in
     conjunction with PHP by saying "Foo for PHP" instead of calling
     it "PHP Foo" or "phpfoo"

Is PHP_CompatInfo considered a derived work of PHP because it includes a
file from the PHP source code in its unit tests? Should the upstream
author be concerned about renaming his module, or asking for permission
to the PHP group? If he gets a written permission, should it (most
likely the email with full headers) be included in Remi's package?

Or are we making a mountain out of a molehill and there is absolutely
nothing to worry about with this module?

Thanks in advance,

PS: I voluntarily left aside the fact that the package is actually "BSD
and MIT"-licensed because it bundles a copy of jQuery. I don't think it
is relevant to this specific issue though, and it would only have made
it more complex for me to explain it, which is why I decided it to leave
it to a post-scriptum.

[Tom Callaway]

On 09/23/2011 03:07 AM, Mathieu Bridon wrote:
> Is PHP_CompatInfo considered a derived work of PHP because it includes a
> file from the PHP source code in its unit tests? Should the upstream
> author be concerned about renaming his module, or asking for permission
> to the PHP group? If he gets a written permission, should it (most
> likely the email with full headers) be included in Remi's package?

Keeping in mind that I'm:

A) Not the copyright holder for either PHP or PHP_CompatInfo
B) Not a lawyer

I would have to say that the core of PHP_CompatInfo is not considered a
derived work of PHP because it includes a file from the PHP source code
in its unit tests. Now, depending on how that file is included, it is
hypothetically possible that the _unit tests_ could be considered a
derived work of PHP, so it probably would not be a terrible idea for the
upstream copyright holder of PHP_CompatInfo to inform upstream of this
use, the concern around the name overlap, and confirm that everything is
acceptable from their perspective.

If upstream receives written permission, they should simply indicate
that they have done so in some form. Could be as simple as a comment in
the README or as complicated as a copy of the email with full headers.

Either way, we should defer this issue to the upstream copyright holder
for resolution.

~tom

==
Fedora Project