So is someone going to take this to Georgia Public Library Service and ask permission? Seems like this would be a GREAT opportunity and Evergreen/Equinox already has a relationship with them it should be an Evergreen group making the request with Support from the Koha Community? Benefits for all... I see the openncip.org - webspace is no longer a valid website but is still - "owned by PTFS"... Looking for recommendations... Texas is very interested in this as our "NEW" ILL system is going to be based on NCIP and Evergreen and Koha will need that connection. David Schuster Joe Atzberger wrote:
For example, the SIP2 implementation?
That points to a problem. Koha's SIP2 implementation is actually a fork of OpenNCIP [1], and I would like to merge in Koha's changes at some point and remove the fork. But even if the fork never gets resolved, there's a problem: OpenNCIP's license is GPL2, not GPL2+. As GPL2 and GPL3 are incompatible licenses, if we license Koha using the GPL3+, we couldn't use Koha's SIP2 support code until either OpenNCIP is relicensed to GPL2+ or we get specific permission from the original copyright holder (the Georgia Public Library Service).
I'm working on updating that implementation itself, incorporating many of the changes I previously made on the Koha version (but not all; some are Koha-specific hacks).
I've pulled the repo out of it's CVS mausoleum and posted it to github:
http://github.com/atz/SIPServer
Updates will include 3M's checkin extensions that Koha already enjoys. This repo should serve as the de facto Koha-reconciliation codebase as well. Open to contributions, but the hard part isn't make patches: it's doing real testing with the resulting code.
Long-term, I would like to see the perl stuff distributed as a proper CPAN module, but that will be a pain. Our namespace choices have been exceedingly poor, and test coverage is lacking (koha is ahead there). In particular the example ILS abstraction layer (already a poor choice for CPAN distribution) conflicts directly with Koha's self-serving reimplementation in the same namespace. I am responsible for some of that.
So someday, I could imagine moving everthing under Business::SIP or OpenNCIP::ILS or similar non-root namespaces. And then, e.g:
ILS::Item (example) => OpenNCIP::ILS::Item ILS::Item (Koha) => OpenNCIP::ILS::Item::Koha OpenILS::SIP::Item (EG) => OpenNCIP::ILS::Item::Evergreen
Considering "SIP" is unrecognizable to most and also an acronym in VOIP circles, using it as a filename in root cpan namespace is a bad idea. And Sip.pm makes even less sense.
Anyway, point being we have a venue for making changes to OpenNCIP, including license update should GPLS approve.
--Joe
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- View this message in context: http://old.nabble.com/Re%3A-SIP2-OpenNCIP-development-%28was-AGPLv3-discussi... Sent from the Koha - Discuss mailing list archive at Nabble.com.