<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">For example, the SIP2 implementation?<br>
<br>
</div>That points to a problem.  Koha&#39;s SIP2 implementation is actually a<br>
fork of OpenNCIP [1], and I would like to merge in Koha&#39;s changes at<br>
some point and remove the fork.  But even if the fork never gets<br>
resolved, there&#39;s a problem: OpenNCIP&#39;s license is GPL2, not GPL2+.<br>
As GPL2 and GPL3 are incompatible licenses, if we license Koha using<br>
the GPL3+, we couldn&#39;t use Koha&#39;s SIP2 support code until either<br>
OpenNCIP is relicensed to GPL2+ or we get specific permission from the<br>
original copyright holder (the Georgia Public Library Service).<br>
<br>
[1] <a href="http://sourceforge.net/projects/openncip/" target="_blank">http://sourceforge.net/projects/openncip/</a></blockquote><div><br></div><div>I&#39;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).  </div>
<div><br></div><div>I&#39;ve pulled the repo out of it&#39;s CVS mausoleum and posted it to github:</div><div><br></div></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div class="gmail_quote"><div><a href="http://github.com/atz/SIPServer">http://github.com/atz/SIPServer</a></div></div></blockquote><div class="gmail_quote"><div><br></div><div>Updates will include 3M&#39;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&#39;t make patches: it&#39;s doing real testing with the resulting code.  </div>
<div><br></div><div>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&#39;s self-serving reimplementation in the same namespace. I am responsible for some of that.</div>
<div><br></div><div>So someday, I could imagine moving everthing under Business::SIP or OpenNCIP::ILS or similar non-root namespaces.  And then, e.g:</div></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div class="gmail_quote"><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">ILS::Item     (example) =&gt; OpenNCIP::ILS::Item </font></div><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">ILS::Item        (Koha) =&gt; OpenNCIP::ILS::Item::Koha </font></div>
</div><div class="gmail_quote"><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">OpenILS::SIP::Item (EG) =&gt; OpenNCIP::ILS::Item::Evergreen</font></div></div></blockquote><div class="gmail_quote">
<div><br></div><div>Considering &quot;SIP&quot; 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.  </div><div><br>
</div><div>Anyway, point being we have a venue for making changes to OpenNCIP, including license update should GPLS approve.</div><div><br></div><div>--Joe</div></div>