[Koha] Support for Koha

[Kyle Hall]

MJ wrote:
>Yes, I feel anyone commissioning Koha hosting should probably add a
>clause that requires they get a copy of the exact version used in the
>hosting and access to all their data and configuration files on
>demand, so they can host it on their own server if they want.  Maybe
>we should add a "download all" link in the Tools section and mention
>it in the official manual?  If that's missing/disabled, users will
>know to start plotting an escape.

Wouldn't this be a good use for the AGPL? Have any notable projects
switched to the Affero GPL license?

Kyle

http://www.kylehall.info
Information Technology
Crawford County Federated Library System ( http://www.ccfls.org )




On Wed, Aug 5, 2009 at 8:43 AM, MJ Ray<mjr at phonecoop.coop> wrote:
> Joshua Ferraro <jmf at liblime.com> wrote: [...]
>> Since this has turned into an attack on LibLime I feel I must state
>> for the record that, as far as I know, LibLime is the ONLY vendor that
>> has historically contributed 100% of our code as soon as it was
>> approved by a customer's quality assurance testing.
>
> Probably that's correct because I think several vendors are publishing
> 100% of their code as soon as it gets past their own QA!
>
> I think software.coop is the only Koha vendor whose governing rules
> commit us "to inform the general public - particularly young people
> and opinion leaders - about the nature and benefits" of Koha's
> development model; and "work for the sustainable development" of our
> communities. Yes, that's really in our company mission, as submitted
> to our national registration bodies.  In short, we're a good
> cooperative.  In our last evaluation (2008), we were achieving 69% of
> these goals and we're improving each year.
>
>> As far as I know,
>> every other vendor in the Koha community intentionally withholds
>> customizations that are only available to their customers, or don't
>> take the time to fully integrate their code into the mainline Koha
>> codebase (understandably so, as this either gives them a competitive
>> edge, or they simply don't have time to contribute it).
>
> Well, software.coop forked 3.0 many moons ago because we made the
> mistake of promising the announced 3.0 release date plus a few months
> slack to a customer, so we needed to stabilise it quickly and
> disagreed on some principles. We've been fairly open about that and we
> will reconcile that fork.  It looks like the features will merge into
> 3.2 and not 3.0 now.
>
> Even though it's not on the mainline, the code is normally available,
> although we've had a few services die on us and not really publicised
> it - so now we plan to introduce git.software.coop for public hosting
> but I don't know when we'll get resources for that.
>
> There's also some development code which isn't public because early
> drafts contain authentication details and things like that which we
> can't publish, but it's normally described in enhancement bug reports
> on bugs.koha.org - unlike a vendor whose apparently-similar work we
> only learnt about when someone tweeted from their conference sessions!
>
>> [...] So, companies who
>> host Koha in a software as a service environment are not obligated to
>> redistribute their code to the community (which is why so many Koha
>> vendors are able to withhold their code).
>
> Yes, I feel anyone commissioning Koha hosting should probably add a
> clause that requires they get a copy of the exact version used in the
> hosting and access to all their data and configuration files on
> demand, so they can host it on their own server if they want.  Maybe
> we should add a "download all" link in the Tools section and mention
> it in the official manual?  If that's missing/disabled, users will
> know to start plotting an escape.
>
> [...]
>> Also, for the record, as requested by LibLime's customers, the LibLime
>> Users's Group list is a closed list, so messages sent to that list
>> should NOT be forwarded to the general Koha list, or anywhere else.
>
> Yes, that's not good.  On lists I run, I change the standard footer to
> something which mentions restrictions like that, but it's hard to put
> these back in private once published.
>
> Best wishes,
> --
> MJ Ray (slef)  LMS developer and webmaster at     | software
> www.software.coop http://mjr.towers.org.uk        |  .... co
> IMO only: see http://mjr.towers.org.uk/email.html |  .... op
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>