Desktop Matters


Last week was a busy week for me. I was at San Jose attending Desktop Matters conference. It was just great. Thanks for Ben and Dion organizing it. I met so many people face to face for the first time although we emailed a lot in the past. In this conference, I announced that JIDE will open source JIDE Common Layer within next month. Here are some details.

JIDE Common Layer is a layer on top of Java Swing. When we developed all the JIDE components, we found that there were many missing features in Swing. Thus we created a JIDE Common Layer and included all those missing features. More and more features were added to this layer as we built more products.  All other JIDE products heavily depend on this JIDE Common Layer. JIDE never sell this JIDE Common Layer separately. All JIDE customers get this layer (the jide-common.jar) for free when they purchase any of the JIDE products. So it is not a common layer just for JIDE products but also for our customers. By open sourcing this layer, we hope it will because a de-facto standard building block for any Java Swing applications.

JIDE Common Layer has around 100K lines of code as it is right now. It has over 40 components and utilities which greatly enhances the component set already provided by Swing. Since it is the foundation of all other JIDE products, we will keep enhancing this common layer including adding new components, adding new features to existing components and fixing bugs. We of course welcome other open source developers to contribute to this project and make it thrive.

JIDE promotes component reuse either in open source format or as commercial license. All existing JIDE products will remain as commercial licensed for companies who want a complete and high quality component solution. For the open sourced JIDE Common Layer, we will also provide a maintenance contract for those who will need a high quality technical support which you can’t find in most open source projects.

Well, this is the idea. We will find out soon how this works out. So stay tune for this great news!

Here is the news on Ben Galbraith’s Blog.

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.


Other Posts
Anybody in Manhattan NYC?
First Blog

Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

Reader Comments

Bravo David for open-sourcing this stuff. I’m sure it was a tough decision, and I hope the community is properly appreciative of it. Thanks!

That’s excellent news David! Thanks a lot for open sourcing such high quality work. I am sure the community will love to hear about this.

[…] Qiao, from JIDE Software, announces on his blog that the JIDE Common Layer will be open sourced shortly. Considering the quality of JIDE’s offerings, this excellent news for the […]

Having used the components in personal projects and with a previous employer, I’ve been very impressed, both with the products and with the development cycle and support. I hope this encourages adoption of JIDE. Maybe it’ll interest my current employer too! ;-)

Again - excellent news.
Any idea when and where this will be available?
Thanks

It will be within next month. We will probably open some of the components first than adding more latter.

It will be on jide-oss.dev.java.net but it is not public yet.

Amazing components. Congratulations!

[…] Qiao, da JIDE Software anunciou no seu blog que o JIDE Common Layer será aberto em breve. Dada a qualidade dos produtos JIDE é uma excelente novidade para a […]

What license are you planning on using for the OSS stuff?

We have decided which license to you. We are thinking about GPL or LGPL but free to suggestion. We do want a way to protect our interests while allowing the best leverage of OSS community.

I think it would be a good idea to use
the same license (GPL + Classpath extension) that Sun will use for the open source JDK.
that would allow people using the components in commercial applications and still protect your interests.

GPL+Classpath exception would be a good choice IMHO.

LGPL allows commercial use, I don’t know about GPL+Ex. Anyway, LGPL would be less scary than GPL+whatever, thus adoption would be easier.

I second usage of LGPL, and a clear license that lets commercial customers that they don’t have to worry about any viral aspects of the GPL.

Of course, not sure how LGPL would protect your commercial interests …

LGPL is traditional for libraries such as this. Essentially, any published/distributed modification of your code must be provided to the end user. You will get much more adoption with the LGPL vs. GPL because commercial projects will be able to integrate with it without worry of the implications of their proprietary works.

In fact, you’d probably want to be extra careful in choosing GPL at all, given that your own higher level commercial products are based on the common layer which you’re opening. Granted, you own the copyright so it’s a non-issue. None-the-less, LGPL would be consistent with your guys’ use of the library.

I vote for the Apache licence, way better then the licences from the dark side of open source (gpl and lgpl). With it your product are protected, if someone change the code he/she has make the changes availible and its more friendly to others.

I am currently using some libraries from JIDE with the licence for open source projects any I am hapy with that. I hope that option will stay be availible in the future. I will never use any library under gpl and I don’t like lgpl very much eather. Can I use lgpl code in bsd licenced application?

Definitely not GPL. LGPL is good.

I second what Everet is saying and vote for the Apache 2.0 license also. I would never use any library under the GPL license, and I don’t like the LGPL much either.

One thing I was wondering if you don’t want to use anything using GPL, does it mean you won’t use JDK either since JDK is released as GPL + Classpath Exception?

One option we are considering is to release under two licenses. First license option GPL + Classpath Exception or whatever license as JDK is using. This option is for any open source projects. As long as people use JDK, they can use JIDE Common Layer. The second license is commercial license but it is absolutely free. This is mainly for commercial users who don’t want to deal with GPL of any format.

We certainly are not interested to get into any license war. All we want is to let as many people as possible using JIDE Common Layer but not making it a public domain kind of thing which people use it, modify it but never contribute it back.

The current JDK I use isn’t licenced under gpl. I am planing to move to Apache Harmony. It was just plain stupid of Sun to go for GPL, the problem is the gpl and Linux people, they only accept gpl and nothing else.

If I want to use your libs in an open source project, which options do I have?
I am forced to use gpl or do I have other options?

I have no problem with contibute code back after I modified it.
I am personaly more for licences as Apache and BSD but I am also like commerical licences more then (l)gpl.

Would free commercial license be an option for you? We have to make GPL + classpath exception as one of the license options in order to allow the vast number of GPL-ed projects using JIDE. The other OS licenses are way too open. So as long as you choose an open source license doesn’t prevent you from using both GPL and commercial, you can use JIDE.

I don’t know if the proposed licensing models will work for my two projects, because I have to be extremely careful when it comes to managing my dependencies to avoid restrictions on what I can do with my own code.

The first project is a rich client framework used to develop database forms and report applications. I am considering open-sourcing this framework using the Apache or BSD license. Users of my rich client framework should be able to freely build open-source, closed-source, or commercial applications. I’m writing my own docking framework rather than using JIDE for this reason.

The second project is a commercial port of a financial accounting program that would leverage my rich client application framework. I should not have to pay to use my own application framework in a commercial environment.

I have no problem contributing back code modifications to the JIDE Common Layer library. The licensing complications arise if I release code that has Common Layer as a dependency.

As far as what Sun is doing, I find it ironic they would take an Apache project (Derby) and bundle it with JDK 6 as Java DB.

i think open sourcing this project will be wonderful and an intelligent move.Becouse of that developments will speed up