Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] Devfile, JSON schema & license stubbornness

Hello,
for the time being, we still can live with some restrictions with the validators/generators we currently using.
But adding new big tool types into devfile may became problematic.

  At the same time, there is a lot of requests from users to the  "everit" validator maintainers to change JSON api
from json.org to GSON or jackson. (There is even some PR's, but they're still uncomplete).
Maybe some other JSON schema tools going to  implement support of spec-07 too.
So i will continue to keep an eye on it.

On Mon, Feb 18, 2019 at 12:45 PM Mario <mario.loriedo@xxxxxxxxx> wrote:
Thank you for the update Max. Do you have any idea yet on what could be the alternatives?

On Fri, Feb 15, 2019 at 2:00 PM Maksim Shaposhnyk <mshaposh@xxxxxxxxxx> wrote:
 Hi all,
 as some of you may already know, one of the keystones of the Defile API is that it's using
 JSON schema for many aspects, such as validation of incoming devfiles, building model POJO's and documentation generation.
 
 JSON schema specification itself still doesn't have any releases, and it is
 stepping by Internet Draft versions, current of which is Draft-07 [1].
  As a result of this, a small variety of java tools supporting JSON schemas,
 additionally limited by supported version (some of them still at draft-03, 04 etc.).
 
 Initially, our schema wasn't so complex, and fits into Draft-04, but the more features we add,
 (like new complicated tool types such as dockerimage), the more we feel that current tools we use doesn't fit anymore (they're sometimes producing odd validation messages, have some complexity generation collections in POJO)  plus we need the latest 07 spec innovations like "if"\"then"\"else" switches e.t.c.
 
 So the another JSON validation tool [2] was found, and firstly things looked pretty nice - latest draft support, active development,
 much better UX with messaging, and not least, recommendations from json-schema group. 
 Also it was require an minimal set of changes in our code, merely, change the used JSON framework from jackson to org.json, which is just another 15 minutes for brave guys like us (ok, maybe half of day) :-)
 
 But when it came to the license checks, the quite interesting things appeared. The author of json.org api, included the sentence  "The Software shall be used for Good, not Evil" into his software license. [3] It can be interpreted very widely, so at some point,  Apache Foundation moved the JSON license to its Category X license list (not approved) [4], so, apparently, we cannot use any library which depends on that API anymore. Surprisingly, eh?
 
 As i found in one of IPZilla CQ-s: "Many many folks have approached Mr. Crockford asking him to revise the license  but with no success." Perseverance worthy of respect :-). More details can be found in CQ-s [5], [6].

 All-in-all, this is an a major obstacle to further devfile development, and it seems that  we will be forced to re-think our approach to all those 3-rd party automatization stuff tools pretty soon.
 
 Regards, Max.
       
       
[1]  http://json-schema.org/specification.html
[2]  https://github.com/everit-org/json-schema
[3]  https://github.com/stleary/JSON-java/blob/master/LICENSE
[4]  https://www.apache.org/legal/resolved.html#json     
[5]  https://dev.eclipse.org/ipzilla/show_bug.cgi?id=13579
[6]  https://dev.eclipse.org/ipzilla/show_bug.cgi?id=12764      

--
Max Shaposhnyk,

senior software engineer

Red Hat
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev


--
Max Shaposhnyk,

senior software engineer

Red Hat

Back to the top