
Debian and the PHP license - jpswade
http://lwn.net/Articles/604630/
======
VLM
TLDR is the license is specifically intentionally designed to only be applied
to certain named products from exactly one named group of coders, but random
internet people are applying it to random code written by random people.

A bad HN automobile analogy would be if Ford had a clickwrap license on all
new cars that summarized to "This Focus model car is provided by Ford, Ford
wrote this Focus model car UI, Ford distributes this specific Ford Focus
model, and you can officially do the FOSS thing with it, including Ford will
not provide any guarantees". (note I'm guessing this isn't the real license on
the ford focus UI, LOL, just a made up example)

And then GM sells a car, lets say, the Buick LaCrosse, and for reasons of
apparent insanity slaps the Ford license on their car.

Next people are all WTF because GM released something under a license claiming
that Ford owns it, wrote it, distributes it, and Ford won't provide guarantees
(implying, I guess, that GM will).

Can I legally resell a GM car that claims its owned by Ford? So who owns this
"GM" car, and if the license slapped on it is literally nonsense, is it even
legally licensed software? So you're trying to sell a LaCross under the Focus
license, are you claiming this thing is actually a Focus or that GM is a
division of Ford, or Ford won't provide warranty coverage so I guess its
implied GM will. If the license claims this is owned by Ford, but I bought it
from a GM dealer, who's permission do I need to ask to relicense if needed? If
I intentionally violate the license, can GM sue me if in writing they claim
Ford owns this software, not GM? Or if Ford wanted, just to be jerks, could
they sue me for using this GM software, because after all the license says
Ford owns it. If the software crashes and kills people is a license falsely
claiming Ford owns it a legal liability for GM for defamation (Ford owns it,
its their fault not ours)?

~~~
thefreeman
I don't think that is really accurate. I think it is closer to:

\- Ford makes car, licenses under Ford license.

\- 3rd parties make add on products for the Ford automobile, like an updated
radio, and say that it is licensed under the same license as the original car.

~~~
icebraining
It's not just a Ford license, it's a Ford Focus license. It's specific to the
car, that's why the addon maker shouldn't use it for its radio.

~~~
thefreeman
True, and I am not trying to say the extension authors are correctly using the
license. I just thought that the OP's analogy would be more fitting if someone
like ruby decided to use the PHP license.

------
davidw
My own small contribution to a Debian Licensing Hassle:

[http://lwn.net/1998/0611/ircii.html](http://lwn.net/1998/0611/ircii.html)

I cold-called one of those guys and he was kind of amused by the whole thing.
It was not much fun though.

------
ecaron
Another conversation along the similar vein of "Debian putting its foot down
about a license" is Firefox (see
[http://en.wikipedia.org/wiki/Mozilla_Corporation_software_re...](http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project))

~~~
JohnTHaller
Mozilla doesn't permit 3rd parties to make unapproved changes to their
software and continue using their trademarks. It's in their trademark policy.
Debian has a similar policy with respect to their trademarks. So, Debian
created funnily named alternatives based on the code. All that made sense.
What didn't make sense was all the people whining about Mozilla's policies and
unironically complaining about how it restricted the Debian devs.

~~~
dspillett
The odd thing with that is that the problem became apparent, people discussed
it, Mozilla didn't want to (or couldn't for some, presumably legal, reason)
change policy, neither did Debian, sometime suggested the name change thing,
both parties agreed that this was compatible with their policies, and so it
happened. There was no drama between Firefox and Debian: just a problem, a
discussion, and a solution.

The way some people presented it as a pitched battle between the Firefox and
Debian teams is silly. Both were protecting their standing in some way, both
appreciated the other's position, and a solution was found that causes no
problems for either of them (aside from a small amount of user training along
the lines of "yeah, it is Firefox under a different name").

~~~
lambda
It's good that Google learned from this problem, and built a solution into
their naming when releasing Chrome; the open source project is named Chromium,
and is what distro versions can be named, and the official build from Google
is named Chrome.

It would be nice if Mozilla would follow suit, and come up with an official
name for the open source project and community builds which is distinct from
their official branded builds. Right now Debian uses "IceWeasel", GNU uses
"IceCat", and other distros would have to come up with their own name if they
made changes that were incompatible with Mozilla's trademark policy.

On the other hand, in pretty much every repository, you find "Chromium", but
if you instead download straight from Google you get "Chrome".

~~~
chimeracoder
Chromium and Chrome differ in a number of ways beyond the name and trademark,
though.

Iceweasel is literally just Firefox packaged for Debian, except with a
different name and icon. I don't think there is any functional difference
(beyond the normal distro-specific packaging that every distro does).

Chromium lacks a number of features that Chrome has, because Chrome comes
bundled with a bunch of proprietary components that will never be distributed
with Chromium.

A basic example is that Chromium cannot (without a patch) display PDFs in-
browser, the way Chrome can. Chromium also cannot support Chromecast, or any
of the many other Chrome-specific features, of which there are many[0]

[0] [https://i.imgur.com/AIxYzl9.jpg](https://i.imgur.com/AIxYzl9.jpg)
(screenshot is from Firefox, but it illustrates how much Google focuses on
Chrome-specific functionality.)

~~~
lambda

      Iceweasel is literally just Firefox packaged for Debian, 
      except with a different name and icon.
    

If you read this bug report[1], it's really about more than just a "different
name and icon." If they used the official name and icon, they would have
needed to have every patch be reviewed by Mozilla, which has serious problems
for urgent security patches. And in that discussion, Mozilla voiced concern
about several of Debian's patches.

It looks like there has been some effort to do what I've described, come up
with a generic default name for Firefox builds that can be used as a default,
unbranded version[2] rather than requiring every distro that doesn't want to
or can't comply with Mozilla's trademark policy have to do it on their own,
but the effort appears to have stalled.

    
    
      Chromium lacks a number of features that Chrome has,
      because Chrome comes bundled with a bunch of proprietary
      components that will never be distributed with Chromium.
    

Sure, I'm not saying that the situations are exactly analogous, just that
Chromium has managed to much better avoid the kind of trademark issues with
distros that caused so much trouble for Firefox and Debian. On the other hand,
as pointed out elsewhere in the thread, it appears that there is no official
Chromium trademark policy (at least easily discoverable), but it seems that
most distros have been able to use the name without complaint from Google.

[1]: [https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=354622](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=354622) [2]:
[https://bugzilla.mozilla.org/show_bug.cgi?id=682414](https://bugzilla.mozilla.org/show_bug.cgi?id=682414)

------
jessaustin
Matthias Urlichs wins the thread:

" _I 'd be for this_ [removing offending PHP modules] _in a heartbeat if it
would make people switch to a saner programming language, but that 's wishful
thinking._"

~~~
eitland
Hehe, anytime, just give us a language with the same features and the same ide
support etc and I'll happily let you bring along your improved standard
library, nicer syntax etc.

I don't think most developers would miss the craziness, I don't think the
features are tied to the craziness of the language and I'm sure a lot of us
would change as soon as it became production ready (if not earlier.)

(Hoping for Hack to be a step in the rigth direction.)

------
jpswade
From time to time people raise concerns of using PEAR packages licensed under
the PHP license in GPL'ed code. In a discussion about this topic, the creator
of PHP, Rasmus Lerdorf, issued the following statement:

It all comes down to semantics of what linking means. The PHP license is
pretty much identical to the Apache license and you could indeed make a case
for not allowing any GPL'ed software to be "linked to" from Apache either.

See
[http://www.apache.org/licenses/LICENSE-1.1](http://www.apache.org/licenses/LICENSE-1.1).

The PHP license was chosen to match the Apache license because Apache and PHP
are tied so closely to each other.

This hair splitting over linking, derivation and aggregation has been going on
since the beginning of time. My stance is that you can indeed ship PHP
licensed PEAR components on the same cd or in the same tarball as GPL'ed code
because I see it as an aggregate work. This changes if you take PEAR code,
modify it and copy-paste it directly into your own work. Then it moves from
aggregate to derived. But the intent of the PEAR components is to be used in
aggregate form. The PHP license allows you to use it in derived form as well,
of course, but then you should be choosing a license other than the GPL for
the derived work.

The FSF has a FAQ on aggregation here:
[http://www.fsf.org/licensing/licenses/gpl-
faq.html#MereAggre...](http://www.fsf.org/licensing/licenses/gpl-
faq.html#MereAggregation)

That text is heavily biased towards compiled software and they talk about
executables and memory spaces which don't really apply in this case. If you
don't consider using a PEAR component as aggregation then it logically follows
that you also cannot have Apache call your code so you will have to stipulate
that nobody can use your code from Apache. I think this is an extreme
interpretation that pretty much nobody out there shares.

In short, I don't see an issue here. Move along.

For PECL extensions that are linked into PHP, the license must be compatible
with the PHP license. That means you can not GPL a PECL extension or you would
be violating the GPL. Note also that if you write an extension that links
against a GPL'ed library you will be violating the GPL. If you need to link
against a GPL'ed library, get permission from the author of the library to use
the library under a compatible license.

The license of any PEAR/PECL package can be found in the head of all source
code files, inside the <license> tag of the package description file
(package.xml) and also on the package homepage.

~~~
dethstar
But this isn't about linking issues. This is about distribution issues.

------
chris_wot
What is the contradictory part of the license? And... What's the point if a
license that contradicts itself? How on earth do they expect to enforce their
conditions?

It's things like this that make me think "what did we do to deserve PHP?"

~~~
TallGuyShort
It's not that the license is self-contradictory, it's that the license text
(as written here:
[http://php.net/license/3_01.txt](http://php.net/license/3_01.txt)) implies
that the software is distributed only by the PHP Group, and is therefore not
usable without modification by anyone outside the PHP Group. The solution is
simple: modify the text of your project's license to have similar clauses to
the PHP license, but not mention the PHP Group, OR re-license your software
under the BSD license or another, similar license.

~~~
icebraining
_The solution is simple: modify the text of your project 's license to have
similar clauses to the PHP license, but not mention the PHP Group_

That's not so simple; as a work produced by someone, a legal document may be
subject to copyright. So you might need a _license to the license_ to modify
and reuse it :)

[http://www.adamsdrafting.com/the-contract-drafter-as-
copyrig...](http://www.adamsdrafting.com/the-contract-drafter-as-copyright-
violator/)

~~~
TheLoneWolfling
Hmm... Is it possible to "self-host" a license? That is, is it possible to
have a license licensed under itself?

~~~
icebraining
I don't know; and I'm not sure if anyone knows. As far as I know, there's no
jurisprudence about the copyright of copyright licenses.

~~~
tedunangst
The GPL is itself copyright, but its licence doesn't permit modification. One
example.

~~~
icebraining
But was that tested in court?

------
rebolek
So the PHP license is as good as PHP itself. What a surprise.

------
mangecoeur
Not directly relevant, but is it me is is lwn.net one of the ugliest sites
ever. practically anything, including dropping all the formatting altogether,
would make it look better. In that vein, I think I've identified a CS-specific
visual syndrome that makes CS people always choose a bizarre shade of salmon
pink for everything. See aforementioned lwn sidebar, and other exhibits
[http://hyperphysics.phy-
astr.gsu.edu/hbase/hframe.html](http://hyperphysics.phy-
astr.gsu.edu/hbase/hframe.html)
[http://www.lyx.org/images/about/main_window.png](http://www.lyx.org/images/about/main_window.png)
(there are others i can't be bothered finding right now, apache foundation has
a number of gems, and more that have thankfully been redesigned in the last
few years)

------
bellerocky
> It is clear, he said, that PHP doesn't care about the misuse of its license
> and the misusers don't understand that they are making a mistake.

You could replace "license" with a lot of other words and it would still a
possibly accurate statement. "mysql api" comes to mind, as well as "classes"
and "URL query variables like $_GET"...

~~~
jonursenbach
Oh, here we go again. This is unnecessary bashing.

