Edit report at https://bugs.php.net/bug.php?id=63520&edit=1
ID: 63520
Comment by: s...@php.net
Reported by: kaplan at debian dot org
Summary: JSON extension includes a problematic license
statement
Status: Assigned
Type: Bug
Package: JSON related
PHP Version: Irrelevant
Assigned To: remi
Block user comment: N
Private report: N
New Comment:
What's the status here Remi? Can we have a regular Debian release including the
JSON ext before this hits testing/stable? We had a first issue on Composer
today because someone was missing the json ext [1], using Ubuntu 13.10.
If this isn't resolved soon Ubuntu's next release won't have json enabled by
default and we'll have a support shitstorm on our hands, so please don't do
Evil because of a dubious license statement. Given the prevalence of JSON APIs
and such these days, it's not just Composer that will be affected, so removing
it before having a replacement in place was really an unhelpful decision IMO.
[1] https://github.com/composer/composer/issues/2092
Previous Comments:
------------------------------------------------------------------------
[2013-04-27 10:40:22] r...@php.net
Yes, I'm still working on the new alternative extension.
------------------------------------------------------------------------
[2013-04-22 22:24:39] pleasestand at live dot com
Remi: any update? Is <https://github.com/remicollet/pecl-json-c>
relevant?
I'll note that as a [MediaWiki][1] developer, I recently removed our
bundled copy of PEAR Services_JSON on the basis that the JSON extension
is compiled in by default, and therefore users can be expected to have
it installed. Unfortunately, I had to [revert the change][2] because
I only found out about the licensing problem last week, and our next
release is three weeks from now (2013-05-15).
So I would like to know whether you are still working on this.
[1]: https://www.mediawiki.org/
[2]: https://bugzilla.wikimedia.org/show_bug.cgi?id=47431
------------------------------------------------------------------------
[2013-04-04 18:00:52] b dot eltzner at gmx dot de
I am not a native speaker. This comment is not supposed to be rude or insult
anybody.
I would like to make the problem clearer:
*The "json license" affecting /ext/json/JSON_parser.c and
/ext/json/utf8_decode.c is regarded non-free by GNU/FSF, Debian, Fedora, Red
Hat and Google and is not approved by OSI. This is not at all the same as "Free
but incompatible with GPL", which is the category in which the FSF lists the
php license.
*The morality clause "The Software shall be used for Good, not Evil." violates
software freedom 0 and point 6 of the open source definition and the license
will therefore _never_ be free or open source by definition. This is not a
license "some fanatics don't like", it is a manifestly proprietary license.
*The original author of the license has purposely chosen this form of license
to trick open source projects into mistaking it as an open source license. He
did this to prove the point that "those open source guys are entitled kids" and
plays the issue for amusement: http://www.youtube.com/watch?v=-hCimLnIsDA
*With the non-free files, PHP cannot be distributed unmodified as free software
by downstream projects.
Note that I don't say "Throw that stuff out!!!!11" It goes without saying that
you can distribute the result of your work under whatever licenses you like,
open source or not. However, if you want PHP to be easily distributable as free
and open source software by downstream projects, I am sure they would be
enormously relieved, if you provided them with a simple way to exclude the
non-free files without breaking too much functionality.
------------------------------------------------------------------------
[2012-11-23 13:33:42] r...@php.net
A patch proposed in https://bugs.php.net/63588 makes "json_encode" really free.
------------------------------------------------------------------------
[2012-11-15 18:09:30] ras...@php.net
I am not saying it isn't a tricky license clause to deal with and it would be
better if it wasn't there. However, I am also not keen on spending resources on
rewriting code for this reason. If someone supplies a functionally equivalent
replacement, we will have a look at it. But as far as I am concerned, license-
wise the terms Good and Evil are not legal terms. These are more subjective
self-describing terms and since I deem PHP's use of the code as "Good" then we
comply with the license. Could others perhaps use PHP and thus the code for
"Evil" and therefore not comply with the license? Sure, but there are many
things people can do with our code that is either against the various licenses
involved or even illegal criminally. It is something we cannot control.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=63520
--
Edit this bug report at https://bugs.php.net/bug.php?id=63520&edit=1
