I can't say I like their licensing scheme too much. Among other things it is even more viral than GNU in some ways; you are required to open source any server-side code that outputs Tibet code as well as the Tibet code! Note that they expect their Open Source License to be accepted by OSI, but it hasn't been accepted as of right now. I wouldn't hold my breath if I was them...



Another problem is that they have patents on a bunch of obvious stuff like signals and client-side markup. What's up with that?



Plus the library may be overkill for some applications. There are hundreds of methods and objects there which may never be used in a particular application, but no obvious way to trim it down.



All-in-all I think there is lots of cool code in the library, but am extremely underwhelmed by all the marketroid-speak and restrictive licensing. Plus I didn't see the cost to license it for commercial use anywhere, usually a clue that it is out of my reach.



Heck with Tibet. If I need something like this I will write my own. And they can take their patents on client-side markup and such and put 'em where the sun don't shine...



Jack William Bell

I should open by saying I'm one of the co-authors of TIBET and the author of the RPL (http://www.technicalpursuit.com/Biz_RPL.html). I'm posting in the hopes of clarifying what appear to be issues in how the TIBET license/patent design is being interpreted. I'd also like to clarify a few other points. Sorry in advance for the length of this post but I want to provide as much information and context as possible.



The RPL:



Our goal with the RPL was to create a "GPL with no privacy clause". The privacy clause is a loophole (in our minds anyway) that allows users of GPL software to derive financial benefit without contributing to the movement that made their products possible. So we wrote the RPL. The goal of that license is simple -- Use our code? Share your code.



In regard to earlier comments about the RPL, the GPL would place the same requirement on you. Linking a GPL'd library with an application makes the application fall under the terms of the GPL. That doesn't change simply because the application happens to be client-server or web-based. If the two parts can’t run separately it’s one application. You could just as easily claim "...; you are required to open source any server-side code that [links] GPL code as well as the GPL code!".



The RPL and GPL are viral to the *application*, not some subset of it that's convenient to you. Open source is a hard path. You're either on it or not. Neither the RPL nor the GPL will let you sit on the fence.



As to OSI approval, we’re not aware of any aspect of the RPL that isn’t fully compatible with http://opensource.org/docs/definition.html and we’re willing to work with anyone who sees a problem with the RPL's OSI standards compliance and can relate it to us.



Patents:



We think patents are necessary due to the intense competition in the web marketplace -- competition that often takes the form of “borrowing” innovations from others. Not that we mind you borrowing, as long as it’s reciprocal. Licensing our patent-pending technology under the RPL says you’re free to borrow as long as we’re free to borrow back. Looking at patents independently of license(s) is missing the point.



Our pending patents define what we claim as our intellectual property. The licenses define what you can do with that IP. Since one of those licenses says roughly “do whatever you want as long as you’re willing to share your code in return” the fact that the underlying technology is patent pending shouldn’t matter. On the other hand, trying to use our technology without fair compensation in either code or capital would be a clear violation –- not to mention just plain rude :).



As to “obviousness”, wanting isn’t the same as having. Inheritance, signaling, templating, etc. are all nice features but implementations that work are conspicuously missing. Show me working DOM Level2 Events in Nav4, or IE4+. Show me working type inheritance that supports overriding and “call super” semantics. Show me working XML-compliant page templating. Prior to TIBET none of these existed in JavaScript despite years of web development by literally hundreds of thousands of JavaScript programmers. Clearly our solutions weren’t obvious.



TIBET’s innovations are a long way from the “one click” failures of patent law. To date, I know of no other client-side technology that implements XML-compliant page templating and that includes JavaScript, Flash, Curl, Applets, or other technologies. If client-side templating is obvious I’m curious why nobody ever did it. Maybe it’s not obvious after all? More likely is that by being let in on TIBET’s magic by seeing it all in well-commented source code it now becomes obvious.



The bottom line is that patents cover implementations, not wish lists. Our implementations are patent pending. That doesn’t mean you can’t do inheritance, signaling, templating, inference, or other TIBET features in JavaScript. It does mean you can only use our implementations under a valid license. If that doesn’t appeal to you consider the bar raised. You can raise it higher with your innovations. We look forward to them. Hopefully when you’ve put in ten man-years in the most inconsistent, bug-ridden, zero-tool, “development environment” ever pushed on a programmer you’ll still feel like open-sourcing the result –- we have.



Overkill:



Is TIBET "overkill" for some applications? Look at it this way, it takes less capacity to load an email application written with TIBET, TIBET itself, and the first email than it takes to get a Hotmail message starting from the login page.



Having said that I'll also say this: if you ever write an application that needs all of TIBET I’ll eat my shirt. But then again, the same could be said of Java, Perl, Python, or any other language/library combination.



TIBET isn’t a widget kit, it’s a platform in every sense of the word. It’s an application platform, written in JavaScript and augmented with a library of 350 types and 2500 methods (and growing) designed to let you create applications so complete they don’t have to talk to the server except to commit data – all while letting you leverage existing JavaScript and markup experience to do it. It’s built to support the full range of web application requirements and is particularly suited to the emerging web services model where SOAP access from the browser allows a true client/server architecture and SVG will allow faithful UI rendering. In particular it’s built to support the kind of web-based applications only a few companies have successfully implemented but a lot have attempted. Things like:



- Telephone service ordering for a dozen product lines

- Order entry, personnel management, call centers, etc.

- Network and system security administration consoles

- Embedded device front-ends and administration tools



If you can write what you need such that your wages, deployment costs, and time-to-market delays don’t cost your employer more than TIBET does you’re not building a web-based application as we define it...you’re building a web site. In that case, you’re right -- TIBET isn’t for you.



Code Size:



Most applications in a browser load one page at a time and you have to add the size of the JavaScript to the size of every page. TIBET is different. You load TIBET once per application invocation. TIBET’s reflection system (the only one in JS we know of) allows you to “import” all of TIBET’s functionality into other pages in