Here’s a story for you:
You have a car with four wheels. But they aren’t ordinary wheels. You see, every 10000 times a wheel makes a rotation, there’s a 1% chance that $1 will disappear from your bank account. You’d like to avoid this, and your buddy, one who has some design experience, offers to build you a new set of wheels.
Years go by and though you’ve yet to lose a single dollar, you remain anxious and await your buddy’s return. Then - he arrives, gleefully exclaiming “I did it, I did it!”
In his arms, four times this:
You install the wheels and start the car. Sure enough, it works - it’s a bit bumpy so no drinks, pregnant women or sharp objects in the vehicle, but hey - there’s no chance of losing dollars! If that’s not a win, what is?
We can ignore the fact that we are now moving at 1/3rd of the speed and spending 4 times as much on gas, as well as the fact that a week later we already have to have the car serviced and all the suspension replaced, but we can no longer lose dollars for no reason - that’s all we wanted, right?
By now you’re wondering if I’m going anywhere with this. And yeah, I am. See, PHP has had bundled JSON support since 2006. But in 2012, someone with way too much time on their hands noticed that the JSON extension’s license says the following:
./ext/json/utf8_to_utf16.c:The Software shall be used for Good, not Evil.
./ext/json/JSON_parser.c:The Software shall be used for Good, not Evil.
./ext/json/utf8_decode.c:The Software shall be used for Good, not Evil.
./README.REDIST.BINS:The Software shall be used for Good, not Evil.
Ok, someone made a joke in the text file of a piece of software, so?
As it turns out, that’s our wheel-rotation dollar loss right there - that’s what made the PHP internals decide that NOPE - this software was no good, because the license didn’t exactly match the one they had been using in other projects (failing, at the same time, to notice that similar shenanigans had occurred in the SQLite3 license - remaining unreported to this day).
Because of a small license difference, an entire replacement JSON extension was developed, one that works as well as a square wheel. You see, while the traditional JSON functionality in this new extension works just fine, the edge cases weren’t even considered. And when they were reported as broken, they were deemed less important than four joke lines in a license file.
- “Your projects’ quality be damned, we can’t have jokes in our licenses, of all things!”
Even Rasmus thought that rewriting the JSON implementation due to this was stupid.
It later turned out that a lot more people took this license joke far more seriously than they should have. In fact, it made Fedora’s bad license list. Eltzner then jumps in with a better explanation on why this seems to be a big deal and how Douglas Crockford actually threw a wrench into things with his silliness. Of course Good and Evil cannot be defined. Of course any court would invalidate these terms. But they’re in there, and they cannot be ignored.
Finally, Jose tops the topic off with an incompatibility report to which no one reacts. Worse, the bug is simply closed. And now, we have an extension in which parsing big integers into strings only works for numerics under 64 bits, so the official example #5 does not work - invalidating the official documentation and breaking some libraries in the process. I myself have encountered this on a lib I’m developing, where I get numbers larger than the extension can parse.
While the large integer parsing issue has been reported a long, long time ago and still remains unfixed, noticing this for the first time now, I took it upon myself to report an official PHP bug that the documentation is, in fact, bugged - the example is simply not true on most installations of PHP. That bug, too, was promptly dismissed without valid reason.
Now, will this be fixed? It seems that for PHP 7 the answer is yes - a new jsond parser will come into play. But for PHP <7? Doubtful - if it hasn’t been fixed so far, there’s fat chance it’ll be fixed months before PHP 7’s release. But does that mean that libraries needing to parse numerics larger than 64 bits need to declare PHP 7 as their minimum requirement? Is that not ridiculous? And if the legality of a license over the terms “Good” and “Evil” was brought into question so hard it caused the development of a new extension, why are there no such repercussions for claiming to be a “drop in replacement” when this is obviously not true? And why is functionality that allows for ints over 64bits simply not taken from the original implementation and reused in the new extension to achieve full feature parity? (Some say it’s because that software is under a different license. But now we license snippets of code too? How long until we can license the plus sign in an assignment operation?) So many questions…
Got any answers? Let me know…