On Mon, Jun 6, 2011 at 12:05 PM, Clay Fouts <[email protected]> wrote: > Each vendor has their own (sometimes very large) customizations that they > may or may not port back into community code. The community RM may or may > not accept these back ports even if effort is made to rebase them. Please > point to the line distinguishing "Koha" from "not Koha".
That's easy: the point at which the vendor (whomever they may be) chooses to fork from Koha. At that point, the software the vendor is servicing, maintaining, your-term-goes-here, ceases to be Koha. It may be said to be based upon Koha, but it is not Koha. > Is BibLibre's fork Koha? They have substantial, potentially irreconcilable > differences that appear not to be destined for the community base and their > extremely patient efforts to point this out and seek solution are met with > little more than a dismissive that "well, that's your problem." Who is or > isn't cooperating this case? > Is Software Coop's fork Koha? I understand there are large differences that > they are not paying to port back into the community base. I even recall > seeing an announcement that someone was paying ByWater to do the work of > porting the coop's EDI code back to community. Does this qualify as > "cooperation"? How is this different from LibLime publishing its code so > that any library is welcome to pay the vendor of their choosing to back port > it to community? Would we receive the same praiseful press release if > ByWater was getting paid to port our large-bib functionality into community > code? By definition a fork is not the same as the base from which it was forked. A given instance of code is only a true fork once there is a delta between it and the source from which it was cloned. Otherwise it is a clone rather than a fork. So, by definition any repo, installation, etc. which has a delta over the main repo is a fork. Since we live in a world where there must be some objective standard against which to make accurate comparisons, we must decide on that standard. In the Koha community that standard has long been the code base in the main repo. So every fork is by definition only as nearly "Koha" as it conforms to that standard. Thus, the larger the delta between the fork and the main repo, the less the fork can be said to be "Koha." Its an inverse relationship if that is clearer. At this point in history, LibLime's fork has a pretty large delta and so is less "Koha" than other forks. > The community had their opportunity to fork their project from the company > that owns the trademark, website, etc. and call their software something > different, much like LibreOffice and Jenkins chose to do when splitting from > the Oracle-run projects. But that wasn't the choice that was made, so now we > all get to have endless arguments and have libraries confused about what is > or is not Koha. Liblime only owns the US trademark usage of the name "Koha," and last I looked, the US does not dictate world trademark law. Koha is much bigger than LibLime (as much as LibLime might pretend otherwise). So just as you are free to have your opinion, the Koha community has their opinion: There is no confusion to those in the know. The Koha community produces and holds the standard against which all other things calling themselves Koha are judged. > At the very least, LibLime when asked tries to be respectful of our > differences and does not say "well, that's not really Koha." I'd say that LibLime is simply acceding to the facts of reality when they refrain from making such claims. They are certainly not doing the community any favors. Kind Regards, Chris _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
