Liblime, Koha, BibLibre and FLOSS
Hello everyone, Following the thread on Library Journal's article "LibLime's Enterprise Koha Sets Off Debate" (http://www.libraryjournal.com/article/CA6700348.html) we at BibLibre posted an article on our web site about this issue: http://www.biblibre.com/content/liblime-koha-biblibre-and-floss Cheers, Nicolas -- Nicolas Morin Mobile: +33(0)633 19 11 36 http://www.biblibre.com
Nicolas Morin <nicolas.morin@biblibre.com>
[...] we at BibLibre posted an article on our web site about this issue: http://www.biblibre.com/content/liblime-koha-biblibre-and-floss
Amongst other things, that says: "BibLibre decided we needed to modify our standard hosting contract to close the GPL loophole used by LibLime: in our future contracts, and when the current contracts are renewed, an extra article is added to the contract which specifies that even though the software is hosted, the library has access to the source code, GPLed." I'm surprised because software.coop's usual contract terms have said that we "grant permission to the Buyer to use, copy, modify, adapt or enhance the material supplied in the performance of the Services, so far as [the co-op] is permitted to grant that permission" since at least 2006 and probably before (I'd need to check paper files to be sure). For Koha, that means you get a copy under the GPL, basically. What with all the flaming of LibLime for hosting lock-in, I didn't expect that other Koha vendors weren't making at least that promise already. So - would the other vendors like to state their current contract permissions? Anyone else want to follow the co-op and BibLibre and make this promise to your buyers? Also, I'd like to know whether anyone else's hosting-source-access clause forbids evil tricks like public key encryption? Offering access alone isn't sufficient. Also, what about the data? Thanks, -- MJ Ray (slef) Webmaster and LMS developer at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op
2009/10/23 MJ Ray <mjr@phonecoop.coop>:
Nicolas Morin <nicolas.morin@biblibre.com>
[...] we at BibLibre posted an article on our web site about this issue: http://www.biblibre.com/content/liblime-koha-biblibre-and-floss
Amongst other things, that says:
"BibLibre decided we needed to modify our standard hosting contract to close the GPL loophole used by LibLime: in our future contracts, and when the current contracts are renewed, an extra article is added to the contract which specifies that even though the software is hosted, the library has access to the source code, GPLed."
I'm surprised because software.coop's usual contract terms have said that we "grant permission to the Buyer to use, copy, modify, adapt or enhance the material supplied in the performance of the Services, so far as [the co-op] is permitted to grant that permission" since at least 2006 and probably before (I'd need to check paper files to be sure).
For Koha, that means you get a copy under the GPL, basically.
What with all the flaming of LibLime for hosting lock-in, I didn't expect that other Koha vendors weren't making at least that promise already. So - would the other vendors like to state their current contract permissions? Anyone else want to follow the co-op and BibLibre and make this promise to your buyers?
Also, I'd like to know whether anyone else's hosting-source-access clause forbids evil tricks like public key encryption? Offering access alone isn't sufficient. Also, what about the data?
As far as Im aware Liblime is the only vendor in the history of Koha, certainly the only vendor listed on the Koha support page, to refuse to give the source code, and database access to their customers. For me thats where the flames are coming from. I will find out what the Catalyst contracts say, but we don't have and Software as a Service Koha clients, they are all self hosted. But I will look just for curiosity sake. Chris
Maybe access to the source of in-house modifications should be a requirement for being a listed vendor on the site? We may not be able to alter the terms of the GPL, but we can decide the terms of koha.org ( assuming we have and will have that much control over it ). I would expect that we would have to grandfather all current vendors though. Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) On Thu, Oct 22, 2009 at 1:35 PM, MJ Ray <mjr@phonecoop.coop> wrote:
Nicolas Morin <nicolas.morin@biblibre.com>
[...] we at BibLibre posted an article on our web site about this issue: http://www.biblibre.com/content/liblime-koha-biblibre-and-floss
Amongst other things, that says:
"BibLibre decided we needed to modify our standard hosting contract to close the GPL loophole used by LibLime: in our future contracts, and when the current contracts are renewed, an extra article is added to the contract which specifies that even though the software is hosted, the library has access to the source code, GPLed."
I'm surprised because software.coop's usual contract terms have said that we "grant permission to the Buyer to use, copy, modify, adapt or enhance the material supplied in the performance of the Services, so far as [the co-op] is permitted to grant that permission" since at least 2006 and probably before (I'd need to check paper files to be sure).
For Koha, that means you get a copy under the GPL, basically.
What with all the flaming of LibLime for hosting lock-in, I didn't expect that other Koha vendors weren't making at least that promise already. So - would the other vendors like to state their current contract permissions? Anyone else want to follow the co-op and BibLibre and make this promise to your buyers?
Also, I'd like to know whether anyone else's hosting-source-access clause forbids evil tricks like public key encryption? Offering access alone isn't sufficient. Also, what about the data?
Thanks, -- MJ Ray (slef) Webmaster and LMS developer 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@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Reply inline: On Thu, October 22, 2009 19:53, Kyle Hall wrote:
Maybe access to the source of in-house modifications should be a requirement for being a listed vendor on the site? We may not be able to alter the terms of the GPL, but we can decide the terms of koha.org ( assuming we have and will have that much control over it ). I would expect that we would have to grandfather all current vendors though.
I respond at the risk of great controversy but we have already seen what trouble grandfathered treatment has caused in the Koha community and we should be more careful in future. [Please remember to be calm, civil, and respectful in any replies.] There are altogether too many exclusionary rules already for being listed on the 'pay for support' page . There may even be legal hazard from any possible mishap with a litigious library for certifying competence in a world of human frailty if the Koha community might be understood to function as a trade association in some legal jurisdictions which had certified the qualifications of some members. I presume we are now moving away from a process where one support company or a small group of support companies would exercise exclusive control over what appears on the community website. I would prefer banning all mention of paid support services from the community website to the nonsensical treatment which has come regarding listing support service companies in the past year. I am not recommending such a ban but merely identifying what a problem the issue has been. The very thing we should avoid is grandfathering, meaning exempting, anyone from the rules. Any rules worth having are rules which should be applied equally to all. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783
* Thomas Dukleth (kohalist@agogme.com) wrote:
Reply inline:
On Thu, October 22, 2009 19:53, Kyle Hall wrote:
Maybe access to the source of in-house modifications should be a requirement for being a listed vendor on the site? We may not be able to alter the terms of the GPL, but we can decide the terms of koha.org ( assuming we have and will have that much control over it ). I would expect that we would have to grandfather all current vendors though.
I respond at the risk of great controversy but we have already seen what trouble grandfathered treatment has caused in the Koha community and we should be more careful in future.
[Please remember to be calm, civil, and respectful in any replies.]
There are altogether too many exclusionary rules already for being listed on the 'pay for support' page . There may even be legal hazard from any possible mishap with a litigious library for certifying competence in a world of human frailty if the Koha community might be understood to function as a trade association in some legal jurisdictions which had certified the qualifications of some members.
I presume we are now moving away from a process where one support company or a small group of support companies would exercise exclusive control over what appears on the community website.
I would prefer banning all mention of paid support services from the community website to the nonsensical treatment which has come regarding listing support service companies in the past year. I am not recommending such a ban but merely identifying what a problem the issue has been.
The very thing we should avoid is grandfathering, meaning exempting, anyone from the rules. Any rules worth having are rules which should be applied equally to all.
Hear Hear! I would much prefer we list all those who apply, with no judgement or order inferred, than the current mess. And that whatever rules there are, are applied equally to all. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
I would prefer banning all mention of paid support services from the community website to the nonsensical treatment which has come regarding listing support service companies in the past year. I am not recommending such a ban but merely identifying what a problem the issue has been.
Hear Hear!
I would much prefer we list all those who apply, with no judgement or order inferred, than the current mess.
And that whatever rules there are, are applied equally to all.
yep, i agree or as others on the koha-lists have asked - order the support- companies *alphabetically* as Katipo did originally,
There are altogether too many exclusionary rules already for being listed on the 'pay for support' page . There may even be legal hazard from any possible mishap with a litigious library for certifying competence in a world of human frailty if the Koha community might be understood to function as a trade association in some legal jurisdictions which had certified the qualifications of some members.
I don't think the vendor listing has ever made claims about competence.
I presume we are now moving away from a process where one support company or a small group of support companies would exercise exclusive control over what appears on the community website.
I believe that is the goal.
I would prefer banning all mention of paid support services from the community website to the nonsensical treatment which has come regarding listing support service companies in the past year. I am not recommending such a ban but merely identifying what a problem the issue has been.
I like Chris's idea better. List everyone who applies, without judgment. Maybe even randomize the list on each view. I believe that removing the vendor list would definitely hurt the project itself. Right now, if a library is interested, they have one page where they can find every koha vendor ( at least all the one's serious enough to get listed. )
The very thing we should avoid is grandfathering, meaning exempting, anyone from the rules. Any rules worth having are rules which should be applied equally to all.
As long as Liblime is the only entity with complete control over koha.org, that's not going to happen. Kyle
On Fri, Oct 23, 2009 at 7:24 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
I would prefer banning all mention of paid support services from the community website to the nonsensical treatment which has come regarding listing support service companies in the past year. I am not recommending such a ban but merely identifying what a problem the issue has been.
I like Chris's idea better. List everyone who applies, without judgment. Maybe even randomize the list on each view. I believe that removing the vendor list would definitely hurt the project itself. Right now, if a library is interested, they have one page where they can find every koha vendor ( at least all the one's serious enough to get listed. )
Just to add another idea about the organization of the vendor listing page - why not create a map - then it's not random and it's not alpha - you zoom into your country and see who's there - just an idea since I just finished teaching my mashups workshop and we talked about map mashups :)
The very thing we should avoid is grandfathering, meaning exempting, anyone from the rules. Any rules worth having are rules which should be applied equally to all.
As long as Liblime is the only entity with complete control over koha.org, that's not going to happen.
The idea is that this is going to change - we're going to form a committee and work with the group we choose in the survey to control Koha assets. Nicole
Just to add another idea about the organization of the vendor listing page - why not create a map - then it's not random and it's not alpha - you zoom into your country and see who's there - just an idea since I just finished teaching my mashups workshop and we talked about map mashups :)
Fantastic idea! Nicole++
The very thing we should avoid is grandfathering, meaning exempting, anyone from the rules. Any rules worth having are rules which should be applied equally to all.
As long as Liblime is the only entity with complete control over koha.org, that's not going to happen.
The idea is that this is going to change - we're going to form a committee and work with the group we choose in the survey to control Koha assets.
Indeed. I suppose that the proper solution to changing the listing rules is to have all listed vendors agree to all the changes to make sure they are aware and still in compliance.
Nicole
Great Idea Nicole... I must second this idea of creating maps for vendors Regards, Ata ur Rehman, www.lisolutions.org 2009/10/23 Nicole Engard <nengard@gmail.com>
On Fri, Oct 23, 2009 at 7:24 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
I would prefer banning all mention of paid support services from the community website to the nonsensical treatment which has come regarding listing support service companies in the past year. I am not recommending such a ban but merely identifying what a problem the issue has been.
I like Chris's idea better. List everyone who applies, without judgment. Maybe even randomize the list on each view. I believe that removing the vendor list would definitely hurt the project itself. Right now, if a library is interested, they have one page where they can find every koha vendor ( at least all the one's serious enough to get listed. )
Just to add another idea about the organization of the vendor listing page - why not create a map - then it's not random and it's not alpha - you zoom into your country and see who's there - just an idea since I just finished teaching my mashups workshop and we talked about map mashups :)
The very thing we should avoid is grandfathering, meaning exempting, anyone from the rules. Any rules worth having are rules which should be applied equally to all.
As long as Liblime is the only entity with complete control over koha.org, that's not going to happen.
The idea is that this is going to change - we're going to form a committee and work with the group we choose in the survey to control Koha assets.
Nicole
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Hi Nicole, 2009/10/23 Nicole Engard <nengard@gmail.com>:
On Fri, Oct 23, 2009 at 7:24 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
I would prefer banning all mention of paid support services from the community website to the nonsensical treatment which has come regarding listing support service companies in the past year. I am not recommending such a ban but merely identifying what a problem the issue has been.
I like Chris's idea better. List everyone who applies, without judgment. Maybe even randomize the list on each view. I believe that removing the vendor list would definitely hurt the project itself. Right now, if a library is interested, they have one page where they can find every koha vendor ( at least all the one's serious enough to get listed. )
Just to add another idea about the organization of the vendor listing page - why not create a map - then it's not random and it's not alpha - you zoom into your country and see who's there - just an idea since I just finished teaching my mashups workshop and we talked about map mashups :)
The very thing we should avoid is grandfathering, meaning exempting, anyone from the rules. Any rules worth having are rules which should be applied equally to all.
As long as Liblime is the only entity with complete control over koha.org, that's not going to happen.
The idea is that this is going to change - we're going to form a committee and work with the group we choose in the survey to control Koha assets.
Nicole
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
+1
Nicole Engard a écrit :
As long as Liblime is the only entity with complete control over koha.org <http://koha.org>, that's not going to happen.
The idea is that this is going to change - we're going to form a committee and work with the group we choose in the survey to control Koha assets.
You'll be surprised, but my vote is -1 : that could let ppl think noone can provide commercial support in their area, which is not the case. And being in a given country does not mean you work only in this country. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Sun, Oct 25, 2009 at 12:59 PM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Nicole Engard a écrit :
As long as Liblime is the only entity with complete control over koha.org <http://koha.org>, that's not going to happen.
The idea is that this is going to change - we're going to form a committee and work with the group we choose in the survey to control Koha assets.
You'll be surprised, but my vote is -1 : that could let ppl think noone can provide commercial support in their area, which is not the case. And being in a given country does not mean you work only in this country.
This tendency could be offset by a simple note to the effect that many/all of these companies provide international support for Koha. Kind Regards, Chris
There was much discussion of the issue of the arrangement of listings on the pay for support page in May, when LibLime introduced the new Plone based website. I think that it is the least important part of the koha.org website, although, understandably it was highly contentious part of discussions in May. The most important comment I have to make on the issue is that we should not be telling the user what the user should value most as a criteria for arranging support companies. There was some support in May for offering multiple views of support company listings and allowing every user to use one more allowing each to satisfy his own particular interests. Publicly shared arrangement schemes should be both fair and useful. VARIOUS TYPES OF ARRANGEMENTS. Utility should be rationally related to the function provided. Quality of support services or various types of support services would be the most useful means of ordering but we have no fair objective means of measuring quality of support services. Such judgements are best left to the prospective customer. See section 3.2.1.1.5, "Rational schemes and irrational measures", in my first comment on the new Plone based website in May, http://lists.koha.org/pipermail/koha-devel/2009-May/009541.html . We should not pretend to measure what we cannot actually measure. Other less fundamental aspects of support services such as geographic and linguistic measures also entail a point of view about the arrangement of geographic areas or languages in any particular presentation. Geographic areas have to be ordered in some manner. Maps have an orientation and distortions of projection. One aspect of Paul Poulain's point about maps is that maps are liable to show empty regions unless all regions would be filled by those offering support services everywhere. Text based arrangement of geographical information avoids some problems of visual maps and should not be excluded from a geographical presentation. Languages have to be ordered in some manner. Historical arrangement may have value to some but it should actually be historical. The current arrangement on Koha.org is not historical. The alphabet is not a rational organisational scheme because it is strictly arbitrary by the happenstance of the placement of letters. It has the virtue of being universally understood. The arbitrary has the possibility of seeming fair by being impartial but fairness is not a necessary consequence of arbitrary impartiality. Trade naming choices can also be taken to ensure early placement in alphabetical ordering and undue fairness but we have not seen that problem in the Koha community. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 Original Subject: Re: [Koha] Liblime, Koha, BibLibre and FLOSS On Sun, October 25, 2009 18:36, Chris Nighswonger wrote:
On Sun, Oct 25, 2009 at 12:59 PM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Nicole Engard a écrit :
As long as Liblime is the only entity with complete control over koha.org <http://koha.org>, that's not going to happen.
The idea is that this is going to change - we're going to form a committee and work with the group we choose in the survey to control Koha assets.
You'll be surprised, but my vote is -1 : that could let ppl think noone can provide commercial support in their area, which is not the case. And being in a given country does not mean you work only in this country.
This tendency could be offset by a simple note to the effect that many/all of these companies provide international support for Koha.
Kind Regards, Chris _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
[Reposted with minor corrections including a spelling correction for the meaning intended.] There was much discussion of the issue of the arrangement of listings on the pay for support page in May, when LibLime introduced the new Plone based website. I think that it is the least important part of the koha.org website, although, understandably it was a highly contentious part of discussions in May. The most important comment I have to make on the issue is that we should not be telling the user what the user should value most as a criteria for arranging support companies. There was some support in May for offering multiple views of support company listings and allowing every user to use one more allowing each to satisfy his own particular interests. Publicly shared arrangement schemes should be both fair and useful. VARIOUS TYPES OF ARRANGEMENTS. Utility should be rationally related to the function provided. Quality of support services or various types of support services would be the most useful means of ordering but we have no fair objective means of measuring quality of support services. Such judgements are best left to the prospective customer. See section 3.2.1.1.5, "Rational schemes and irrational measures", in my first comment on the new Plone based website in May, http://lists.koha.org/pipermail/koha-devel/2009-May/009541.html . We should not pretend to measure what we cannot actually measure. Other less fundamental aspects of support services such as geographic and linguistic measures also entail a point of view about the arrangement of geographic areas or languages in any particular presentation. Geographic areas have to be ordered in some manner. Maps have an orientation and distortions of projection. One aspect of Paul Poulain's point about maps is that maps are liable to show empty regions unless all regions would be filled by those offering support services everywhere. Text based arrangement of geographical information avoids some problems of visual maps and should not be excluded from a geographical presentation. Languages have to be ordered in some manner. Historical arrangement may have value to some but it should actually be historical. The current arrangement on Koha.org is not historical. Alphabetical arrangement is not a rational organisational scheme because it is strictly arbitrary by the happenstance of the placement of letters. It has the virtue of being universally understood. The arbitrary has the possibility of seeming fair by being impartial but fairness is not a necessary consequence of arbitrary impartiality. Trade naming choices can also be taken to ensure early placement in alphabetical ordering and undo fairness but we have not seen that problem in the Koha community. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 Original Subject: Re: [Koha] Liblime, Koha, BibLibre and FLOSS On Sun, October 25, 2009 18:36, Chris Nighswonger wrote:
On Sun, Oct 25, 2009 at 12:59 PM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Nicole Engard a écrit :
As long as Liblime is the only entity with complete control over koha.org <http://koha.org>, that's not going to happen.
The idea is that this is going to change - we're going to form a committee and work with the group we choose in the survey to control Koha assets.
You'll be surprised, but my vote is -1 : that could let ppl think noone can provide commercial support in their area, which is not the case. And being in a given country does not mean you work only in this country.
This tendency could be offset by a simple note to the effect that many/all of these companies provide international support for Koha.
Kind Regards, Chris _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Hi all, A map view of listed commercial support receives a + 1 from me. Some libraries will choose to work alone, others with a local Koha service provider, others will scan the global skills base. When looking for support, most clients look for a specific blend of: experience, languages spoken, rates, availability, packaged services, involvement with the Koha Project, the F/OSS Community, prior recommendations, etc to match their specific situation and needs with the offerings of a service provider. Listed vendors usually mention their physical geographical location and if they work with libraries located elsewhere. Perhaps even adding on their website a map showing the location of their clients .... I love maps! Yes, and used to love cataloguing maps of all types and projections! ... Best regards, Irma CALYX information essentials
One difficulty I can identify: some vendors have multiple locations. 1. Does each location get a 'pin'? How is a location defined (do home offices count, or only the company office)? Do 'pins' have weight? Wouldn't that essentially give geographically diverse vendors more entries, and might that not be considered unfair to geographically-localized vendors? 2. Paul brings up a good point: geographic location is less important in a web-based environment. If a region doesn't have a 'pin' nearby, that doesn't mean it can't get a contract; nor is a library required to contract with the nearest vendor. I like the idea of a map, because it is less arbitrarily ordered than a list. If we can agree on a fair way to represent vendors on such a map, then great. Perhaps it makes more sense to encode the critical vendor info in a database table or XML document, and then provide multiple interfaces for viewing that data. That way, prospective customers can view the vendor list in terms that are relevant to them at the time. I'd be happy to help work on the data structure and interface design for that. Cheers, Ian Walls Systems Integration Librarian NYU Health Sciences Libraries 550 First Ave., New York, NY 10016 (212) 263-8687 -----Original Message----- From: koha-bounces@lists.katipo.co.nz [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Irma Birchall Sent: Sunday, October 25, 2009 7:11 PM To: koha@lists.katipo.co.nz Subject: Re: [Koha] A map showing Koha "Pay for support" companies - Was subject: Re: Liblime, Koha, BibLibre and FLOSS Hi all, A map view of listed commercial support receives a + 1 from me. Some libraries will choose to work alone, others with a local Koha service provider, others will scan the global skills base. When looking for support, most clients look for a specific blend of: experience, languages spoken, rates, availability, packaged services, involvement with the Koha Project, the F/OSS Community, prior recommendations, etc to match their specific situation and needs with the offerings of a service provider. Listed vendors usually mention their physical geographical location and if they work with libraries located elsewhere. Perhaps even adding on their website a map showing the location of their clients .... I love maps! Yes, and used to love cataloguing maps of all types and projections! ... Best regards, Irma CALYX information essentials _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha ------------------------------------------------------------ This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is proprietary, confidential, and exempt from disclosure under applicable law. Any unauthorized review, use, disclosure, or distribution is prohibited. If you have received this email in error please notify the sender by return email and delete the original message. Please note, the recipient should check this email and any attachments for the presence of viruses. The organization accepts no liability for any damage caused by any virus transmitted by this email. =================================
Kyle Hall a écrit :
The very thing we should avoid is grandfathering, meaning exempting, anyone from the rules. Any rules worth having are rules which should be applied equally to all.
As long as Liblime is the only entity with complete control over koha.org, that's not going to happen.
You get a point here. We can't even access download.koha.org, we can't modify anything on koha.org, except if a company that has left the community decide to accept or do the changes we want. The next question is: how could we retrieve some control over koha.org? the short answer here is = we can't. The next question is: what do we do now? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
The next question is: what do we do now? Change the name of the project, register new URLs and trademarks. Take control of our own community.
Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) On Fri, Oct 23, 2009 at 9:03 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Kyle Hall a écrit :
The very thing we should avoid is grandfathering, meaning exempting, anyone from the rules. Any rules worth having are rules which should be applied equally to all.
As long as Liblime is the only entity with complete control over koha.org, that's not going to happen.
You get a point here. We can't even access download.koha.org, we can't modify anything on koha.org, except if a company that has left the community decide to accept or do the changes we want. The next question is: how could we retrieve some control over koha.org? the short answer here is = we can't. The next question is: what do we do now?
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Is it inconceivable that the community will not have the Koha name back to use? On Oct 23, 2009, at 10:09 AM, Kyle Hall wrote:
The next question is: what do we do now? Change the name of the project, register new URLs and trademarks. Take control of our own community.
Kyle
http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
On Fri, Oct 23, 2009 at 9:03 AM, Paul Poulain <paul.poulain@biblibre.com
wrote: Kyle Hall a écrit :
The very thing we should avoid is grandfathering, meaning exempting, anyone from the rules. Any rules worth having are rules which should be applied equally to all.
As long as Liblime is the only entity with complete control over koha.org, that's not going to happen.
You get a point here. We can't even access download.koha.org, we can't modify anything on koha.org, except if a company that has left the community decide to accept or do the changes we want. The next question is: how could we retrieve some control over koha.org? the short answer here is = we can't. The next question is: what do we do now?
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Hi to all,
The next question is: how could we retrieve some control over koha.org? the short answer here is = we can't. The next question is: what do we do now?
we need to register a new site, put all info / manual/FAQ/ect. here, tell to everyone that there is a new koha site and de-link koha.org. Who do control wiki.koha.org ? Bye
tajoli a écrit :
Hi to all,
The next question is: how could we retrieve some control over koha.org? the short answer here is = we can't. The next question is: what do we do now?
we need to register a new site, put all info / manual/FAQ/ect. here, tell to everyone that there is a new koha site and de-link koha.org.
Who do control wiki.koha.org ?
Everything is under LL hands. Except mailing lists, that we host (but we don't manage the DNS, it's LL ). -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Hi everyone, When I finished work yesterday it looked highly likely that Horowhenua Library Trust would be the prefeered option for hlding the community 'assets' in safe hands until a long term solution is arrived at. May I ask that the Trust is given a little time to contact Liblime directly, offlist, and invite Joshua to handover his assets. He has always said he will do this and I am optimistic that he will honour his word. He has been a long serving, highly respected and valued member of the Koha Community, aside from this little blip, and I think we owe him and Horowhenua Library Trust a little space to quietly sort this out. Does that sound acceptle? May I ask for 1 months 'space' to work with Joshua directly? Kind regards Joann Ransom. On Sat, Oct 24, 2009 at 4:01 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
tajoli a écrit :
Hi to all,
The next question is: how could we retrieve some control over koha.org? the short answer here is = we can't. The next question is: what do we do now?
we need to register a new site, put all info / manual/FAQ/ect. here, tell to everyone that there is a new koha site and de-link koha.org.
Who do control wiki.koha.org ?
Everything is under LL hands. Except mailing lists, that we host (but we don't manage the DNS, it's LL ).
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Joann Ransom RLIANZA Acting Head of Libraries, Horowhenua Library Trust.
Excellent idea, Joann. I think some direct communication between Josh and HLT (or whomever is voted in) is just what is needed. Lori Ayre 2009/10/23 Joann Ransom <jransom@library.org.nz>
Hi everyone,
When I finished work yesterday it looked highly likely that Horowhenua Library Trust would be the prefeered option for hlding the community 'assets' in safe hands until a long term solution is arrived at.
May I ask that the Trust is given a little time to contact Liblime directly, offlist, and invite Joshua to handover his assets. He has always said he will do this and I am optimistic that he will honour his word. He has been a long serving, highly respected and valued member of the Koha Community, aside from this little blip, and I think we owe him and Horowhenua Library Trust a little space to quietly sort this out.
Does that sound acceptle? May I ask for 1 months 'space' to work with Joshua directly?
Kind regards
Joann Ransom.
On Sat, Oct 24, 2009 at 4:01 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
tajoli a écrit :
Hi to all,
The next question is: how could we retrieve some control over koha.org? the short answer here is = we can't. The next question is: what do we do now?
we need to register a new site, put all info / manual/FAQ/ect. here, tell to everyone that there is a new koha site and de-link koha.org.
Who do control wiki.koha.org ?
Everything is under LL hands. Except mailing lists, that we host (but we don't manage the DNS, it's LL ).
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Joann Ransom RLIANZA Acting Head of Libraries, Horowhenua Library Trust.
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
I also agree with Joann Ransom that whatever entity would be designated by the election to legally hold Koha assets for the community should be the party making requests of various parties for consolidating community assets. Time should be given to allow needed discussions between the parties. The Koha community should be ready with an alternative if things go wrong but we should not presume an outcome in advance. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 On Fri, October 23, 2009 20:51, Lori Ayre wrote:
Excellent idea, Joann. I think some direct communication between Josh and HLT (or whomever is voted in) is just what is needed.
Lori Ayre
2009/10/23 Joann Ransom <jransom@library.org.nz>
Hi everyone,
When I finished work yesterday it looked highly likely that Horowhenua Library Trust would be the prefeered option for hlding the community 'assets' in safe hands until a long term solution is arrived at.
May I ask that the Trust is given a little time to contact Liblime directly, offlist, and invite Joshua to handover his assets. He has always said he will do this and I am optimistic that he will honour his word. He has been a long serving, highly respected and valued member of the Koha Community, aside from this little blip, and I think we owe him and Horowhenua Library Trust a little space to quietly sort this out.
Does that sound acceptle? May I ask for 1 months 'space' to work with Joshua directly?
Kind regards
Joann Ransom.
On Sat, Oct 24, 2009 at 4:01 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
tajoli a écrit :
Hi to all,
The next question is: how could we retrieve some control over koha.org? the short answer here is = we can't. The next question is: what do we do now?
we need to register a new site, put all info / manual/FAQ/ect. here, tell to everyone that there is a new koha site and de-link koha.org.
Who do control wiki.koha.org ?
Everything is under LL hands. Except mailing lists, that we host (but we don't manage the DNS, it's LL ).
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Joann Ransom RLIANZA Acting Head of Libraries, Horowhenua Library Trust.
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Hi Joann, 2009/10/23 Joann Ransom <jransom@library.org.nz>:
Hi everyone,
When I finished work yesterday it looked highly likely that Horowhenua Library Trust would be the prefeered option for hlding the community 'assets' in safe hands until a long term solution is arrived at.
May I ask that the Trust is given a little time to contact Liblime directly, offlist, and invite Joshua to handover his assets. He has always said he will do this and I am optimistic that he will honour his word. He has been a long serving, highly respected and valued member of the Koha Community, aside from this little blip, and I think we owe him and Horowhenua Library Trust a little space to quietly sort this out.
Does that sound acceptle? May I ask for 1 months 'space' to work with Joshua directly?
This is exactly what should happen and what I would think would be high on our list of expectations for HLT as the single point of representation for the Koha community. Other than this tangent (and we must honestly acknowledge the extremity of it), Joshua and his company have been both respected and highly valued community members (this has probably made the reaction to the issue greater by at least a magnitude), and I would expect Joshua to honor his word as he should. If he does not, I would be very concerned if I were a customer of his. Dishonesty is not a commendable character trait. I think a month is a reasonable time period to allow the issues to be resolved. However, I also think we must set a deadline and stick to it. (Failure to set and adhere to deadlines probably contributed heavily to the current situation. We should learn from our own history so that we will not be doomed to repeat it.) Kind Regards, Chris
Both utukoha.org and kokohu.org are available. On Fri, Oct 23, 2009 at 10:19 AM, Erik Lewis <elewis@ngrl.org> wrote:
Is it inconceivable that the community will not have the Koha name back to use?
On Oct 23, 2009, at 10:09 AM, Kyle Hall wrote:
The next question is: what do we do now? Change the name of the project, register new URLs and trademarks. Take control of our own community.
Kyle
http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
On Fri, Oct 23, 2009 at 9:03 AM, Paul Poulain <paul.poulain@biblibre.com
wrote: Kyle Hall a écrit :
The very thing we should avoid is grandfathering, meaning exempting, anyone from the rules. Any rules worth having are rules which should be applied equally to all.
As long as Liblime is the only entity with complete control over koha.org, that's not going to happen.
You get a point here. We can't even access download.koha.org, we can't modify anything on koha.org, except if a company that has left the community decide to accept or do the changes we want. The next question is: how could we retrieve some control over koha.org? the short answer here is = we can't. The next question is: what do we do now?
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Maybe access to the source of in-house modifications should be a requirement for being a listed vendor on the site? We may not be able to alter the terms of the GPL, but we can decide the terms of koha.org One thing recent events have shown is that as a community we cannot guarantee that a vendor will will act tomorrow as they act today. Or
On 10/22/2009 08:53 PM, Kyle Hall wrote: that a large vendor may not suddenly decide to bring its weight into the library market (think microsoft as a worst case, or maybe the company that does the payroll and backoffice for your institution wants to add a library package addon). As such we have to depend on the licensing terms of the software we rely on to do our work and the freedoms, rights and responsibilities that they grant us. It's not a problem that is peculiar to this project and we can benefit from the work of the greater free software community. We should seriously be looking at whether we should alter the licence for future contributions to Koha (and I think we may well find ourselves at the beginning of a period of major growth now). The Free Software Foundation already promote a licence that closes the Software as a Service gap, see the annoucement here:
http://www.fsf.org/blogs/licensing/2007-03-29-gplv3-saas and the actual license here http://www.gnu.org/licenses/agpl-3.0.html
whether this is the way to go or not the freedoms in the GPL have been a good foundation to the growth of this community. I think we need to ensure they are carried on to future users and it is a subject we need to give serious attention to Colin -- Colin Campbell Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com
Colin Campbell wrote:
Maybe access to the source of in-house modifications should be a requirement for being a listed vendor on the site? We may not be able to alter the terms of the GPL, but we can decide the terms of koha.org One thing recent events have shown is that as a community we cannot guarantee that a vendor will will act tomorrow as they act today. Or
On 10/22/2009 08:53 PM, Kyle Hall wrote: that a large vendor may not suddenly decide to bring its weight into the library market (think microsoft as a worst case, or maybe the company that does the payroll and backoffice for your institution wants to add a library package addon). As such we have to depend on the licensing terms of the software we rely on to do our work and the freedoms, rights and responsibilities that they grant us.
These are social challenges and any legal-only solution will not work well in practice. Relying only on the licensing would allow privately-owned companies that comply with the letter of the licence while not joining in the spirit of the community to exploit the community. It is essential that we bring social measures into play in a more library-involving, less legalistic way than the Koha project has for some time.
[...] We should seriously be looking at whether we should alter the licence for future contributions to Koha (and I think we may well find ourselves at the beginning of a period of major growth now). The Free Software Foundation already promote a licence that closes the Software as a Service gap, see the annoucement here:
http://www.fsf.org/blogs/licensing/2007-03-29-gplv3-saas and the actual license here http://www.gnu.org/licenses/agpl-3.0.html whether this is the way to go or not the freedoms in the GPL have been a good foundation to the growth of this community. I think we need to ensure they are carried on to future users and it is a subject we need to give serious attention to
Please read the list archives. I looked at it seriously during its drafting and, personally, I feel that AGPL is a bogus licence, based on the absurd idea that one can "ensure cooperation" with contract-based compulsion when it has been well-known for over 70 years that true cooperation is voluntary. See for example http://www.ica.coop/coop/principles.html#1 There are also unanswered questions and probably other loopholes created by its current version. Anyway, see the archives. Thanks, -- MJ Ray (slef) Webmaster and LMS developer at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op
On 10/23/2009 11:00 AM, MJ Ray wrote:
Colin Campbell wrote:
Please read the list archives. I looked at it seriously during its drafting and, personally, I feel that AGPL is a bogus licence, based on the absurd idea that one can "ensure cooperation" with contract-based compulsion when it has been well-known for over 70 years that true cooperation is voluntary. See for example http://www.ica.coop/coop/principles.html#1
I've read them first time and thought your view of the license a caricature. The license does not mention co-operation it merely tries to give those who purchase SaaS the same rights and privileges over source as the GPL permitted. As such it enables co-operation, but as you point out that is voluntary. Colin -- Colin Campbell Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com
I've been a proponent of the AGPL in the past. I suppose my question is, would switching to the AGPL hurt the project in any way? Assuming it fails to "ensure cooperation", wouldn't that just make it equivalent to the GPLv3? Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) On Fri, Oct 23, 2009 at 8:21 AM, Colin Campbell <colin.campbell@ptfs-europe.com> wrote:
On 10/23/2009 11:00 AM, MJ Ray wrote:
Colin Campbell wrote:
Please read the list archives. I looked at it seriously during its drafting and, personally, I feel that AGPL is a bogus licence, based on the absurd idea that one can "ensure cooperation" with contract-based compulsion when it has been well-known for over 70 years that true cooperation is voluntary. See for example http://www.ica.coop/coop/principles.html#1
I've read them first time and thought your view of the license a caricature. The license does not mention co-operation it merely tries to give those who purchase SaaS the same rights and privileges over source as the GPL permitted. As such it enables co-operation, but as you point out that is voluntary. Colin
-- Colin Campbell Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2
http://www.ptfs-europe.com _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Colin Campbell wrote:
On 10/23/2009 11:00 AM, MJ Ray wrote:
Please read the list archives. I looked at it seriously during its drafting and, personally, I feel that AGPL is a bogus licence, based on the absurd idea that one can "ensure cooperation" with contract-based compulsion when it has been well-known for over 70 years that true cooperation is voluntary. See for example http://www.ica.coop/coop/principles.html#1
I've read them first time and thought your view of the license a caricature. The license does not mention co-operation [...]
Erm, yes it does. The first body paragraph of http://www.fsf.org/licensing/licenses/agpl-3.0.html says: "The GNU Affero General Public License is a free, copyleft license for software and other kinds of works, specifically designed to ensure cooperation with the community in the case of network server software." Note "ensure cooperation" there on line three. As one can see, the AGPL is "specifically designed" around that absurd idea, which should worry everyone. Please read and analyse the licence before accusing others of making caricatures of it. There are *big* tricky unanswered questions in it, not just about whether it makes hosted applications actually open or just means they get locked in a different way, but also about whether users have to bear significant costs and risks in using AGPL'd code. Some of these result from the basic absurdity, some do not. Regards, -- MJ Ray (slef) Webmaster and LMS developer at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op
On 10/26/2009 10:22 AM, MJ Ray wrote:
Erm, yes it does. The first body paragraph of http://www.fsf.org/licensing/licenses/agpl-3.0.html says:
"The GNU Affero General Public License is a free, copyleft license for software and other kinds of works, specifically designed to ensure cooperation with the community in the case of network server software."
Note "ensure cooperation" there on line three. As one can see, the AGPL is "specifically designed" around that absurd idea, which should worry everyone. Apologies for my loose phrasing and word blindness (major sins I admit when discussing licences). My point was it does not say "you must co-operate" it does try to ensure that the freedoms guaranteed by the GPL are not circumvented by the means of distribution of the software. The important thing is that the users of the software are ensured of the rights to view, modify and distribute the program. Those freedoms are fundamental to our work and we need to look closely at how to ensure them. Colin -- Colin Campbell Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile)
colin.campbell@ptfs-europe.com skype: colin_campbell2
MJ Ray a écrit :
What with all the flaming of LibLime for hosting lock-in, I didn't expect that other Koha vendors weren't making at least that promise already. So - would the other vendors like to state their current contract permissions? Anyone else want to follow the co-op and BibLibre and make this promise to your buyers?
If the contract says nothing about providing source to *hosted* client there is a loophole. Because GPL + SaaS + specific code + unreleased code is legal (well, no one objected anything. And maybe we could/should investigate if it's really legal. But I think so) So instead of saying nothing we decided to *explicitly* exclude this possibility. We never planned to do that (ie: fork a non open-source version), but with updated contracts, we contractualy exclude this possibility. And, you know, what is written in a contract can't be discussed. What is not written can. Now it's written for BibLibre, our clients are protected. No changes in the promises, just changes in the contracts. In your contract, you say it's written : " grant permission to the Buyer to use, copy, modify, adapt or enhance the material supplied in the performance of the Services, so far as [the co-op] is permitted to grant that permission" but... in a SaaS, you don't provide any material to your customer. So, you have the "juridic loophole" as we had. of course, for non hosted libraries, one provide material, so you/we must release the code under GPL. but (and that's the trick with LEK), for hosted libraries, one provide no material. About:
Also, what about the data? We already explicitly say : "datas are your's, you can get the SQL dump at any time".
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Paul Poulain wrote: [...]
In your contract, you say it's written : "
grant permission to the Buyer to use, copy, modify, adapt or enhance the material supplied in the performance of the Services, so far as [the co-op] is permitted to grant that permission"
but... in a SaaS, you don't provide any material to your customer. So, you have the "juridic loophole" as we had.
No, it's the material *supplied in the performance* that the Buyer is permitted to copy it. Note that the clause is not limited to the material supplied to the Buyer in the way suggested.
Also, what about the data? We already explicitly say : "datas are your's, you can get the SQL dump at any time".
So no prohibition on the encrypting the data in the SQL dump? Regards, -- MJ Ray (slef) Webmaster and LMS developer at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op
MJ Ray a écrit :
but... in a SaaS, you don't provide any material to your customer. So, you have the "juridic loophole" as we had.
No, it's the material *supplied in the performance* that the Buyer is permitted to copy it. Note that the clause is not limited to the material supplied to the Buyer in the way suggested. OK, there's some English subtleties I have missed ;-)
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Hi, all. I'm hoping to write a sort of "minority opinion" regarding the current voting, but I thought I'd voice this concern now rather than waiting. Please, please, please stop *reacting* to current events. You do yourselves and your future a disservice if you base large decisions on a reactionary stance. Instead, try to postulate current and future needs based on the entirety of your history. Try to anticipate future growth and demands. And above all, please think about your customer base, the libraries who use Koha. If you are not addressing their needs and trends, you risk dooming this application and relegating all your work to history's ashcan. At the very least, you should not let your feelings about one company push you in any direction. If you do, you are essentially letting the target of your feelings dictate your moves. I know you've been talking about these changes for a while, but you are acting now. And it's your actions that are disconcerting. And I know that I'm a minority of one here, so I don't expect much sympathy. Just, please, think about what you are doing independently of current events. Thank you. -- Ben
You make a good point - and normally I'd agree with you - but I think that makes our decisions now is a must - not just because of recent events, but because it should have never been like this in the first place. Koha should have always been under the governance/blanket/protection/whatever a non-profit organization of some sort - it should have never ended up that vendors with financial stakes hold control over simple things like the community website and trademarks. Yes, current events are making this decision process reactionary - but I think it's made everyone learn from their original mistake. This isn't about one company - this is about making the community stronger/safer/better organized. It's about making sure that the assets created by the community are in the control of the community - not in the control of any for-profit company - not matter what that company believes or what business decisions they have made in the past and currently. Nicole On Fri, Oct 23, 2009 at 9:02 AM, Ben Ide <benide@gmail.com> wrote:
Hi, all.
I'm hoping to write a sort of "minority opinion" regarding the current voting, but I thought I'd voice this concern now rather than waiting.
Please, please, please stop *reacting* to current events. You do yourselves and your future a disservice if you base large decisions on a reactionary stance.
Instead, try to postulate current and future needs based on the entirety of your history. Try to anticipate future growth and demands. And above all, please think about your customer base, the libraries who use Koha. If you are not addressing their needs and trends, you risk dooming this application and relegating all your work to history's ashcan.
At the very least, you should not let your feelings about one company push you in any direction. If you do, you are essentially letting the target of your feelings dictate your moves.
I know you've been talking about these changes for a while, but you are acting now. And it's your actions that are disconcerting. And I know that I'm a minority of one here, so I don't expect much sympathy. Just, please, think about what you are doing independently of current events.
Thank you. -- Ben _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Please, please, please stop *reacting* to current events. You do yourselves and your future a disservice if you base large decisions on a reactionary stance.
I wouldn't say that we are 'reacting' to current events. I would say that the current events have provided a catalyst for processes we had already planned to do.
Instead, try to postulate current and future needs based on the entirety of your history. Try to anticipate future growth and demands. And above all, please think about your customer base, the libraries who use Koha. If you are not addressing their needs and trends, you risk dooming this application and relegating all your work to history's ashcan.
I would like to think we do, but nobody is psychic. As a library IT guy, the needs of my librarians are my first priority.
At the very least, you should not let your feelings about one company push you in any direction. If you do, you are essentially letting the target of your feelings dictate your moves.
Again, I think this has been a catalyst for a planned action, rather than a reaction.
I know you've been talking about these changes for a while, but you are acting now. And it's your actions that are disconcerting. And I know that I'm a minority of one here, so I don't expect much sympathy. Just, please, think about what you are doing independently of current events.
I've always welcomed dissenting opinions and have kept my mind open to all ideas. It's important that opposing viewpoints be declared and discussed. Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
Thank you. -- Ben _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Ben Ide a écrit :
Hi, all.
Hi Ben,
I'm hoping to write a sort of "minority opinion" regarding the current voting, but I thought I'd voice this concern now rather than waiting.
Please, please, please stop *reacting* to current events. You do yourselves and your future a disservice if you base large decisions on a reactionary stance.
If you investigate this list archive, you should find things about "Koha Software Foundation", that LL announced to help rising (Josh even announced that LL would put $10 000 in the fundation) The problem is that, of course, the KSF won't happend by LL now, so we are working an other solution. So it's a reaction, but not only a reaction. Look here : http://lists.koha.org/pipermail/koha-devel/2006-March/005864.html, it's the 1st thread I could find about the KSF. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
participants (20)
-
Ata ur Rehman -
Ben Ide -
Chris Cormack -
Chris Cormack -
Chris Nighswonger -
Colin Campbell -
Erik Lewis -
Indranil Das Gupta -
Irma Birchall -
Joann Ransom -
Kyle Hall -
Lori Ayre -
Mason James -
MJ Ray -
Nicolas Morin -
Nicole Engard -
Paul Poulain -
tajoli -
Thomas Dukleth -
Walls, Ian