[Koha] Koha Digest, Vol 57, Issue 34

Wed Jul 14 09:24:56 NZST 2010

Hi,

I am a part of the group who are currently evaluating migration from
Millennium to Koha and was wondering if there is a case study which has been
done which outlines how has the experience been, common pitfalls or some
other useful information which can help us in getting to speed in doing a
test evaluation?

If there are any useful links or information you can point out from
migrating from Millennium to Koha that would be helpful too with respect to
in which format the data should be exported from Millennium, what format is
accepted by Koha, how the transformation mapping done.

Thanks and Looking forward to hear from you all.

Regards,
Pranav

On Tue, Jul 13, 2010 at 1:29 PM, <koha-request at lists.katipo.co.nz> wrote:

> Send Koha mailing list submissions to
>        koha at lists.katipo.co.nz
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.katipo.co.nz/mailman/listinfo/koha
> or, via email, send a message with subject or body 'help' to
>        koha-request at lists.katipo.co.nz
>
> You can reach the person managing the list at
>        koha-owner at lists.katipo.co.nz
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Koha digest..."
>
>
> Today's Topics:
>
>   1. Re: Searching problems in 3.2 beta (Liz Rea)
>   2. Re: Online demo for 3.2? (Ian Walls)
>   3. #koha IRC meeting today about voting on software license
>      (Thomas Dukleth)
>   4. Re: AGPL 3 objections and replies (Thomas Dukleth)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 13 Jul 2010 10:08:22 -0500
> From: Liz Rea <lrea at nekls.org>
> Subject: Re: [Koha] Searching problems in 3.2 beta
> To: Amy Schuler <schulera at caryinstitute.org>
> Cc: "koha at lists.katipo.co.nz" <koha at lists.katipo.co.nz>
> Message-ID: <1DC963DC-BE16-4FAB-BD03-3E99D41F39C7 at nekls.org>
> Content-Type: text/plain; charset="windows-1252"
>
> Amy,
>
> You may want to consult the FAQ's for searching:
> http://koha-community.org/documentation/faq/searching/
>
> It's very likely that you need to reindex your data for searches to work.
> There are lots of places for that process to get hung up, so please let us
> know if you need more assistance.
>
> Liz Rea
> NEKLS
>
> On Jul 13, 2010, at 10:00 AM, Amy Schuler wrote:
>
> > Hello,
> >
> > Recently, after consulting this list, my IT specialist Jon and I upgraded
> from Koha 3.0001005 to the 3.2 beta.  He went straight for 3.2 because he
> said that The Koha virtual appliance we are using can only be updated
> through its internal updater, and we were running the latest version that it
> supports.  However, he was able to set up a new virtual machine to make the
> upgrade to 3.2.
> >
> > The issue we have now is that although the database appears to be
> populated --  I can view the records in a public list that I had created and
> also view records by typing URLs in the formathttp://
> 10.70.0.78/cgi-bin/koha/opac-detail.pl?biblionumber=7910, altering the bib
> number to view other records ? the records cannot be retrieved through a
> search.  When we search the database, we have the error ?No results match
> your search?.
> >
> > The sys preferences and other settings seem to have migrated correctly,
> and we tried reindexing the database to fix this problem.  Do you have any
> other thoughts?
> >
> > Thanks as always.
> > a
> >
> > Amy C. Schuler
> > Manager of Information Services
> > Cary Institute of Ecosystem Studies
> > PO Box AB
> > Millbrook, NY  12545
> > (845) 677-7600 x164
> > schulera at caryinstitute.org
> >
> >
> > _______________________________________________
> > Koha mailing list
> > Koha at lists.katipo.co.nz
> > http://lists.katipo.co.nz/mailman/listinfo/koha
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.katipo.co.nz/pipermail/koha/attachments/20100713/1d5fa83e/attachment-0001.htm
>
> ------------------------------
>
> Message: 2
> Date: Tue, 13 Jul 2010 11:30:16 -0400
> From: Ian Walls <ian.walls at bywatersolutions.com>
> Subject: Re: [Koha] Online demo for 3.2?
> To: Liz Rea <lrea at nekls.org>
> Cc: Koha list <koha at lists.katipo.co.nz>
> Message-ID:
>        <AANLkTiknPoPXzuR7vYUkFA0a9WY7Jf6M_Yswk6n6CLfP at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> To be perfectly accurate, the ByWater Demo (at the time of this email) is
> running database version 3.01.00.143, which is 3 or 4 database revisions
> beyond the tagged release of 3.2 Beta.  The current HEAD commit is f74e86ca
> (pushed yesterday), for those you looking to compare it to the Koha Git
> repo.  And as Liz said, the demo is pure Koha, pulled directly from the Git
> repository.
>
> We at ByWater are committed to keeping the demo current on the path to 3.2,
> and will continue to update it as new bugfixes are released.  We're open to
> community input on how to manage the demo after the official release of
> Koha
> 3.2.
>
> If you have any questions about how we host the demo, just ask.  It's here
> for the benefit of the community.
>
>
> -Ian
>
> 2010/7/13 Liz Rea <lrea at nekls.org>
>
> > Er, I mean Beta. ^.^
> >
> > Liz
> >
> > On Jul 13, 2010, at 10:04 AM, Liz Rea wrote:
> >
> > These demos track HEAD, which currently is 3.2 Alpha:
> >
> > Catalog <http://catalog.bywatersolutions.com/> Demo Site for Library
> > Catalog powered by the Koha ILS. This demo runs version 3.01.00.143.
> > http://catalog.bywatersolutions.com/
> >
> > Staff Interface <http://intranet.bywatersolutions.com/> Demo site for
> the
> > Staff interface of the Koha ILS. Username = bywater Password = bywater
> > http://intranet.bywatersolutions.com/
> >
> > These demos are straight Koha, no proprietary code, and they are hosted
> by
> > Bywater Solutions.
> >
> > I hope this helps!
> >
> > Liz Rea
> > NEKLS
> >
> > On Jul 13, 2010, at 9:50 AM, Cab Vinton wrote:
> >
> > Is such a beast available anywhere?
> >
> > Looking for demos of both staff client & OPAC, something along the
> > lines of http://www.liblime.com/demos
> >
> > I found something here --
> >
> http://www.osslabs.biz/koha_library_management_system/try_koha/demo.html--
> > but this seems to be for version 3.01 not 3.2 as advertised.
> >
> > Cheers,
> >
> > Cab Vinton, Director
> > Sanbornton Public Library
> > Sanbornton, NH
> > _______________________________________________
> > Koha mailing list
> > Koha at lists.katipo.co.nz
> > http://lists.katipo.co.nz/mailman/listinfo/koha
> >
> >
> >
> >
> > _______________________________________________
> > Koha mailing list
> > Koha at lists.katipo.co.nz
> > http://lists.katipo.co.nz/mailman/listinfo/koha
> >
> >
>
>
> --
> Ian Walls
> Lead Development Specialist
> ByWater Solutions
> Phone # (888) 900-8944
> http://bywatersolutions.com
> ian.walls at bywatersolutions.com
> Twitter: @sekjal
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.katipo.co.nz/pipermail/koha/attachments/20100713/bc1c2639/attachment-0001.htm
>
> ------------------------------
>
> Message: 3
> Date: Tue, 13 Jul 2010 16:00:38 -0000 (UTC)
> From: "Thomas Dukleth" <kohalist at agogme.com>
> Subject: [Koha] #koha IRC meeting today about voting on software
>        license
> To: "Koha list" <koha at lists.katipo.co.nz>
> Message-ID:
>        <0c4ba21c61bc354953b3d53a7d293547.squirrel at wmail.agogme.com>
> Content-Type: text/plain;charset=utf-8
>
> Please remember that the #koha IRC meeting about voting on whether to
> upgrade the copyright license for Koha 3.4 will beheld today on the #koha
> IRC channel, 13 July 2010 at 19:00 UTC+0.
>
> Time Converter:
> http://tinyurl.com/2eaohr4
>
> Agenda:
>
> http://wiki.koha-community.org/wiki/License_Upgrade_Vote_IRC_Meeting,_13_July_2010
>
>
> Thomas Dukleth
> Agogme
> 109 E 9th Street, 3D
> New York, NY  10003
> USA
> http://www.agogme.com
> +1 212-674-3783
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 13 Jul 2010 17:29:19 -0000 (UTC)
> From: "Thomas Dukleth" <kohalist at agogme.com>
> Subject: Re: [Koha] AGPL 3 objections and replies
> To: "MJ Ray" <mjr at phonecoop.coop>
> Cc: koha at lists.katipo.co.nz
> Message-ID:
>        <3a8f07596291a22e7fb874d17f097634.squirrel at wmail.agogme.com>
> Content-Type: text/plain;charset=utf-8
>
> [Subject changed accommodating requests for easier to follow branches of
> original thread.]
>
> Reply inline:
>
>
> Original Subject: Re: [Koha] Proposal To Switch Koha's License to GPLv3
> and AGPLv3 or AGPLv3
>
> On Mon, July 12, 2010 10:16, MJ Ray wrote:
> > Thomas Dukleth wrote:
> >> On Mon, July 5, 2010 14:45, MJ Ray wrote:
> >> >> 3.1.  COMPLIANCE BURDEN. [...]
>
> [...]
>
> >> Omitting one line of source code
> >> could
> >> be a huge compliance problem about which we should be strict.  However,
> >> if
> >> we adopt AGPL 3, we should have some proportionality and understanding
> >> about imperfection while we strive to provide automation to capture
> >> changes in the Corresponding Source which would be of benefit to
> >> everyone
> >> in complying well with the license.
> >
> > Sadly, while we may wish copyright law had some proportionality and
> > understanding of reality, wishing doesn't make it so.  Thanks to our
> > colleagues in Big Music and Big Movies, copyright now seems pretty
> > disproportionate and unsympathetic, with criminal law and amazing
> > penalties for commercial infringement (and even not-for-profits and
> > for-more-than-profits may be commercial).
>
> The Free Software Foundation (FSF) has been giving support to people
> arguing against 'big content's' attempt to undermine the meaning of
> copyright law terms in court.  Providing the opportunity to make copies is
> not equivalent to distribution (conveyance in GPL 3 terms).  'Big content'
> is able to buy the legislative process but logic is not for sale.  I have
> not followed the general course of 'big content' court cases in the past
> several months.  However, when I had lasted noted the course of events,
> logic and copyright terminology seemed to be much battered but surviving
> the attempt by 'big content' to twist their meaning in court.
>
> >
> > So if we are going to suggest that people can be relaxed/late in
> > meeting the Corresponding Source term, I think we're leaving them open
> > to attack from any less sympathetic copyright holders (of Koha or
> > included modules), as well as ourselves open to attack for advising
> > them badly.
>
> I have raised concerns about liability risks under AGPL 3 and sent a
> message to Aaron Williamson at the Software Freedom Law Center (SFLC) last
> week asking a sharply put question about how the Koha community could give
> reassurances about liability under AGPL 3.
>
> >
> >> > [...]
> >> >> 3.1.1.3.  LIMITING BANDWIDTH REMEDY. [...]
>
> [...]
>
> > This is not only about "poor" connectivity and "expensive" bandwidth.
> >
> > I've been and dug out my network connection contract, which includes a
> > clause which allows the provider to "monitor network traffic levels
> > and selectively slow down certain types of packet."  That's on top of
> > any bandwidth management we do ourselves.  So that seems to mean our
> > network provider may limit Corresponding Source download bandwidth, so
> > it's out of our control whether we comply with AGPLv3 at any time.
> >
> > I suspect that term arises from one of the interconnects like LINX and
> > so most UK internet service contracts will include something similar.
> >
> > Have many libraries got truly unlimited connectivity with free
> > bandwidth any more?  Koha support providers?
>
> Unlimited bandwidth is not required.  Demand for source code will always
> be finite.
>
> I will post the questions which I put to Aaron about obligations and
> liability which included your specific question about whether to stop
> remote network use of a program under AGPL 3 when the source code server
> goes offline.
>
> >
> >> >> 3.1.1.4.  SOURCE CODE HOSTING SERVICE REMEDY.
> >>
> >> [...]
> >> > Plus, this brings in my secondary concern of whether the hosted Koha
> >> > should go offline whenever the source code hosting service is offline.
> >> > Please would you ask that, or should I?
> >>
> >> I will ask the question, although, you are welcome to ask yourself.
> >> [...]
> >
> > Thank you.  I will cc you if/when I get to asking it.
>
> I asked this question of Aaron in my message to him last week.
>
> >
> >> [...]  Additionally,
> >> Koha support companies could provide source code hosting services and
> >> indemnify their customers against copyright violations of the software
> >> license for all cases except gross negligence by the customer.
> >
> > I've looked into the prices of such indemnity guarantees in the past
> > and no client has been interested once told the price!
>
> Indemnity may be granted without assessing a price.  If a source code
> hosting service is providing a service, then they may be able to assume
> associated risk.  Koha support companies may be in a position to have
> confidence about risks associated with Koha and assume those risks.
>
> >
> >> >> 3.1.1.5.  ALLOWED REMEDIES FOR OFFSETTING COSTS. [...]
> >> The token fee was meant as something for a source code hosting contract
> >> for a possible source code hosting service provided by Koha support
> >> companies even in the absence of any other support contract.
> >
> > But if you're using a hosting service without paying some consideration,
> > is a contract formed?  I thought that was why a token fee was mentioned.
>
> Yes, the token fee was my recognition from contract law of what would be
> necessary for a valid contract.  I had imagined a hosting service bound by
> at least a token fee where the hosting service would be doing the work of
> managing the source code repository directly for the library where
> automation should substantially eliminate the need for personal attention
> from people who cost money.  Such a service would be under the direction
> of the library with much responsibility transferred to the service.
>
> A service, such as Gitorious or GitHub, may be used for free software
> without paying any fee.  Using Gitorious or GitHub would require some
> knowledge of administering git.  Scripts which might be created to help
> the library automate the management of such a git repository would help.
> Such a service, would provide hosting of the source code but the
> repository would be more directly under the control of the library.
>
> There may be a scenario in which the library would be provided complete
> service by another party and would still retain complete control over
> everything to the fullest extent possible.
>
> I presume that the transference of responsibility via contract would
> require payment of at least a token fee where the retaining responsibility
> would not.  In all this I should state that I am not a lawyer, although, I
> have experience doing legal research at the direction of lawyers.  I have
> never researched contract law and have merely a well informed popular
> understanding of contract law.
>
> [...]
>
> >> Aaron had seemed to imply that parties with
> >> responsibilities for complying with the license need to control or
> >> direct
> >> their own compliance but could contract with others to provide such
> >> services.
> >
> > I think a market in compliance services is an evil bureaucrat's dream
> > and not something which the Koha community should encourage by picking
> > such an ununderstood licence.
>
> People at libraries should not be frightened or overly anxious about
> copyright liability.  Risks of copyright violation have to be managed for
> libraries every day.  Providing access to materials with or without copy
> machines exposes libraries to the risk of being sued for facilitating
> copyright infringement.  Library administrators unduly fearful of
> unreasonable action over any possible copyright violation would need to
> close the library.  Reasonable policies help manage risks and AGPL 3 would
> be a small addition to all the other risks of libraries which would be
> duly addressed.
>
> >> But maybe that's just my idealism
> > talking after looking into how commercial broadcasters in the UK
> > handle compliance by licensing it out to the smallest surviving
> > commercial network company (Channel Television, which serves the
> > 160,000 population of the Channel Islands) so that the fines are
> > limited (because the maximum is currently set at 5% of company
> > advertising income).
>
> If we would introduce an AGPL 3 version of Koha, support companies would
> not have the power of regulated broadcast monopolies.
>
> >
> >> >> 3.3.  SECURITY CONFIGURATION.
> >> > [...]
> >> Section 1 of the license clarifies the issue of automatic generation.
> >>
> >> "The Corresponding Source need not include anything that users can
> >> regenerate automatically from other parts of the Corresponding Source."
> >
> > I don't think that effective security settings can regenerate
> > automatically at the moment.  Maybe they should and this is a bug
> > in koha to report at bugs.koha-community.org which should block
> > AGPL 3 adoption.
>
> If we choose to upgrade to AGPL 3 for Koha 3.4, we should file some
> blocker bugs for issuing an AGPL 3 release until there is some automated
> support for complying with the license.  There would also be blocker bugs
> for Open NCIP and NCIP 2 code license compatibility We are at least
> several months from the prospect of a Koha 3.4 release with or without
> AGPL 3.
>
> >
> >> >> 3.4.  DATA.
> >> > [...]  Lack of
> >> >> such coverage in AGPL 3 is not a reason to object to AGPL 3 for an
> >> issue
> >> >> it could never have addressed with any certainty.
> >> >
> >> > Why not?
> >>
> >> Copyright licenses are only effective in the domain of copyright.
> >> Software licenses specifically are only effective for software. [...]
> >
> > That's a misleading place to cut.  I meant: why not object to AGPL 3
> > for *not* being a significant "measure of protection more against Koha
> > related code becoming locked up on a saas platform"?
>
> A copyright license is not a data contract.
>
> I think that your particular request that the copyright license should
> address more is similar to asking why apples are not oranges or oranges
> are not apples.  The fact that apples and oranges are not the same does
> not keep you from having both apples and oranges.  Maybe you have a clever
> way of making an apple/orange hybrid.  I would be happy to taste your
> hybrid, if you have one.
>
> >
> >> What AGPL 3 does do is allow users of software as a service to take the
> >> software which they have been using a server which they do not control
> >> and
> >> move it to a different server including their own server over which they
> >> would have complete control.
> >
> > AGPL 3 is much more limited than that.  Only the source code of the
> > one public-facing service can be taken.  Much other software,
> > including the database, may remain locked up.
>
> FSF is encouraging the development of software which uses a different
> database model ensuring that users can run a local copy of the database in
> which private information is encrypted but everyone can have a copy of the
> whole database.  We should consider the possibility of such a distributed
> design for Koha.  Such a distributed design may never be sufficiently
> efficient for Koha but the possibility should be considered.
>
> >
> > [...]
> >> Users are often all too ready to sign away their freedom.  We need to do
> >> our best to help them appreciate the benefits which freedom brings.
> >
> > I agree.  Moreover, it would give a much better return than upgrading
> > to a licence which doesn't address the main threat to this community
> > and brings with it significant uncertainty and extra hurdles.
> >
> >> >> 3.6.  COMPULSION OR COOPERATION.
> >> > [...]
> >> Some people including myself are actually reassured by the potential of
> >> enforcement if all else fails.  [...]
> >
> > It should be small comfort.  Based on the lack of will to take a stand
> > over easier-to-win smaller battles, I believe it would take something
> > absolutely massive for the licence to be enforced and locking-in
> > customers is below that "absolutely massive" level, so the only people
> > who will keep to the licence are those who would do the right thing
> > anyway.
> >
> > I'm not dwelling on topics in this strategic section now.
> >
> >> > [...]
> >> >> 3.7.  EFFECTIVENESS.
> >> [...] Other parties could have exercised some similar influence if
> >> they had the resources to invest.  [...]
> >
> > They couldn't because they also needed to be invited by the FSF.  Some
> > organisations were invited belatedly and others never were.
> >
> > I'm not dwelling on topics in this strategic section now.
>
> A commitment of sufficient resources to the process may well have produced
> an invitation to participate in a GPL 3 drafting discussion group.
>
> I recognise that the drafting process had significant problems which FSF
> should strive to improve for the next time FSF runs a license revision
> process.  The question is now which license serves the interests of the
> Koha community best.
>
> >
> >> >> 3.7.1.  MINIMAL STANDARD OF COMPLIANCE. [...]
> >> > On this point about whether obfuscated source is a net benefit or not,
> >> > I realise that my view is not universal and I accept that.
> >>
> >> Obfuscating source code has never been acceptable and is a violation of
> >> the GPL.
> >
> > I feel it's somewhat less clear-cut than that: if you're doing it to
> > hinder others, then it's a violation, but what about if the obfuscated
> > source code is their preferred form for modification?  One person's
> > neat coding that ignores community code guidelines is another's
> > obfuscation.
>
> The biggest problem in this regard is machine optimisation of source code
> which can be a form of obfuscation for humans attempting to read the code,
> especially when variables are renamed to one character.  The prospect of
> legal discovery that the optimised form is not the form actually used for
> development should help reduce the temptation to convey machine optimised
> code as if it would be the Corresponding Source.  Machine optimised code
> is generally object code.
>
> [...]
>
> Thomas Dukleth
> Agogme
> 109 E 9th Street, 3D
> New York, NY  10003
> USA
> http://www.agogme.com
> +1 212-674-3783
>
>
>
> ------------------------------
>
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>
>
> End of Koha Digest, Vol 57, Issue 34
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.katipo.co.nz/pipermail/koha/attachments/20100713/8740aba1/attachment-0001.htm 