You will have to ask the original author, at json.org.

Once they have updated the license, we can just merge the changes.

Well, json.org doesn't have any contact address, and also the DNS records (whois) don't have anything useful. The only reference available is Omar Kilani, but it doesn't seem like he wrote the original code.

Any help / pointer would be great.

In any case, this is still a code distributed by PHP.net and I don't see a reason to ignore this by pointing to another project.

As a policy we do not change the license of code we bundle. Contact Douglas 
Crockford at json.org. He wrote this reference implementation that we are using.

You can see the license here:

http://www.json.org/license.html

It explicitly states, "The above copyright notice and this permission notice 
shall be included in all copies or substantial portions of the Software."

So we would be violating the terms of the license if we were to remove the 
notice.

Mail sent, thanks. Hope he will help to solve this. Otherwise we should think of a plan b.

Well, I think you will find that code from json.org is in a lot of packages 
Debian ships. This isn't a PHP-Debian issue, this is a Debian-json.org issue for 
you guys to work out.

I wasn't aware for having non php.net developers involved in the code, otherwise I wouldn't asked just to remove that paragraph but to resolve the issue with upstream, which is what I'm trying to do.

Your licensing policy is what we all do, no need to defend it (:

Anyway, thanks for the fast responses.

On Wed, Nov 14, 2012 at 10:06 PM, Douglas Crockford <douglas@crockford.com> wrote:
> The license looks fine to me.

So he refuses politely... which means it's time for PHP.net to think about this license issue (e.g. use a different implementation for JSON).

And you're right, it's *also* problem in Debian, and we talk to the different upstream projects, trying to resolve the issue with each of them, but that's still a problem of the upstream itself.

Sorry, I don't see us ripping out and rewriting the json code due to this.

I just want to note that the FSF[1] and other distributions like Fedora also think this license is bad[2].

  [1] <http://www.gnu.org/licenses/license-list.html#JSON>
  [2] <https://fedoraproject.org/wiki/Licensing:Main#Bad_Licenses>, look for "JSON License"

So this is not a problem for just Debian.

Ansgar

well, the FSF does not like the PHP license either. Nothing worries me here :)

More seriously, as soon as the license is changed upstream, we will merge it. But 
we won't be able to do anything before.

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.

A patch proposed in https://bugs.php.net/63588 makes "json_encode" really free.

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.

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

Yes, I'm still working on the new alternative extension.

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

@seld Mandriva/Fedora/Debian have drop json non-free extension but provides jsonc dropin alternative (php5-json 1.3.1 for debian).

So, your comment is not PHP related. See debian packager to have this package installed when needed (pulled by main php package for Fedora).

How this is a PHP bug?

Not evil???????... come on!!!!!!!

Stas: We (PHP) provide the code, and the eco system clearly has a problem with it. We could either keep ignoring it while they provide a replacement code, or adopt it officially to make everyone happy.

Stas: Of course it's a PHP bug.  PHP don't live in a vacuum, but has thriving 
ecosystem of various users/packagers/distributors/distributions/etc. and they are 
all affected by the choice you (as PHP) make.

It's not healthy to dug the head into the sand and pretend that it's not a _PHP_ 
bug, since it affects the users of PHP.

Why do you guys even argue about this?

This is not a problem of PHP. It is a problem of Debian. If they don't like the 
license then they can just replace the code. Or they can go forward and drop the 
whole PHP package from their distribution. (Which is the usual threat from Debian 
mainteiners.)

Not a bug in PHP.

Keep this open.

This issue need to be discussed by all PHP developers.

I plan to submit a RFC in a few days.
This bug will be closed according to the vote result.

Besides the license issue, which is a problem but not a php one, Remi's new 
extension brings its lot of nice new stuff.

Please leave this open and add a link to the new extension and RFC, to avoid 
endless confusion here.

I'd be more than happy to see a json extension drop-in. Obviously we cannot 
change the license without the authors permissions, so a drop-in would be the 
best approach.

I hate to add to the noise, but has anyone pointed out to JSON that leaving it to a court to interpret "shall be used for Good, not Evil" is a highly unpredictable outcome? The entire license could be invalidated -- since it has no severability clause -- meaning nobody except the copyright owner is allowed to use any of the JSON code for anything. Is that really a potential outcome that they want?

When the decision is made, can we get a public statement on the site about it? 
Posts like the one on iteration99 (dot) com are only raising the confusion level 
among devs when really this isn't something directly impacting most PHP 
developers.

I definitely would like to encourage the adoption of https://github.com/remicollet/pecl-json-c in all distributions of PHP if for no other reason than the JSON_PARSER_NOTSTRICT option:
* comments are allowed in json string/files (Using /* */ or // until end of line)

This would allow the use of commented JSON configuration files, which is awesome.

I think I speak for most PHP end users when I say I *literally* couldn't care less what underlying JSON implementation is used in the end, as long as the json_* functions remain core, default-enabled functions.

The utter childishness of some of the comments in this thread gives me a non-trivial level of concern, but I'm hoping we don't enter a future where json_* cannot be relied on to exist.

Yesterday a co-worker upgraded to PHP 5.5 and found that he was missing these vital functions. The revelation that THIS of all things was the cause left us speechless.

Tim, if you had upgraded from the version provided by php.net you would not have seen a problem. We have not removed json and we will never release a version of php without json support built in. Any changes in 5.5 is due to whatever distro packaging you are using which we have no control over.

If the original source code stays within the PHP code the complete PHP license is invalidated, that's a serious bug in my opinion. But seems like nearly nobody else from the PHP group sees this problem. In the end it's the same as taking some proprietary code from {{Company X}} and simply reshipping it with your own license. Whoever thinks that {{Company X}} would be happy about this, think again...

https://github.com/remicollet/pecl-json-c seems to be a great drop-in with comment support for JSON files which is great in my opinion. Something that JSON should have supported from the very first release.

I'd like to note that this issue has caused a few bugs within the distros themselves. Ubuntu now packages pecl-json-c as an alias for php5-json. The package is a valiant effort, but is unfortunately incompatible with the version bundled with PHP.

The pecl-json-c version improperly parses non-utf8 characters. In the process of upgrading from one LTS of Ubuntu (12.04) to another (14.04), we uncovered this issue after test runs. I've filed a bug against the readme of that repository - and am attempting to setup automated testing so that we can potentially whittle away at the issue - but I cannot currently suggest it as a valid alternative to the built-in json integration. Hopefully I can get tests going and we can change that situation.

Unfortunately, all PPAs and external repositories for Ubuntu 14.04 appear to have this same issue, so the fix is currently (pending some tests of course, I haven't created a debian package in a few months so this is all from a cursory glance):

- apt-get source php5
- Remove the dfsg-repack.sh. This file is the file which removes ext-json (why they didn't just change the compile options I don't know, but I'm sure there is a good reason)
- Add php5-json to the provides and conflicts stanzas of php5-common in the debian/control file
- Remove php5-json from the depends and breaks stanzas of php5-common in the debian/control file
- Change the version in the debian/changelog file.
- Run `debuild -us -uc -b`

Hopefully this helps someone else in my shoes. I also wonder why they didn't remove sqlite/sqlite3, as the copyright there is a blessing with similar language ;)

Jsond has just been merged to master so this can be closed