Until this point the KosherJava Zmanim API has been released under the GPL V2.0 open source license. This had the effect of forcing any application written using the library to release it’s source code under the same license. Being that the Zmanim API is a library, the LGPL is a more appropriate license. The LGPL allows developers to use the KosherJava Zmanim API, yet keep their application code closed source. Only changes to the API itself (such as ports to different languages) would have to be released as open source. I had in the past on request released the source under the LGPL (the Zmanim API .NET port has already been released under the LGPL with my permission), and with the recent 3/27/2011 SVN checkin I formally changed the Java Zmanim API license to the LGPL 2.1 (not the newer LGPL 3.0). The next 1.3.0 release will be the first formal release under the LGPL. In one case the change to the license required permission from developer who wrote code used by the Zmanim API, and this was done.
Thanks!
I asked you about it a while ago regarding the C++ port 🙂 [as Bahaltener]. I was pretty busy so I couldn’t get to actually doing it, but I’m still very interested in it.
Shmerl,
No one stepped forward to do the port yet, but if you find time, make sure you start off the latest version at https://github.com/kosherjava/zmanim.
It’s good that the API now also supports the calendar functionality, since it makes sense to integrate it all together.
I’d like to work on the C++ port, but I have a feeling it might depend on boost datetime libraries. I need to research a bit more what code from Java.Date, Java.Calendar and Java.Timezone the API is using. I’d prefer to avoid adding extra dependencies, but boost implements quite a decent datetime API, so one doesn’t need to reinvent it from scratch.
Some thoughts – if port to C++ would work out, it would be nice to package the library for Meego, and to create some nice calendar application with zmanim and geolocation.
I started working on the port. One of the moments I wanted to highlight – if you are going to expand the library, try to avoid too Java specific / dynamic language functionality (like reflection for example, which some comments there propose to use) to avoid an overhead of implementing that in C++. This is just a thought. Port can probably work around these issues, but the difference between code base would be bigger.
As a side note, it would be also very useful if someone could port the library into JavaScript. It’ll enable easy to create web application with Zmanim API.
To the best of my recollection, reflection is only used in the ZmanimFormatter.toXML() method to avoid having to manually code every zman. This entire method is optional if you want to serialize the class as XML any other way. Just add your own implementation to the AstronomicalCalendar.tostring() method, or avoid implementing it at all. Please let me know if it is used anywhere else.
By the way, what is the legal difference between LGPL 2.1 and LGPL 3.0 and why you specifically took LGPL 2.1?
The code was originally released under the GPL 2. I was not interested in releasing it under the GPL 3 (various reasons). LGPL 3 code can’t be converted by other parties (who do not own the copyrights) to GPL 2.1, but code released under the LGPL 2.1 license can be converted to either GPL 2 or 3. See the chart on the Wikipedia GPL Compatibility and multi-licensing article.