Development #465

Closed
wants to merge 18 commits into
from

Conversation

Projects
None yet
5 participants

I added the TouchJSON Library. The need of TouchJSON is primarily caused by license issues with BSD licensed libraries.

+#elif defined(EXTJSON_TouchJSON)
+ //NSString* json = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];
+ _rootObject = [[CJSONDeserializer deserializer] deserialize:data error:&err];
+ NSLog(@"Root: %@", _rootObject);
@jverkoey

jverkoey Mar 10, 2011

Contributor

Let's get rid of this NSLog before we merge this in :)

Contributor

jwang commented Mar 11, 2011

TouchJSON is super slow. I don't think this is a good idea. Is the license causing a huge problem? json-framework is used in a lot of other apps.

See: JSONKit

Contributor

jverkoey commented Mar 11, 2011

Hm. It may be better to look into merging JSONKit into Three20. Those benchmarking results are damn impressive.

Hello guys, my intention was not to get a more performant solution, it was more the license thing. The license of Three20 is a apache 2.0 without a NOTICE file. So you CAN, but are not forced to place a license about screen in your app. The BSD license of the most JSON Frameworks forces you to place this copyright notice into your binary.
Some customers don't want such a license screen in their apps. If a customer REALLY don't want that screen (and i am not able to convince the customer that it's a good idea to create such a screen), I have a few options:

  1. I don't use three20
  2. I use three20, deactivate the JSON function and add TouchJSON manually
  3. I implement my own parser
  4. I break the license of the JSON libraries (only the BSD licensed ones)

Of course my preferred way is to talk to my customer and tell him to create the about screen and add that information to get a more performant JSON library. But this argument is not working with every customer out there. As the most developers out there, i prefer to use the same framework for as much projects as possible to keep the maintenance tasks lower.

I hope that is a understandable issue with the license and i think it could prevent a lot of developers from breaking the license of the used libraries.

The problems described in the study from openlogic ( http://www.openlogic.com/news/press/03.08.11.php ) is primarily caused by the ignorance of the licenses. I think it's a good thing to add a library to a framework to prevent the developers from legal issues when using the framework. Also we should also add an article in three20.info about this issues and describe the performance discrepancy of the different frameworks.

What do you think about that?
We can also add JSONKit to Three20 to get a more performant solution. I am also thinking about developing a binary plist solution, but i am not yet sure about that.

Contributor

jverkoey commented Mar 13, 2011

Hey Dominic, sorry for the delay in getting back to you on this; after releasing 1.0.5 I took a break for a few days and will be getting back to reviewing pull requests tomorrow. I'm looking forward to merging this in and growing our support for the various JSON parsers out there. Thanks so much for putting this together :)

As for this framework vs TouchJSON, there is no downside to including as many JSON frameworks as we can into the library, so ideally we'll someday support both.

Thanks for your reply!
Great that you want to merge it.

Contributor

jwang commented Mar 14, 2011

I still think we should think about switching to using gitsubmodules for something like this. I don't like the idea of us having to keep TouchJSON or any other library we add updated on our end instead of relying on a submodule. It could then be later argued that we should allow instead of TTURLRequest to use ASIHTTPRequest which handles support for S3, has caching that actually works, etc. I see this coming back and being a giant pain later on. We'll want to think this through very carefully.

Contributor

jverkoey commented Mar 14, 2011

We can probably switch this pull request up to use a submodule. I'm just not the most familiar with their intricacies; do you think you could put together a simple run-through on best practices for submodules?

I'm the author of JSONKit.

If the BSD license for JSONKit is a problem, I'd be happy to grant some kind of exception along the lines of "When used with three20, the attribution/notice requirement of the BSD license does not apply" (or something to that effect, you get the idea).

I use the BSD license because it's always nice to see where your stuff pops up. But the reality is very, very few people ever comply with it. Heck, the official twitter client for iOS uses RegexKitLite (another one of my projects) and it doesn't acknowledge it, even though it does have acknowledgements for other BSD open source components.

Anyone have any suggestions on how to do this? Language to use? Should these legal details reside in some file in the three20 repository, or do I have to make changes to the JSONKit source? I sort of prefer a blanket "in perpetuity, for any and all versions when bundled with / used as a component of three20" grant / license text that would sit in the three20 repo. Then you can do the git submodules linking stuff without any concern.

Thoughts?

Hello guys,

i added the library as submodule to the repository. I hope you like that.
Submodule using is quite easy

git submodule add git://github.com/TouchCode/TouchJSON.git src/extThree20JSON/Vendors/TouchJSON

git submodule init
git submodule update

In the .gitmodules file you can see your configuration.

... Thinking about adding JSONKit to the repository too. ....

Contributor

jwang commented Mar 23, 2011

I prefer to give credit where credit is due. ie. http://www.mobilecrunch.com/2011/02/28/creator-of-angry-birds-physics-engine-calls-out-rovio-for-not-giving-him-credit/

But that's me personally. And also, if a client or developer really doesn't want to give the proper credit, then they need to recreate what they need and or find an alternative solution. In any case, that's my personal opinion and not that of the Three20 project. I'm stepping out of this one until the extension system is actually defined and built out.

I modified the license for JSONKit so that it is now "dual licensed" under either the BSD or Apache License, Version 2.0 (the same as three20). This was done with johnezang/JSONKit@3c6ff50, which was followed shortly by johnezang/JSONKit@635005b to fix a typo / line duplication.

The language that I used was

//  Dual licensed under either the terms of the BSD License, or alternatively
//  under the terms of the Apache License, Version 2.0, as specified below.

(this is followed by the BSD license text, which was already there, and then the apache license blurb, which was added).

I am not a lawyer, but I believe this is sufficient for people to "pick which license they want to apply". I think this is sufficient to address the concerns that were raised here.

Thank u very much @johnezang. I added JSONKit to my fork and hope somebody will merge it soon! :-) It seems to be very lightweight and fast. I am quite impressed!

dob and others added some commits May 16, 2011

@aporat aporat closed this Jan 19, 2012

ArcticLeaf pushed a commit to ArcticLeaf/apptentive-ios that referenced this pull request Nov 13, 2013

Modified the JSONKit so that it is dual licensed under either the BSD…
… or Apache v2.0 license. This was motivated by the discussion at facebookarchive/three20#465
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment