JSON_parser license issues

[costela]

Sorry to bother you with legalese, I guess this sort of problem may not sound important to everyone, but we noticed a license issue with JSON_parser.*: the license includes the following part: "The Software shall be used for Good, not Evil."

This is in violation of the Debian Free-Software Guidelines(0), the FSF free license definition(1) and possibly the Open Source Initiative's definition. Even if it's most likely unenforceable in most jurisdictions.

I know this is third-party code and it's unrealistic to request it's replacement on short-notice (especially since it wouldn't even help our specific case), but I wanted to report it here in case people are already toying with the idea of replacing it for any other reasons, as one further reason to do it.

I'm also simultaneously asking for some help in trying to sort this license issue out (2). If the JSON folk don't feel like removing this term and I can't find any other solution to this conundrum, transmission might have to be moved to Debian's non-free repository. (please don't read this as a threat; I'm just stating what we'll have to do to stay true to our own policy, even if I personally find it most unfortunate)

Cheers

0. ​http://www.debian.org/social_contract#guidelines
1. ​http://www.gnu.org/licenses/license-list.html#JSON
2. ​http://lists.debian.org/debian-devel/2012/11/msg00168.html

(version set to 2.52+ because that's the - admittedly old - version to be released with Debian wheezy)

[jordan]

The author of that parser's been pretty good with accepting feedback & patches in the past, so let's see if he's interested in DFSG compliance. Otherwise we'll look into switching parsers.

Thanks for the heads-up. I agree with your reading on this.

[jordan]

I've sent Jean mail asking for permission to drop the one-liner in Transmission's copy of JSON_parser.[ch], making it effectively an Expat license / MIT license.

JSON_parser doesn't appear to be listed at json.org anymore so I'm not sure if there's any way to contact the author other than the email that I used in the past when sending him patches. If this approach doesn't work out, I'll look at the other parser options out there.

[jordan]

Okay, I've updated trunk to use jsonsl, which has a suitable license.

Leo, it looks like trunk /should/ build on Wheezy. I think our biggest requirement is GTK > 3.4, and Wheezy's got 3.4.2. Would a new release of Transmission from trunk make it into Wheezy to resolve this issue?

[jordan]

---

r13614 | jordan | 2012-11-10 22:26:56 -0600 (Sat, 10 Nov 2012) | 1 line

(trunk libT) #5131: replace JSON_parser with jsonsl to resolve licensing issue.

---

r13613 | jordan | 2012-11-10 22:20:15 -0600 (Sat, 10 Nov 2012) | 1 line

add more unit tests for the json-benc glue code

[costela]

Replying to jordan:

Okay, I've updated trunk to use jsonsl, which has a suitable license.

Wow, that was fast! Thanks!

Leo, it looks like trunk /should/ build on Wheezy. I think our biggest requirement is GTK > 3.4, and Wheezy's got 3.4.2. Would a new release of Transmission from trunk make it into Wheezy to resolve this issue?

It's definitely buildable in wheezy, but I don't think our release-managers will approve of uploading 2.80, as it's probably too big of a disruptive change this late in the release cycle (queue jokes about debian's long release cycles). I'll propose backporting this change to 2.52 and see if they accept that as compromise. The changeset seems pretty straightforward and limited to json.{c,h}, so it should be doable.

[jordan]

Note for Debian packagers / cherrypickers: using the revisions listed above will give you the smallest diff. After this point, the surrounding code got refactored for 2.80, so 2.80's diffs will be (much) larger.