Re: [Koha] SIP2/OpenNCIP development (was AGPLv3 discussion)
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
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.
On Wed, May 12, 2010 at 8:53 AM, David Schuster <dschust1@tx.rr.com> wrote:
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?
There are no license issues from the EG point of view, because the code is not distributed as part of EG. So any relicense requests should probably still originate from Koha, covering at least the reimplementation currently distributed as part of Koha, and preferably the whole project codebase. I wrote author and maintainer David Fiander re: my git repo, but I didn't get into anything about licensing. Conceptually, that's separate from and unrelated to the work I'm doing now. --joe
participants (2)
-
David Schuster -
Joe Atzberger