--- On Thu, 10/14/10, MJ Ray <mjr@phonecoop.coop> wrote:
I've posted a brief outline or summation of LibLime's ideas about a Koha Software Foundation on the wiki -- we seek your comments -- http://wiki.koha-community.org/wiki/Forming_a_Koha_Foundation#United_States
Please let me know if there is a more logical place to
wiki - under Forming a Foundation / Locations for an Independent Koha Organisation/ United States seemed to fit the flow in
From: MJ Ray <mjr@phonecoop.coop> Subject: Re: [Koha] Fwd: LibLime ideas on a Koha Software Foundation To: koha@lists.katipo.co.nz Date: Thursday, October 14, 2010, 12:30 PM DeGroff, Amy wrote: place these on the place but I am happy
to cross post or move if it will help.
A foundation 40%-controlled by Liblime doesn't seem independent to me, so I feel it should be moved, but I can't think of how to name where it should go. Does a vendor tie seem in keeping with a FOSS project host corporation to anyone?
In general, I don't think a vendor tie is necessarily against keeping with FOSS values. Many successful Open Source products have significant vendor ties. MySQL is a prime example.
I've added a comment to re-explain the difference between a foundation and an association.
I'll ignore the "intellectual assets" as that's against community policy. http://www.gnu.org/philosophy/words-to-avoid.html#IntellectualProperty
Agreeing to any permanent representation on the board would open a can of worms because I expect all 30 or so current vendors would like something similar and several were giving to this project community before LibLime even launched.
Well, yes and no. LibLime did launch after a lot of development took place, but they also acquired the assets relating to Koha from the initial developers as I understand it.
It's hard to measure how much, because I'm sure we've seen patches committed under the wrong author's byline. It would be a bit odd to give permanent credit for "standing" only to one company that bought the 2005-9 LibLime business, wouldn't it?
No. Not at all. If they legally acquired the assets, they have acquired the assets and should have the same rights afforded to them as if they were the same entity/people that developed them. The question to me is more what that means in terms of rights, guarantees, etc. in any new Koha organization. Should any entity that has contributed code or other intellectual property have some sort of guarantees? I don't know the answer. However if the answer is yes, then PTFS/LibLime has a legitimate claim here.
So I feel like PTFS's basic preconditions are obviously unworkable and this means we're at a more obvious and clear deadlock. Can anyone explain what I've missed and why I'm wrong?
I don't know if they are obviously unworkable or not because I do not know what PTFS would say to an alternative proposal that they felt might reasonably protect their interests. I also don't know if the community as a whole would agree to an alternative. Without rehashing the details I think it is fair to say both PTFS and large portions of the Koha community each have reasons to be skeptical of each other. Arguing who is at fault would make any attempt to cross this divide even less likely to succeed then it is now. Personally, I wouldn't mind if a few key entities/persons got some level of guaranteed seats at the table for a limited time period. I am not sure what percentage of the board (or what ever it is) that should be nor how it should be divided. As I said, I don't know if PTFS would agree to such an alternative proposal, but my gut feeling is if they don't have at least an initial seat, they would be unlikely to relinquish the assets they control. This might be unfortunate and not what a significant portion of the community would prefer, but I think it is reality. If what I suspect of PTFS is true and the community doesn't want to meet them at some point in the middle (or if PTFS is unwilling to accept a compromise), I fear that Thomas Krichel is correct when he says "the whole thing will not be over until the community changes the name of the software and gets another domain for it." Cheers, Edward
Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha