[Koha] Defining community participation [was: Koha demo links on koha.org]

[Kyle Hall]

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 at 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 at 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 at gmail.com> wrote:
>>> On Mon, Oct 12, 2009 at 1:26 PM, Owen Leonard <oleonard at 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 at lists.katipo.co.nz
>>> http://lists.katipo.co.nz/mailman/listinfo/koha
>>>
>>
>