[Koha] Support for Koha

[savitra sirohi]

I know - otrs (http://www.otrs.org), an excellent open source ticket
system -  has released it's latest version on AGPL, specifically to
address the "ASP loophole".

On 8/5/09, Kyle Hall <kyle.m.hall at gmail.com> wrote:
> 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
>>
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>