Il 22/05/2012 17:51, Eric Blake ha scritto:

Is the JSON license only applicable to code downloaded from json.org, but not to the actual JSON language specification?

Yes, of course. I think not even Oracle disagrees.

If so, does that mean that a clean-room implementation of JSON (the language specification) can be written with different license than JSON (the license), and that such alternate code could then be linked into qemu?

That is what we did, in fact. Paolo

On 05/22/2012 10:51 AM, Eric Blake wrote:

The QMP monitor uses JSON as its underlying base. However, when you read the license of JSON [1], you will note that it has a pretty severe limitation ("The Software shall be used for Good, not Evil"). In fact, this limitation is severe enough that the FSF has declared that the JSON license is non-free (even if the limitation is unenforceable), and therefore cannot be combined with GPL code:

[1] http://www.json.org/license.html [2] https://www.gnu.org/licenses/license-list.html#JSON

How do we reconcile this? Obviously, qemu must remain GPL, because it has files that are licensed GPLv2, and the overall license is the restrictive union of all source licenses. But that implies that we cannot include any source code or libraries provided by json.org, if such code is under the incompatible JSON license.

Is the JSON license only applicable to code downloaded from json.org, but not to the actual JSON language specification? If so, does that mean that a clean-room implementation of JSON (the language specification) can be written with different license than JSON (the license), and that such alternate code could then be linked into qemu? Is this already the case? It would be a shame to have to reinvent QMP to use a different language specification if the entire JSON language is deemed poisoned.

Hi Eric, When evaluating JSON implementations, I looked at the json.org license and immediately sought other options. I was very aware that that clause would not be GPL compatible. Ultimately, we wrote our own from scratch based on the JSON RFC[1]. There is no dubious claims in the RFC and I don't think there could be as it's simply a strict subset of the EMCA specification. At no point have I ever looked at the json.org source but given the fact that the license is moronic, I expect the implementation to be equally dumb and wouldn't even consider it even if the license was changed at this point. [1] http://www.ietf.org/rfc/rfc4627 Regards, Anthony Liguori

Thoughts? Do we need to seek legal guidance from FSF, Red Hat, or any other organization on how to proceed?