Re: [Koha] Defining community participation [was: Koha demo links on koha.org]
So, if LibLime promised to make all their code available after customer signoff, would this reduce all of this discussion to a footnote in Koha's history? Because this promise has been made on more than one occasion.
Define "available." As we've already heard, LibLime has said that they would not open up a public git repo. That means that the Koha community can't interact with their developments in the way they do with everyone else's. As has been pointed out frequently before, making code available by releasing a tarball just doesn't count. That's not participation.
Actually, with perhaps two exceptions, all the discussion off that thread can be summed up with "Thanks. Could you use Git, please?"
In other words, "Could you return to the kind of participation you were doing just a few months ago?"
Let me ask a very basic question, which I think is at the heart of this matter. How is LibLime's actions different from those of software.coop, the work done for the Learning Access Institute, and HTL? All have code that, so far as I can tell, have not been released back to TKC,* despite open source licensing agreements. What makes this stink bigger?
HLT. Horowhenua Library Trust. http://www.library.org.nz. And neither software.coop or HLT has posted demos of non-public versions of Koha on koha.org. Neither are advertising a non-public version of Koha using the Koha name.
Thank you. But as it's been said before, corporations have the right to profit and programmers have the right to get paid.
It's amazing that we're still having this conversation. Who around here isn't getting paid? All of us, not least of all LibLime, are proof that participation--real participation--in an open source project can be sustainable and profitable.
I have another question that maybe someone can help me with. I've been reading a bit about git and it seems like a real pain to use while you're developing code.
It's not. It's beneficial. LibLime knows this very well, as they use the tool every day to support their customers. This is a non-issue for this subject. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
On Mon, Oct 12, 2009 at 1:26 PM, Owen Leonard <oleonard@myacpl.org> wrote:
So, if LibLime promised to make all their code available after customer signoff, would this reduce all of this discussion to a footnote in Koha's history? Because this promise has been made on more than one occasion.
Define "available." As we've already heard, LibLime has said that they would not open up a public git repo. That means that the Koha community can't interact with their developments in the way they do with everyone else's.
Everyone except for the one's I mentioned (below), you mean.
As has been pointed out frequently before, making code available by releasing a tarball just doesn't count. That's not participation.
You have pointed that out frequently. Very frequently. Could you tell me why tarball doesn't count? To me, it looks like the code is out there, even if it's not in the format you want it to be. What are the rules for participation? Does everyone prefer git? I've read about a few other flavors that people prefer.
Actually, with perhaps two exceptions, all the discussion off that thread can be summed up with "Thanks. Could you use Git, please?"
In other words, "Could you return to the kind of participation you were doing just a few months ago?"
Yes, before they took on a new client's requests. But you know that already. Is this more about impatience in TKC or one company's commitment?
Let me ask a very basic question, which I think is at the heart of this matter. How is LibLime's actions different from those of software.coop, the work done for the Learning Access Institute, and HTL? All have code that, so far as I can tell, have not been released back to TKC,* despite open source licensing agreements. What makes this stink bigger?
HLT. Horowhenua Library Trust. http://www.library.org.nz. And neither software.coop or HLT has posted demos of non-public versions of Koha on koha.org. Neither are advertising a non-public version of Koha using the Koha name.
But that's not really the issue, is it? This is about doing a "find/delete" on anything that says "supported by LibLime."
Thank you. But as it's been said before, corporations have the right to profit and programmers have the right to get paid.
It's amazing that we're still having this conversation. Who around here isn't getting paid? All of us, not least of all LibLime, are proof that participation--real participation--in an open source project can be sustainable and profitable.
It is amazing that we are having this conversation. I thought everyone had moved on with their lives until you started this thread. And for the record, I haven't earned one thin dime off of Koha. Does that make my statements and concerns irrelevant?
I have another question that maybe someone can help me with. I've been reading a bit about git and it seems like a real pain to use while you're developing code.
It's not. It's beneficial. LibLime knows this very well, as they use the tool every day to support their customers. This is a non-issue for this subject.
I never claimed it wasn't beneficial or made guesses about who knew it or not. Here, I'll ask again: Is git easy to use while you are developing code or is it an added step? If it's an added step, why not wait until the work is done? Thanks, -- Ben
We are starting to play with Koha for the first time :-) I've got a clean install that I'm building into a test site. I've run into my first snag. When I go to Home>Administration>Libraries_And_Groups, I am able to set up a new group. But, when I try to set up a new library, it looks like everything works, but no new library appears. Any thoughts? Thanks! Andrea -- Andrea Schurr Web Technology Librarian and ILS Manager Lupton Library, Dept. 6456 University of Tennessee at Chattanooga Phone: 423-425-2668 Fax: 423-425-4775 Email: Andrea-Schurr@utc.edu
In other words, "Could you return to the kind of participation you were doing just a few months ago?"
Yes, before they took on a new client's requests.
And what was it about that new client's requests that made them so different about the clients before them?
But that's not really the issue, is it? This is about doing a "find/delete" on anything that says "supported by LibLime."
This is about keeping Koha.org as vendor-neutral as possible. Demo links should point to the open-source version of Koha.
It is amazing that we are having this conversation. I thought everyone had moved on with their lives until you started this thread.
And as it turns out others agree that this is an issue that needs to be corrected.
And for the record, I haven't earned one thin dime off of Koha. Does that make my statements and concerns irrelevant?
It does make it more difficult for you to make accurate statements about what a developer or company should or shouldn't do in order for it to remain sustainable or profitable. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
On Mon, Oct 12, 2009 at 2:06 PM, Owen Leonard <oleonard@myacpl.org> wrote:
In other words, "Could you return to the kind of participation you were doing just a few months ago?"
Yes, before they took on a new client's requests.
And what was it about that new client's requests that made them so different about the clients before them?
You tell me. You were contracted to work on it.
But that's not really the issue, is it? This is about doing a "find/delete" on anything that says "supported by LibLime."
This is about keeping Koha.org as vendor-neutral as possible. Demo links should point to the open-source version of Koha.
Sure it is.
It is amazing that we are having this conversation. I thought everyone had moved on with their lives until you started this thread.
And as it turns out others agree that this is an issue that needs to be corrected.
Hey, the muck has been stirred. Why not chime in?
And for the record, I haven't earned one thin dime off of Koha. Does that make my statements and concerns irrelevant?
It does make it more difficult for you to make accurate statements about what a developer or company should or shouldn't do in order for it to remain sustainable or profitable.
Yes, you're very clear on the librarian's role in all this: "Take what we give you and shut up." Best of luck with your next RFP.
And for the record, I haven't earned one thin dime off of Koha. Does that make my statements and concerns irrelevant?
It does make it more difficult for you to make accurate statements about what a developer or company should or shouldn't do in order for it to remain sustainable or profitable.
Yes, you're very clear on the librarian's role in all this: "Take what we give you and shut up."
If you think Koha can be defined as "software a bunch of ignorant developers foisted on the library world," then why on earth are you using it? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Please, this conversation has now taken a turn for the much worse and is barely constructive. Ok, IMNSHO, not at all helpful. Can we all vote on foundation or not, joining forces or not when Nicole et al's survey comes out? Since LibLime has done a fix of sorts on the koha.org site as per requested, can we let that go as well? Thanx. Lenora Lenora A. Oftedahl StreamNet Regional Librarian Columbia River Inter-Tribal Fish Commission http://www.fishlib.org
Ben Ide <benide@gmail.com> 10/12/2009 1:36 PM >>> On Mon, Oct 12, 2009 at 2:06 PM, Owen Leonard <oleonard@myacpl.org> wrote: In other words, "Could you return to the kind of participation you were doing just a few months ago?"
Yes, before they took on a new client's requests.
And what was it about that new client's requests that made them so different about the clients before them?
You tell me. You were contracted to work on it.
But that's not really the issue, is it? This is about doing a "find/delete" on anything that says "supported by LibLime."
This is about keeping Koha.org as vendor-neutral as possible. Demo links should point to the open-source version of Koha.
Sure it is.
It is amazing that we are having this conversation. I thought everyone had moved on with their lives until you started this thread.
And as it turns out others agree that this is an issue that needs to be corrected.
Hey, the muck has been stirred. Why not chime in?
And for the record, I haven't earned one thin dime off of Koha. Does that make my statements and concerns irrelevant?
It does make it more difficult for you to make accurate statements about what a developer or company should or shouldn't do in order for it to remain sustainable or profitable.
Yes, you're very clear on the librarian's role in all this: "Take what we give you and shut up." Best of luck with your next RFP. _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
I agree that there seems to be some high tempers in some of these threads ( I'm guilty ). However, the fact is that the site is now 'broken'. The 'Demos' link no longer takes a user to demos, but to the showcase, which is definitely not what a demos link should do. If Liblime were to remove the front-page 'ad' for Liblime's LEK demos, and link to a real Koha demo ( For example, Biblibre's demo ), everything would be fine. I certainly don't begrudge Liblime the right to put up demos of LEK ( all other LEK issues aside ). If Koha.org is supposed to be vendor neutral, the LEK demos should not be linked to from there. At the very least, the site should link to a true Koha demo, and have the LEK demo links marked clearly that they are not official versions of Koha, and are not available for download. Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) On Mon, Oct 12, 2009 at 4:51 PM, Lenora Oftedahl <OFTL@critfc.org> wrote:
Please, this conversation has now taken a turn for the much worse and is barely constructive. Ok, IMNSHO, not at all helpful.
Can we all vote on foundation or not, joining forces or not when Nicole et al's survey comes out?
Since LibLime has done a fix of sorts on the koha.org site as per requested, can we let that go as well?
Thanx. Lenora
Lenora A. Oftedahl StreamNet Regional Librarian Columbia River Inter-Tribal Fish Commission http://www.fishlib.org
Ben Ide <benide@gmail.com> 10/12/2009 1:36 PM >>> On Mon, Oct 12, 2009 at 2:06 PM, Owen Leonard <oleonard@myacpl.org> wrote: In other words, "Could you return to the kind of participation you were doing just a few months ago?"
Yes, before they took on a new client's requests.
And what was it about that new client's requests that made them so different about the clients before them?
You tell me. You were contracted to work on it.
But that's not really the issue, is it? This is about doing a "find/delete" on anything that says "supported by LibLime."
This is about keeping Koha.org as vendor-neutral as possible. Demo links should point to the open-source version of Koha.
Sure it is.
It is amazing that we are having this conversation. I thought everyone had moved on with their lives until you started this thread.
And as it turns out others agree that this is an issue that needs to be corrected.
Hey, the muck has been stirred. Why not chime in?
And for the record, I haven't earned one thin dime off of Koha. Does that make my statements and concerns irrelevant?
It does make it more difficult for you to make accurate statements about what a developer or company should or shouldn't do in order for it to remain sustainable or profitable.
Yes, you're very clear on the librarian's role in all this: "Take what we give you and shut up."
Best of luck with your next RFP. _______________________________________________ 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
Reply inline: Original Subject: Re: [Koha] Defining community participation [was: Koha demo linkson koha.org] On Mon, October 12, 2009 20:51, Lenora Oftedahl wrote: [...]
Since LibLime has done a fix of sorts on the koha.org site as per requested, can we let that go as well?
LibLime have not made any requested changes to the koha.org website in relation to the recent discussion about improperly linking to non-free LibLime demonstrations which are not Koha. The supposition that LibLime had mad a partial change came from people who had not noticed a link which had been broken or mislabelled since LibLime put up a new Plone based version of the community website exclusively under LibLime control in May. The 'demo' link in the central image with the medium blue background on the homepage had been broken or mislabelled in the new website design. Under the former website design, which had been used until May and which is still available at http://old.koha.org , the central image demo link had led to a showcase page with both live OPAC links and demonstration links, http://old.koha.org/showcase/ . In the new website, the 'demo' link in the central image with the medium blue background on the homepage leads to the same relative page with only live OPAC links, no demonstrations, http://koha.org/showcase/ . The central homepage link labelled 'demo' should merely be relabelled 'showcase' or something more appropriate. The demonstration links on the koha.org page are just under the central image with the medium blue background labelled 'New Demo Sites' I reported this issue amongst many others in May when the new koha.org website was about to go live but I failed to report that the issue was related to the image with the medium blue background so Joshua Ferraro had not understood. See section 3.1 in my reply to Joshua from May.about the new website, http://tinyurl.com/yk6pv8d . People have checked the timestamps in Plone and no changes have been made to pages at koha.org linking to demonstrations have been made for months. There are many koha.org bugs which have been discussed on the mailing list but not filed formally. Most people may be too frustrated by the exclusive control of LibLime to file such bugs. I have not filed them formally merely because I have lacked time to report them properly in relation to other things which I have to do. The LibLime demonstrations themselves have changed recently and now feature non-free software for which no source code is available which is not Koha. I and others find the linking to non-free software described as Koha from koha.org inappropriate but I agree that we should move forward and form a foundation which can offer an alternative. I assume that the 'move forward' part matches the other sentiments which you had expressed in your message. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783
Salvete! Maybe Paul will chime in, because I am fairly certain he could be a proper professor at some University since he can get dolts like me to understand stuff. This is a bit of telephone, since I've not actually used git, so do keep that in mind. Git strikes me rather like old fashioned FTP, with the important difference of revision control; if you and I both manufacture a car rim simultaneously, Paul can look at it and select the best, or maybe keep both, or perhaps toss them both as rubbish. (I pick on Paul because he has thick skin, and he really was a RM ;) I learnt about git at the last Koha Con, so really, it's not some super secret arcane crippling demand for programmers. Even I was able to make functions for the linux login stuff I needed to do in college, and I'm fairly secure in my thinking that I could use git if I had to after hearing an explanation of it at Koha Con. I'd go so far as to say that you can probably make a function that will upload your file to git simply by pressing whatever key for the first command bits then typing your file name, but I might well be behind the times. You might want to take a look at http://sysmonblog.co.uk/misc/git_by_example/ which was linked from wikipedia to see what I mean. I would think that it's rather like dragging and dropping a file to the average programmer. It's just not that hard. To me, I'm reminded of making snowballs, snow forts, and snowmen as a kid. Sure, I packed a mean snowball, but if I got bored, or called back inside, or had to pack into school or what have you I could leave my snowball outside, and someone else could roll it about. To my amazement as I came back to my little snowball, it wasn't so little anymore. My sister, my da, one of the neighbourhood kids, who knows took it up for a little bit, rolled it around, and viola, suddenly I had summat I couldn't lift anymore and my eyes were wide. Technically someone else messing with my snowball was an added step, but man was that worth it. It was always the coolest when 5 or 6 kids got together when school was closed and we made a crazy fort in the backyard that was way bigger than the mischief we were individually capable of. This whole project is about doing a little at a time and having many eyes on the code. Setting an artificial velvet rope up takes it back from the open source mindset and back into the proprietary realm. It's like saying "No, no, your ideas aren't worth anything to us, we'll just give you our polished professional version once it's all done." Even if it's less rich, concise, or elegant. Owen in my experience has never discounted my ideas whole cloth. He might caution me that I want to do something foolish, but if I were clear enough about what sort of feature I was interested in having and he thought it would appeal to more than just me, he'd make it happen. Owen spent a lot of time at Koha Con essentially showing people how to do a chunk of what he does for free :D I like to think that he did this out of a sense of community in addition to a desire to not see Libraries have busted stuff between versions from being too fancy with the templates when an overlay will work. I might have missed the point, though. I'm not paid. That gives me freedom of action, but I try not to act like it somehow makes me better. The difference between LibLime and HLT in my eyes is night and day. HLT is in this for the social profit of the venture. They've been selfless in this. It's more valid to ask why BibLibre or Katipo are not being lambasted, from where I stand, since it's corpo to corpo. I think both BibLibre and Katipo were models for the community in how they behaved. Cheers, Brooke
Could you tell me why tarball doesn't count? To me, it looks like the code is out there, even if it's not in the format you want it to be.
A tarball is absolutely the very least a body can do to release code and no violate the GPL. It means that if we want to integrate the LEK code into Koha, it will require hundreds of man-hours to integrate. If Liblime were to make available a Git repository, it would change hundreds to just tens. I don't buy they 'customer sensitive data' line. If they can strip customer sensitive data from a tarball of the code, they could do the same for a Git repository. From my viewpoint, it looks like Liblime is doing the minimum they can so they can so 'LEK is Open Source!', while making it as hard as possible for that "Open Source" code to be useful.
Here, I'll ask again: Is git easy to use while you are developing code or is it an added step? If it's an added step, why not wait until the work is done?
You have no idea how amazing Git is! It's the most powerful and amazing tool I have ever used as a programmer. When the discussion of switching to Git was going on, I was 100% anti-Git ( I was pushing subversion ). It is not an added step, it removes steps. I'm sure that using Git has saved hundreds of man-hours across the entire Koha developer community. Since it is not an added step, your second question is moot, but I'll answer it anyway. The longer the wait, the greater the differences between Koha and LEK become, and this means more work spent on integration. It's as simple as that. Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) On Mon, Oct 12, 2009 at 1:51 PM, Ben Ide <benide@gmail.com> wrote:
On Mon, Oct 12, 2009 at 1:26 PM, Owen Leonard <oleonard@myacpl.org> wrote:
So, if LibLime promised to make all their code available after customer signoff, would this reduce all of this discussion to a footnote in Koha's history? Because this promise has been made on more than one occasion.
Define "available." As we've already heard, LibLime has said that they would not open up a public git repo. That means that the Koha community can't interact with their developments in the way they do with everyone else's.
Everyone except for the one's I mentioned (below), you mean.
As has been pointed out frequently before, making code available by releasing a tarball just doesn't count. That's not participation.
You have pointed that out frequently. Very frequently.
Could you tell me why tarball doesn't count? To me, it looks like the code is out there, even if it's not in the format you want it to be. What are the rules for participation? Does everyone prefer git? I've read about a few other flavors that people prefer.
Actually, with perhaps two exceptions, all the discussion off that thread can be summed up with "Thanks. Could you use Git, please?"
In other words, "Could you return to the kind of participation you were doing just a few months ago?"
Yes, before they took on a new client's requests. But you know that already. Is this more about impatience in TKC or one company's commitment?
Let me ask a very basic question, which I think is at the heart of this matter. How is LibLime's actions different from those of software.coop, the work done for the Learning Access Institute, and HTL? All have code that, so far as I can tell, have not been released back to TKC,* despite open source licensing agreements. What makes this stink bigger?
HLT. Horowhenua Library Trust. http://www.library.org.nz. And neither software.coop or HLT has posted demos of non-public versions of Koha on koha.org. Neither are advertising a non-public version of Koha using the Koha name.
But that's not really the issue, is it? This is about doing a "find/delete" on anything that says "supported by LibLime."
Thank you. But as it's been said before, corporations have the right to profit and programmers have the right to get paid.
It's amazing that we're still having this conversation. Who around here isn't getting paid? All of us, not least of all LibLime, are proof that participation--real participation--in an open source project can be sustainable and profitable.
It is amazing that we are having this conversation. I thought everyone had moved on with their lives until you started this thread.
And for the record, I haven't earned one thin dime off of Koha. Does that make my statements and concerns irrelevant?
I have another question that maybe someone can help me with. I've been reading a bit about git and it seems like a real pain to use while you're developing code.
It's not. It's beneficial. LibLime knows this very well, as they use the tool every day to support their customers. This is a non-issue for this subject.
I never claimed it wasn't beneficial or made guesses about who knew it or not. Here, I'll ask again: Is git easy to use while you are developing code or is it an added step? If it's an added step, why not wait until the work is done?
Thanks, -- Ben _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Excellent reply. Thank you! You were one of the folks I alluded to when I mentioned that others preferred something other than Git, so I count this as a ringing endorsement. I'm still not sure what the mechanics of Git are, but as soon as I contribute code I'll understand it better. (If Koha ever needs HyperCard programming, I'm your guy. ;-) One more question: Who first mentioned that LibLime plans to release their code via tarball? Thanks, -- Ben On Mon, Oct 12, 2009 at 2:16 PM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
Could you tell me why tarball doesn't count? To me, it looks like the code is out there, even if it's not in the format you want it to be.
A tarball is absolutely the very least a body can do to release code and no violate the GPL. It means that if we want to integrate the LEK code into Koha, it will require hundreds of man-hours to integrate. If Liblime were to make available a Git repository, it would change hundreds to just tens.
I don't buy they 'customer sensitive data' line. If they can strip customer sensitive data from a tarball of the code, they could do the same for a Git repository. From my viewpoint, it looks like Liblime is doing the minimum they can so they can so 'LEK is Open Source!', while making it as hard as possible for that "Open Source" code to be useful.
Here, I'll ask again: Is git easy to use while you are developing code or is it an added step? If it's an added step, why not wait until the work is done?
You have no idea how amazing Git is! It's the most powerful and amazing tool I have ever used as a programmer. When the discussion of switching to Git was going on, I was 100% anti-Git ( I was pushing subversion ). It is not an added step, it removes steps. I'm sure that using Git has saved hundreds of man-hours across the entire Koha developer community.
Since it is not an added step, your second question is moot, but I'll answer it anyway. The longer the wait, the greater the differences between Koha and LEK become, and this means more work spent on integration. It's as simple as that.
Kyle
http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
On Mon, Oct 12, 2009 at 1:51 PM, Ben Ide <benide@gmail.com> wrote:
On Mon, Oct 12, 2009 at 1:26 PM, Owen Leonard <oleonard@myacpl.org> wrote:
So, if LibLime promised to make all their code available after customer signoff, would this reduce all of this discussion to a footnote in Koha's history? Because this promise has been made on more than one occasion.
Define "available." As we've already heard, LibLime has said that they would not open up a public git repo. That means that the Koha community can't interact with their developments in the way they do with everyone else's.
Everyone except for the one's I mentioned (below), you mean.
As has been pointed out frequently before, making code available by releasing a tarball just doesn't count. That's not participation.
You have pointed that out frequently. Very frequently.
Could you tell me why tarball doesn't count? To me, it looks like the code is out there, even if it's not in the format you want it to be. What are the rules for participation? Does everyone prefer git? I've read about a few other flavors that people prefer.
Actually, with perhaps two exceptions, all the discussion off that thread can be summed up with "Thanks. Could you use Git, please?"
In other words, "Could you return to the kind of participation you were doing just a few months ago?"
Yes, before they took on a new client's requests. But you know that already. Is this more about impatience in TKC or one company's commitment?
Let me ask a very basic question, which I think is at the heart of this matter. How is LibLime's actions different from those of software.coop, the work done for the Learning Access Institute, and HTL? All have code that, so far as I can tell, have not been released back to TKC,* despite open source licensing agreements. What makes this stink bigger?
HLT. Horowhenua Library Trust. http://www.library.org.nz. And neither software.coop or HLT has posted demos of non-public versions of Koha on koha.org. Neither are advertising a non-public version of Koha using the Koha name.
But that's not really the issue, is it? This is about doing a "find/delete" on anything that says "supported by LibLime."
Thank you. But as it's been said before, corporations have the right to profit and programmers have the right to get paid.
It's amazing that we're still having this conversation. Who around here isn't getting paid? All of us, not least of all LibLime, are proof that participation--real participation--in an open source project can be sustainable and profitable.
It is amazing that we are having this conversation. I thought everyone had moved on with their lives until you started this thread.
And for the record, I haven't earned one thin dime off of Koha. Does that make my statements and concerns irrelevant?
I have another question that maybe someone can help me with. I've been reading a bit about git and it seems like a real pain to use while you're developing code.
It's not. It's beneficial. LibLime knows this very well, as they use the tool every day to support their customers. This is a non-issue for this subject.
I never claimed it wasn't beneficial or made guesses about who knew it or not. Here, I'll ask again: Is git easy to use while you are developing code or is it an added step? If it's an added step, why not wait until the work is done?
Thanks, -- Ben _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
One more question: Who first mentioned that LibLime plans to release their code via tarball?
LibLime has not said how they would release their code, only that they would, eventually. They've said categorically that they would not open up a public git repo, so it's logical to conclude that they would release a tarball. Perhaps even that is overly optimistic? Perhaps we'll get a PDF? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
I'm glad that I was able to be informative, I'm not always successful at such things ; ) Owen is right. Liblime has stated that there will absolutely not be a git repo made available. The only logical alternative is a tarball or the source tree. This is assuming the code ever gets released. It's simply untrue of Liblime to say that LEK is Open Source when the sources have yet to be opened. They could say it will be Open Source in the future, but that is not what they are saying. From http://www.liblime.com/products/koha/koha-solution-comparison we see they are claiming LEK as Open Source, but how can that be true, if they have not made the source code available? This is a stretch, but one could say that by releasing a tarball, and not a Git repository, that they are violating the GPL. The GPL states that "source code" for a work means the preferred form of the work for making modifications to it. One could argue that the preferred form for Koha is a Git repository, but since the GPL doesn't define 'preferred form' the potential for a violation remains unclear. Does anyone know of any precedent for such an issue? Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) On Mon, Oct 12, 2009 at 2:30 PM, Ben Ide <benide@gmail.com> wrote:
Excellent reply. Thank you! You were one of the folks I alluded to when I mentioned that others preferred something other than Git, so I count this as a ringing endorsement.
I'm still not sure what the mechanics of Git are, but as soon as I contribute code I'll understand it better. (If Koha ever needs HyperCard programming, I'm your guy. ;-)
One more question: Who first mentioned that LibLime plans to release their code via tarball?
Thanks, -- Ben
On Mon, Oct 12, 2009 at 2:16 PM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
Could you tell me why tarball doesn't count? To me, it looks like the code is out there, even if it's not in the format you want it to be.
A tarball is absolutely the very least a body can do to release code and no violate the GPL. It means that if we want to integrate the LEK code into Koha, it will require hundreds of man-hours to integrate. If Liblime were to make available a Git repository, it would change hundreds to just tens.
I don't buy they 'customer sensitive data' line. If they can strip customer sensitive data from a tarball of the code, they could do the same for a Git repository. From my viewpoint, it looks like Liblime is doing the minimum they can so they can so 'LEK is Open Source!', while making it as hard as possible for that "Open Source" code to be useful.
Here, I'll ask again: Is git easy to use while you are developing code or is it an added step? If it's an added step, why not wait until the work is done?
You have no idea how amazing Git is! It's the most powerful and amazing tool I have ever used as a programmer. When the discussion of switching to Git was going on, I was 100% anti-Git ( I was pushing subversion ). It is not an added step, it removes steps. I'm sure that using Git has saved hundreds of man-hours across the entire Koha developer community.
Since it is not an added step, your second question is moot, but I'll answer it anyway. The longer the wait, the greater the differences between Koha and LEK become, and this means more work spent on integration. It's as simple as that.
Kyle
http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
On Mon, Oct 12, 2009 at 1:51 PM, Ben Ide <benide@gmail.com> wrote:
On Mon, Oct 12, 2009 at 1:26 PM, Owen Leonard <oleonard@myacpl.org> wrote:
So, if LibLime promised to make all their code available after customer signoff, would this reduce all of this discussion to a footnote in Koha's history? Because this promise has been made on more than one occasion.
Define "available." As we've already heard, LibLime has said that they would not open up a public git repo. That means that the Koha community can't interact with their developments in the way they do with everyone else's.
Everyone except for the one's I mentioned (below), you mean.
As has been pointed out frequently before, making code available by releasing a tarball just doesn't count. That's not participation.
You have pointed that out frequently. Very frequently.
Could you tell me why tarball doesn't count? To me, it looks like the code is out there, even if it's not in the format you want it to be. What are the rules for participation? Does everyone prefer git? I've read about a few other flavors that people prefer.
Actually, with perhaps two exceptions, all the discussion off that thread can be summed up with "Thanks. Could you use Git, please?"
In other words, "Could you return to the kind of participation you were doing just a few months ago?"
Yes, before they took on a new client's requests. But you know that already. Is this more about impatience in TKC or one company's commitment?
Let me ask a very basic question, which I think is at the heart of this matter. How is LibLime's actions different from those of software.coop, the work done for the Learning Access Institute, and HTL? All have code that, so far as I can tell, have not been released back to TKC,* despite open source licensing agreements. What makes this stink bigger?
HLT. Horowhenua Library Trust. http://www.library.org.nz. And neither software.coop or HLT has posted demos of non-public versions of Koha on koha.org. Neither are advertising a non-public version of Koha using the Koha name.
But that's not really the issue, is it? This is about doing a "find/delete" on anything that says "supported by LibLime."
Thank you. But as it's been said before, corporations have the right to profit and programmers have the right to get paid.
It's amazing that we're still having this conversation. Who around here isn't getting paid? All of us, not least of all LibLime, are proof that participation--real participation--in an open source project can be sustainable and profitable.
It is amazing that we are having this conversation. I thought everyone had moved on with their lives until you started this thread.
And for the record, I haven't earned one thin dime off of Koha. Does that make my statements and concerns irrelevant?
I have another question that maybe someone can help me with. I've been reading a bit about git and it seems like a real pain to use while you're developing code.
It's not. It's beneficial. LibLime knows this very well, as they use the tool every day to support their customers. This is a non-issue for this subject.
I never claimed it wasn't beneficial or made guesses about who knew it or not. Here, I'll ask again: Is git easy to use while you are developing code or is it an added step? If it's an added step, why not wait until the work is done?
Thanks, -- Ben _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
On 10/12/2009 07:49 PM, Kyle Hall wrote:
This is a stretch, but one could say that by releasing a tarball, and not a Git repository, that they are violating the GPL. The GPL states that "source code" for a work means the preferred form of the work for making modifications to it. One could argue that the preferred form for Koha is a Git repository, but since the GPL doesn't define 'preferred form' the potential for a violation remains unclear. Does anyone know of any precedent for such an issue?
All the clarifications, I've seen are that preferred form is the source in a form from which you can build the application. (i.e. providing a version of a unix utility in source that requires a non-unix environment is a no-no) I would think that that excludes enforcing the use of a particular source control system. What that is, is a measure of is willingness to cooperate with the community in development. The GPL does not enforce cooperation but reserves the right for you to cooperate if you wish. And it requires that the source be available for the vendor's customers for these purposes, and the purpose of study. Cheers 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
participants (8)
-
Andrea Schurr -
Ben Ide -
Colin Campbell -
Kyle Hall -
Lenora Oftedahl -
M. Brooke Helman -
Owen Leonard -
Thomas Dukleth