Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
For the upcoming release (august) we are planning to support AWT and SWT rendering. As we use this quite for a while internally (CABAReT Stage), we believe this is mature and a really interesting component. Up to now i just didn't find anything comparable.
So, thats the problem. There is really much work in this component and we are not sure if we should use a BSD or a GPL license for it.
So, besides the fact that we ARE going to release this code, perhaps you will participate in a discussion on the license type...
I'm not too much into licenses but AFAIK, if you release it under GPL you provide it to the "open source community" if the project then envolves and receives external input you cannot use this extended library in your commercial product CABARet Stage unless you put it under the GPL as well. Therefore I'd suggest to use LGPL, BSD, Apache or any equivalent, because then you and others can work together and benefit from the improvments made.
As I said, I'm not too much into licenses, feel free to correct me ;-)
Still, as we are the licensor we are free to provide CABAReT (and others!) with commercial licenses while the community has access to the GPL version. Maybe we are doing it wrong but until now there is no (0, zero) improvement / addition to jPod from outside. So, probably i have to look for the benefit elsewehere :-)
I totally agree with Andy. Just look a the lots of successfull Projects with developement fokus (TomCat, Glassfish, PostGres and so on...).
All these Projects use the LGPL or a BSD style licence. Only if a company can earn money with wot they do, they will invest in the libary.
I dont see any developers that say hey, PDF Bugs are so sweet I'll fix em in my leisure time.
I think bottom line a BSD style licence like Apache or LGPL will bring you more benefits.
how true this is:
>> Only if a company can earn money with wot they do, they will invest in the libary.
What is our benefit in keeping quality and features up (besides the pure pleasure of good code, which is a good actuator itself). What do you think is a win-win business model for us as the provider of the whole library (not only a bug fix in leisure time). How can we participate in commercial success?
IMHO I see two strategys of open source.
The first one is the one you mentioned. The licensor keeps his code and maintains it by himself and releases the older versions as GPL code. The benefit of this strategy is: market awareness because lots of people can use the code for free.
The improvements in the GPL code have to be synced into your own codebase (lots of work).
The second strategy is to release it under the LGPL and enable other companys to earn money with it and also enable them to team up with you in points of developement. I'm absolutely sure that you will have much more effect on the second strategy, cause you'll be the first java libary providing PDF rendering capabilitys.
An the lack of this feature is really a pain in the ass for the java world.
I think jpod has the oportunity to become the leading Java PDF libary with its robustness, its text extraction features and als its rednering capabilitys.
So for you, you will get better, more reviewed and tested code which is essential for your own software, you'll get very good PR as the maintainer of the most popular pdf libary, you can support the libary and earn money with support and developement services. You can write an documentation and sell it as a book. And you can still sell your CABAReT produkt even if you directly use the community code.
I my eyes the problem is, that JPOD currently provides the same features as PDFBox does. It's way better structured and very well done, but it lacks documentation and examples. So right now, I can understand that people prefer PDFBox and therefore don't help to improve JPOD. Adding rasterization support and some documentation would totally change the whole picture.
As business model you have the choices:
1) You are the only maintainer of the library and release it under GPL and under a Commercial license (this is what MySQL does). Your benefit: You may get a lot of testers via the GPL version and receive a lot of bug reports and all this.
2) You set it under LGPL or equivalent, you can accept additional committers and you can sell professional support, trainings, etc. However, if you want others to be able to commit code to the library and help to improve it, you have to put it under LGPL, because otherwise you really cannot use it even for your own commercial products.
I'd be happy with either approch.