Hello, I am using KOHA ILS. Can i able to use dedicated Zebra Server which is installed in another server? Could you please advice if possible? Thank you, -- Mansur Ali +966568978721 | +919061635954 | mansuralih@gmail.com
Hi, Il 18/07/2017 13:28, Mansur Ali ha scritto:
Hello,
I am using KOHA ILS. Can i able to use dedicated Zebra Server which is installed in another server? Could you please advice if possible?
with present standard installation, the answer is no, it is not possible. In theory if: 1)You setup to use PazPar instead of Zebra [an old option not tested from years] AND 2)You rewrite the updating scripts and deamon you can try to do it. I suggest you to do a try only if you are very skilled on Zebra and others Indexdata's tools. Bye Zeno Tajoli -- Zeno Tajoli /SVILUPPO PRODOTTI CINECA/ - Automazione Biblioteche Email: z.tajoli@cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)
Thank you for your valuable information. On Tue, Jul 18, 2017 at 2:59 PM, Tajoli Zeno <z.tajoli@cineca.it> wrote:
Hi,
Il 18/07/2017 13:28, Mansur Ali ha scritto:
Hello,
I am using KOHA ILS. Can i able to use dedicated Zebra Server which is installed in another server? Could you please advice if possible?
with present standard installation, the answer is no, it is not possible.
In theory if: 1)You setup to use PazPar instead of Zebra [an old option not tested from years] AND 2)You rewrite the updating scripts and deamon
you can try to do it.
I suggest you to do a try only if you are very skilled on Zebra and others Indexdata's tools.
Bye Zeno Tajoli
-- Zeno Tajoli /SVILUPPO PRODOTTI CINECA/ - Automazione Biblioteche Email: z.tajoli@cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)
-- Mansur Ali +966568978721 | +919061635954 | mansuralih@gmail.com
Hi! We install Koha in a cluster of LXC containers: One haproxy for dns redirection and ssl offloading One container for MariaDB One for OPAC One for staff client One for Zebra One for misc stuff, like the SIP2-server One for ElasticSearch One for Memcached +containers for other support services With haproxy it is rather straight forward to start load balancing multiple "web bricks" if you choose to. We don't need to do it since we chose to buy a lot of hardware. Hardware is less expensive than work where we live in. This clusterization is simply to increase robustness and security. And actually has saved our bacon few times during the past years, when we get unidentifiable hard-drive freezes with the SIP2-container, or some cronjob has went awol and completely hogged all system resources available to it. Without containerization we would have had downtime. Also helps with simple DOS-attacks which can happen by accident. I recommend this type of setup. Unfortunately the debian packages add a lot of unnecesary cruft to each container so we use dev-install instead. Getting Zebra to work in a separate container: Zebra is really really really tightly wound into the make-toolchain Koha uses and there is no convenient way of separating it. Maybe you could just bind mount the zebradb-directory between containers. This might be enough to run Zebra separate of the Koha's source code. Since mass storage is very cheap, we just run two identical Koha instances from the same source code repo. We make several identical Koha-installations via the dev-install. The Zebra-one only has Zebra and Koha sources (no Apache2, MariaDB, etc packages needed by a standalone Koha). You can configure Zebra to listen on tcp socket via the $KOHA_CONF. You can conveniently centrally configure the same $KOHA_CONF to all the Koha containers, so they all find the same Zebra by the ip and the same MariaDB. This is best done with Ansible (since community has already started working towards Ansible) Separating Zebra to a isolated (and easily monitorable) environment is entirely possible. Here is a snippet from our Ansible infrastructure definitions where Koha is set up with capability: zebra These should be most of the Ansible steps needed together with Koha-source to get Zebra running standalone: ansible@hephaestus:~/KSAnsible$ cat roles/koha/tasks/capabilities/zebra.yml --- - name: Install zebrasrv and zebraidx apt: name: idzebra-2.0 become: yes - name: Create the zebra socket-dir and permissions file: path: "{{zebra_run_dir}}" owner: koha group: koha state: directory become: yes - name: Create the zebra lock-dir and permissions file: path: "{{zebra_lock_dir}}" owner: koha group: koha state: directory become: yes - name: Create the zebra data-dir and permissions file: path: "{{zebra_data_dir}}" owner: koha group: koha state: directory become: yes - name: Configure Zebra stripes lineinfile: path: "{{item.path}}" regexp: "{{item.regexp}}" line: "{{item.line}}" with_items: - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^memMax:" line: "memMax: {{zebra_index_mem}}" - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^register:" line: "register: {{zebra_data_dir}}/biblios/register:{{zebra_index_size}}" - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^shadow:" line: "shadow: {{zebra_data_dir}}/biblios/shadow:{{zebra_index_size}}" - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^sortmax:" line: "sortmax: {{zebra_sort_max}}" - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^facetNumRecs:" line: "facetNumRecs:{{zebra_facet_num_records}}" owner: koha become: yes notify: Restart Zebra - name: Zebra - Link Zebra-service file: src: "{{koha_dev_path}}/bin/koha-zebra-ctl.sh" dest: "/etc/init.d/koha-zebra-daemon" owner: root group: root state: "link" become: yes - name: Zebra - Enable Zebra-service systemd: name: koha-zebra-daemon enabled: yes daemon_reload: yes state: started become: yes - name: Zebra-index - Link Zebra-index-service file: src: "{{koha_dev_path}}/bin/koha-index-daemon-ctl.sh" dest: "/etc/init.d/koha-index-daemon" owner: root group: root state: "link" become: yes - name: Zebra-index - Enable Zebra-index-service systemd: name: koha-index-daemon enabled: yes daemon_reload: yes state: started become: yes - name: Deploy Zebra cronjobs template: owner: "{{koha_user}}" src: "etc_cron.d_koha.j2" dest: "/etc/cron.d/koha-zebra" vars: cronjobs: rbza: comment: '#Trigger full Zebra reindexing daily' prefix: ' ' timing: '46 10 * * *' user: 'koha' command: 'migration_tools/rebuild_zebra.pl -b -a -r -v -x' become: yes ________________________________ From: koha-devel-bounces@lists.koha-community.org [koha-devel-bounces@lists.koha-community.org] on behalf of Mansur Ali [mansuralih@gmail.com] Sent: Tuesday, July 18, 2017 3:11 PM To: Tajoli Zeno Cc: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Dedicated Zebra Server Thank you for your valuable information. On Tue, Jul 18, 2017 at 2:59 PM, Tajoli Zeno <z.tajoli@cineca.it<mailto:z.tajoli@cineca.it>> wrote: Hi, Il 18/07/2017 13:28, Mansur Ali ha scritto: Hello, I am using KOHA ILS. Can i able to use dedicated Zebra Server which is installed in another server? Could you please advice if possible? with present standard installation, the answer is no, it is not possible. In theory if: 1)You setup to use PazPar instead of Zebra [an old option not tested from years] AND 2)You rewrite the updating scripts and deamon you can try to do it. I suggest you to do a try only if you are very skilled on Zebra and others Indexdata's tools. Bye Zeno Tajoli -- Zeno Tajoli /SVILUPPO PRODOTTI CINECA/ - Automazione Biblioteche Email: z.tajoli@cineca.it<mailto:z.tajoli@cineca.it> Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) -- Mansur Ali +966568978721 | +919061635954 | mansuralih@gmail.com<mailto:mansuralih@gmail.com>
I'm thinking of doing something like this too. I'd really like to see the zebra var's from the koha_conf.xml too, if possible. Thanks. On Tue, Jul 18, 2017 at 8:37 AM, Kivilahti Olli-Antti < olli-antti.kivilahti@jns.fi> wrote:
Hi!
We install Koha in a cluster of LXC containers:
One haproxy for dns redirection and ssl offloading One container for MariaDB One for OPAC One for staff client One for Zebra One for misc stuff, like the SIP2-server One for ElasticSearch One for Memcached +containers for other support services
With haproxy it is rather straight forward to start load balancing multiple "web bricks" if you choose to. We don't need to do it since we chose to buy a lot of hardware. Hardware is less expensive than work where we live in. This clusterization is simply to increase robustness and security. And actually has saved our bacon few times during the past years, when we get unidentifiable hard-drive freezes with the SIP2-container, or some cronjob has went awol and completely hogged all system resources available to it. Without containerization we would have had downtime. Also helps with simple DOS-attacks which can happen by accident.
I recommend this type of setup.
Unfortunately the debian packages add a lot of unnecesary cruft to each container so we use dev-install instead.
Getting Zebra to work in a separate container: Zebra is really really really tightly wound into the make-toolchain Koha uses and there is no convenient way of separating it. Maybe you could just bind mount the zebradb-directory between containers. This might be enough to run Zebra separate of the Koha's source code.
Since mass storage is very cheap, we just run two identical Koha instances from the same source code repo. We make several identical Koha-installations via the dev-install. The Zebra-one only has Zebra and Koha sources (no Apache2, MariaDB, etc packages needed by a standalone Koha). You can configure Zebra to listen on tcp socket via the $KOHA_CONF. You can conveniently centrally configure the same $KOHA_CONF to all the Koha containers, so they all find the same Zebra by the ip and the same MariaDB. This is best done with Ansible (since community has already started working towards Ansible)
Separating Zebra to a isolated (and easily monitorable) environment is entirely possible.
Here is a snippet from our Ansible infrastructure definitions where Koha is set up with capability: zebra
These should be most of the Ansible steps needed together with Koha-source to get Zebra running standalone:
ansible@hephaestus:~/KSAnsible$ cat roles/koha/tasks/capabilities/ zebra.yml
---
- name: Install zebrasrv and zebraidx apt: name: idzebra-2.0 become: yes
- name: Create the zebra socket-dir and permissions file: path: "{{zebra_run_dir}}" owner: koha group: koha state: directory become: yes
- name: Create the zebra lock-dir and permissions file: path: "{{zebra_lock_dir}}" owner: koha group: koha state: directory become: yes
- name: Create the zebra data-dir and permissions file: path: "{{zebra_data_dir}}" owner: koha group: koha state: directory become: yes
- name: Configure Zebra stripes lineinfile: path: "{{item.path}}" regexp: "{{item.regexp}}" line: "{{item.line}}" with_items: - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^memMax:" line: "memMax: {{zebra_index_mem}}" - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^register:" line: "register: {{zebra_data_dir}}/biblios/ register:{{zebra_index_size}}" - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^shadow:" line: "shadow: {{zebra_data_dir}}/biblios/ shadow:{{zebra_index_size}}" - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^sortmax:" line: "sortmax: {{zebra_sort_max}}" - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^facetNumRecs:" line: "facetNumRecs:{{zebra_facet_num_records}}" owner: koha become: yes notify: Restart Zebra
- name: Zebra - Link Zebra-service file: src: "{{koha_dev_path}}/bin/koha-zebra-ctl.sh" dest: "/etc/init.d/koha-zebra-daemon" owner: root group: root state: "link" become: yes
- name: Zebra - Enable Zebra-service systemd: name: koha-zebra-daemon enabled: yes daemon_reload: yes state: started become: yes
- name: Zebra-index - Link Zebra-index-service file: src: "{{koha_dev_path}}/bin/koha-index-daemon-ctl.sh" dest: "/etc/init.d/koha-index-daemon" owner: root group: root state: "link" become: yes
- name: Zebra-index - Enable Zebra-index-service systemd: name: koha-index-daemon enabled: yes daemon_reload: yes state: started become: yes
- name: Deploy Zebra cronjobs template: owner: "{{koha_user}}" src: "etc_cron.d_koha.j2" dest: "/etc/cron.d/koha-zebra" vars: cronjobs: rbza: comment: '#Trigger full Zebra reindexing daily' prefix: ' ' timing: '46 10 * * *' user: 'koha' command: 'migration_tools/rebuild_zebra.pl -b -a -r -v -x' become: yes
------------------------------ *From:* koha-devel-bounces@lists.koha-community.org [ koha-devel-bounces@lists.koha-community.org] on behalf of Mansur Ali [ mansuralih@gmail.com] *Sent:* Tuesday, July 18, 2017 3:11 PM *To:* Tajoli Zeno *Cc:* koha-devel@lists.koha-community.org *Subject:* Re: [Koha-devel] Dedicated Zebra Server
Thank you for your valuable information.
On Tue, Jul 18, 2017 at 2:59 PM, Tajoli Zeno <z.tajoli@cineca.it> wrote:
Hi,
Il 18/07/2017 13:28, Mansur Ali ha scritto:
Hello,
I am using KOHA ILS. Can i able to use dedicated Zebra Server which is installed in another server? Could you please advice if possible?
with present standard installation, the answer is no, it is not possible.
In theory if: 1)You setup to use PazPar instead of Zebra [an old option not tested from years] AND 2)You rewrite the updating scripts and deamon
you can try to do it.
I suggest you to do a try only if you are very skilled on Zebra and others Indexdata's tools.
Bye Zeno Tajoli
-- Zeno Tajoli /SVILUPPO PRODOTTI CINECA/ - Automazione Biblioteche Email: z.tajoli@cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)
-- Mansur Ali
+966568978721 <+966%2056%20897%208721> | +919061635954 | mansuralih@gmail.com
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
-- Michael Hafen Washington County School District Technology Department Systems Analyst
A sizeable portion of koha-conf.xml is actually Zebra configuration. An interesting task would be to separate out all the Zebra-specific stuff and put it in its own file, so that it was less intimidating and perhaps easier to manage. For searching, Koha is just using a Z39.50 connection, so Zebra could be accessed over TCP on a different server. For indexing, the indexing needs to happen on the Zebra server, and in order to index you need to have records from the Koha database. There’s a number of ways you could handle that I suppose… but yeah it currently is closely tied to the Koha application monolith. In theory, if your MySQL database was on yet another server, you’d just need an indexing script and the credentials to access the MySQL database. I suppose there are some system preferences that get taken into account as well… but that’s still coming from the database. In theory, I would think the “koha-common” package would contain the libraries needed for anything interfacing with Koha and then a person could use Ansible to keep the remote servers all consistently configured. Anyway, all that would require some work, which I know I’m not planning to do. At this point, it’s probably more worthwhile to focus on Elasticsearch development, although I think the plan is to keep Zebra around anyway, so decoupling it a bit from the Koha monolith wouldn’t necessarily be a bad idea… David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australiarpm Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Michael Hafen Sent: Wednesday, 19 July 2017 2:45 AM To: Kivilahti Olli-Antti <olli-antti.kivilahti@jns.fi> Cc: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Dedicated Zebra Server I'm thinking of doing something like this too. I'd really like to see the zebra var's from the koha_conf.xml too, if possible. Thanks. On Tue, Jul 18, 2017 at 8:37 AM, Kivilahti Olli-Antti <olli-antti.kivilahti@jns.fi <mailto:olli-antti.kivilahti@jns.fi> > wrote: Hi! We install Koha in a cluster of LXC containers: One haproxy for dns redirection and ssl offloading One container for MariaDB One for OPAC One for staff client One for Zebra One for misc stuff, like the SIP2-server One for ElasticSearch One for Memcached +containers for other support services With haproxy it is rather straight forward to start load balancing multiple "web bricks" if you choose to. We don't need to do it since we chose to buy a lot of hardware. Hardware is less expensive than work where we live in. This clusterization is simply to increase robustness and security. And actually has saved our bacon few times during the past years, when we get unidentifiable hard-drive freezes with the SIP2-container, or some cronjob has went awol and completely hogged all system resources available to it. Without containerization we would have had downtime. Also helps with simple DOS-attacks which can happen by accident. I recommend this type of setup. Unfortunately the debian packages add a lot of unnecesary cruft to each container so we use dev-install instead. Getting Zebra to work in a separate container: Zebra is really really really tightly wound into the make-toolchain Koha uses and there is no convenient way of separating it. Maybe you could just bind mount the zebradb-directory between containers. This might be enough to run Zebra separate of the Koha's source code. Since mass storage is very cheap, we just run two identical Koha instances from the same source code repo. We make several identical Koha-installations via the dev-install. The Zebra-one only has Zebra and Koha sources (no Apache2, MariaDB, etc packages needed by a standalone Koha). You can configure Zebra to listen on tcp socket via the $KOHA_CONF. You can conveniently centrally configure the same $KOHA_CONF to all the Koha containers, so they all find the same Zebra by the ip and the same MariaDB. This is best done with Ansible (since community has already started working towards Ansible) Separating Zebra to a isolated (and easily monitorable) environment is entirely possible. Here is a snippet from our Ansible infrastructure definitions where Koha is set up with capability: zebra These should be most of the Ansible steps needed together with Koha-source to get Zebra running standalone: ansible@hephaestus:~/KSAnsible$ cat roles/koha/tasks/capabilities/zebra.yml --- - name: Install zebrasrv and zebraidx apt: name: idzebra-2.0 become: yes - name: Create the zebra socket-dir and permissions file: path: "{{zebra_run_dir}}" owner: koha group: koha state: directory become: yes - name: Create the zebra lock-dir and permissions file: path: "{{zebra_lock_dir}}" owner: koha group: koha state: directory become: yes - name: Create the zebra data-dir and permissions file: path: "{{zebra_data_dir}}" owner: koha group: koha state: directory become: yes - name: Configure Zebra stripes lineinfile: path: "{{item.path}}" regexp: "{{item.regexp}}" line: "{{item.line}}" with_items: - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^memMax:" line: "memMax: {{zebra_index_mem}}" - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^register:" line: "register: {{zebra_data_dir}}/biblios/register:{{zebra_index_size}}" - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^shadow:" line: "shadow: {{zebra_data_dir}}/biblios/shadow:{{zebra_index_size}}" - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^sortmax:" line: "sortmax: {{zebra_sort_max}}" - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^facetNumRecs:" line: "facetNumRecs:{{zebra_facet_num_records}}" owner: koha become: yes notify: Restart Zebra - name: Zebra - Link Zebra-service file: src: "{{koha_dev_path}}/bin/koha-zebra-ctl.sh" dest: "/etc/init.d/koha-zebra-daemon" owner: root group: root state: "link" become: yes - name: Zebra - Enable Zebra-service systemd: name: koha-zebra-daemon enabled: yes daemon_reload: yes state: started become: yes - name: Zebra-index - Link Zebra-index-service file: src: "{{koha_dev_path}}/bin/koha-index-daemon-ctl.sh" dest: "/etc/init.d/koha-index-daemon" owner: root group: root state: "link" become: yes - name: Zebra-index - Enable Zebra-index-service systemd: name: koha-index-daemon enabled: yes daemon_reload: yes state: started become: yes - name: Deploy Zebra cronjobs template: owner: "{{koha_user}}" src: "etc_cron.d_koha.j2" dest: "/etc/cron.d/koha-zebra" vars: cronjobs: rbza: comment: '#Trigger full Zebra reindexing daily' prefix: ' ' timing: '46 10 * * *' user: 'koha' command: 'migration_tools/rebuild_zebra.pl <http://rebuild_zebra.pl> -b -a -r -v -x' become: yes _____ From: koha-devel-bounces@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org> [koha-devel-bounces@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org> ] on behalf of Mansur Ali [mansuralih@gmail.com <mailto:mansuralih@gmail.com> ] Sent: Tuesday, July 18, 2017 3:11 PM To: Tajoli Zeno Cc: koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Dedicated Zebra Server Thank you for your valuable information. On Tue, Jul 18, 2017 at 2:59 PM, Tajoli Zeno <z.tajoli@cineca.it <mailto:z.tajoli@cineca.it> > wrote: Hi, Il 18/07/2017 13:28, Mansur Ali ha scritto: Hello, I am using KOHA ILS. Can i able to use dedicated Zebra Server which is installed in another server? Could you please advice if possible? with present standard installation, the answer is no, it is not possible. In theory if: 1)You setup to use PazPar instead of Zebra [an old option not tested from years] AND 2)You rewrite the updating scripts and deamon you can try to do it. I suggest you to do a try only if you are very skilled on Zebra and others Indexdata's tools. Bye Zeno Tajoli -- Zeno Tajoli /SVILUPPO PRODOTTI CINECA/ - Automazione Biblioteche Email: z.tajoli@cineca.it <mailto:z.tajoli@cineca.it> Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) -- Mansur Ali +966568978721 <tel:+966%2056%20897%208721> | +919061635954 | mansuralih@gmail.com <mailto:mansuralih@gmail.com> _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> 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/ -- Michael Hafen Washington County School District Technology Department Systems Analyst
Thank you for your tremendous support. I have successfully integrated dedicated zebra server over TCP connection. In my existing system I am getting an error (*** Error in `zebraidx': corrupted double-linked list: 0x00000000012c6a30 ***) while indexing large database. Because of that I was looking the workaround and finally get done. I am glad to help somebody want to do this integration. On Wed, Jul 19, 2017 at 5:09 AM, David Cook <dcook@prosentient.com.au> wrote:
A sizeable portion of koha-conf.xml is actually Zebra configuration. An interesting task would be to separate out all the Zebra-specific stuff and put it in its own file, so that it was less intimidating and perhaps easier to manage.
For searching, Koha is just using a Z39.50 connection, so Zebra could be accessed over TCP on a different server.
For indexing, the indexing needs to happen on the Zebra server, and in order to index you need to have records from the Koha database. There’s a number of ways you could handle that I suppose… but yeah it currently is closely tied to the Koha application monolith. In theory, if your MySQL database was on yet another server, you’d just need an indexing script and the credentials to access the MySQL database.
I suppose there are some system preferences that get taken into account as well… but that’s still coming from the database.
In theory, I would think the “koha-common” package would contain the libraries needed for anything interfacing with Koha and then a person could use Ansible to keep the remote servers all consistently configured.
Anyway, all that would require some work, which I know I’m not planning to do. At this point, it’s probably more worthwhile to focus on Elasticsearch development, although I think the plan is to keep Zebra around anyway, so decoupling it a bit from the Koha monolith wouldn’t necessarily be a bad idea…
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australiarpm
Office: 02 9212 0899
Direct: 02 8005 0595
*From:* koha-devel-bounces@lists.koha-community.org [mailto: koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Michael Hafen *Sent:* Wednesday, 19 July 2017 2:45 AM *To:* Kivilahti Olli-Antti <olli-antti.kivilahti@jns.fi>
*Cc:* koha-devel@lists.koha-community.org *Subject:* Re: [Koha-devel] Dedicated Zebra Server
I'm thinking of doing something like this too. I'd really like to see the zebra var's from the koha_conf.xml too, if possible. Thanks.
On Tue, Jul 18, 2017 at 8:37 AM, Kivilahti Olli-Antti < olli-antti.kivilahti@jns.fi> wrote:
Hi!
We install Koha in a cluster of LXC containers:
One haproxy for dns redirection and ssl offloading One container for MariaDB One for OPAC One for staff client One for Zebra One for misc stuff, like the SIP2-server One for ElasticSearch One for Memcached +containers for other support services
With haproxy it is rather straight forward to start load balancing multiple "web bricks" if you choose to. We don't need to do it since we chose to buy a lot of hardware. Hardware is less expensive than work where we live in. This clusterization is simply to increase robustness and security. And actually has saved our bacon few times during the past years, when we get unidentifiable hard-drive freezes with the SIP2-container, or some cronjob has went awol and completely hogged all system resources available to it. Without containerization we would have had downtime. Also helps with simple DOS-attacks which can happen by accident.
I recommend this type of setup.
Unfortunately the debian packages add a lot of unnecesary cruft to each container so we use dev-install instead.
Getting Zebra to work in a separate container: Zebra is really really really tightly wound into the make-toolchain Koha uses and there is no convenient way of separating it. Maybe you could just bind mount the zebradb-directory between containers. This might be enough to run Zebra separate of the Koha's source code.
Since mass storage is very cheap, we just run two identical Koha instances from the same source code repo. We make several identical Koha-installations via the dev-install. The Zebra-one only has Zebra and Koha sources (no Apache2, MariaDB, etc packages needed by a standalone Koha). You can configure Zebra to listen on tcp socket via the $KOHA_CONF. You can conveniently centrally configure the same $KOHA_CONF to all the Koha containers, so they all find the same Zebra by the ip and the same MariaDB. This is best done with Ansible (since community has already started working towards Ansible)
Separating Zebra to a isolated (and easily monitorable) environment is entirely possible.
Here is a snippet from our Ansible infrastructure definitions where Koha is set up with capability: zebra
These should be most of the Ansible steps needed together with Koha-source to get Zebra running standalone:
ansible@hephaestus:~/KSAnsible$ cat roles/koha/tasks/capabilities/ zebra.yml
---
- name: Install zebrasrv and zebraidx apt: name: idzebra-2.0 become: yes
- name: Create the zebra socket-dir and permissions file: path: "{{zebra_run_dir}}" owner: koha group: koha state: directory become: yes
- name: Create the zebra lock-dir and permissions file: path: "{{zebra_lock_dir}}" owner: koha group: koha state: directory become: yes
- name: Create the zebra data-dir and permissions file: path: "{{zebra_data_dir}}" owner: koha group: koha state: directory become: yes
- name: Configure Zebra stripes lineinfile: path: "{{item.path}}" regexp: "{{item.regexp}}" line: "{{item.line}}" with_items: - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^memMax:" line: "memMax: {{zebra_index_mem}}" - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^register:" line: "register: {{zebra_data_dir}}/biblios/ register:{{zebra_index_size}}" - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^shadow:" line: "shadow: {{zebra_data_dir}}/biblios/ shadow:{{zebra_index_size}}" - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^sortmax:" line: "sortmax: {{zebra_sort_max}}" - path: "{{koha_dev_path}}/etc/zebradb/zebra-biblios-dom.cfg" regexp: "^facetNumRecs:" line: "facetNumRecs:{{zebra_facet_num_records}}" owner: koha become: yes notify: Restart Zebra
- name: Zebra - Link Zebra-service file: src: "{{koha_dev_path}}/bin/koha-zebra-ctl.sh" dest: "/etc/init.d/koha-zebra-daemon" owner: root group: root state: "link" become: yes
- name: Zebra - Enable Zebra-service systemd: name: koha-zebra-daemon enabled: yes daemon_reload: yes state: started become: yes
- name: Zebra-index - Link Zebra-index-service file: src: "{{koha_dev_path}}/bin/koha-index-daemon-ctl.sh" dest: "/etc/init.d/koha-index-daemon" owner: root group: root state: "link" become: yes
- name: Zebra-index - Enable Zebra-index-service systemd: name: koha-index-daemon enabled: yes daemon_reload: yes state: started become: yes
- name: Deploy Zebra cronjobs template: owner: "{{koha_user}}" src: "etc_cron.d_koha.j2" dest: "/etc/cron.d/koha-zebra" vars: cronjobs: rbza: comment: '#Trigger full Zebra reindexing daily' prefix: ' ' timing: '46 10 * * *' user: 'koha' command: 'migration_tools/rebuild_zebra.pl -b -a -r -v -x' become: yes
------------------------------
*From:* koha-devel-bounces@lists.koha-community.org [ koha-devel-bounces@lists.koha-community.org] on behalf of Mansur Ali [ mansuralih@gmail.com] *Sent:* Tuesday, July 18, 2017 3:11 PM *To:* Tajoli Zeno *Cc:* koha-devel@lists.koha-community.org *Subject:* Re: [Koha-devel] Dedicated Zebra Server
Thank you for your valuable information.
On Tue, Jul 18, 2017 at 2:59 PM, Tajoli Zeno <z.tajoli@cineca.it> wrote:
Hi,
Il 18/07/2017 13:28, Mansur Ali ha scritto:
Hello,
I am using KOHA ILS. Can i able to use dedicated Zebra Server which is installed in another server? Could you please advice if possible?
with present standard installation, the answer is no, it is not possible.
In theory if: 1)You setup to use PazPar instead of Zebra [an old option not tested from years] AND 2)You rewrite the updating scripts and deamon
you can try to do it.
I suggest you to do a try only if you are very skilled on Zebra and others Indexdata's tools.
Bye Zeno Tajoli
-- Zeno Tajoli /SVILUPPO PRODOTTI CINECA/ - Automazione Biblioteche Email: z.tajoli@cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)
--
Mansur Ali
+966568978721 <+966%2056%20897%208721> | +919061635954 | mansuralih@gmail.com
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
--
Michael Hafen
Washington County School District Technology Department
Systems Analyst
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
-- Mansur Ali +966568978721 | +919061635954 | mansuralih@gmail.com
Recently, people at the Apache Software Foundation have found that software released by Facebook using the Facebook BSD+Patents license, such as ReactJs, has patent terms which are incompatible with patent terms in Apache License version 2 (ALv2). Similar incompatibility seems to exist for patent terms in GPLv3 which Koha uses and GPLv2 which Koha had used previously. Unless Facebook chooses to fix the issue for ReactJS in some satisfactory manner as they have with RocksDB, there seems to be an insurmountable licensing issue preventing the use of ReactJS in Koha which had been proposed for the use with the OPAC. ReactJS alternatives such as Preact, https://preactjs.com/ , and Inferno, https://www.infernojs.org/ , should be investigated. Preact and Inferno use the permissively compatible MIT Athena license: https://github.com/developit/preact/blob/master/LICENSE, https://github.com/infernojs/inferno/blob/master/LICENSE.md . Inferno changed to the MIT Athena license in 2016 after previously using the Mozilla Public License version 2, https://github.com/infernojs/inferno/commit/144f96e8cf55c0ff3a7b27ab151f5d37... . In general, we need to be somewhat wary of potential licensing issues when using programming libraries. Merely reading the license file is not always sufficient for knowing the license which is applies to the software as in the example of ReactJS detailed further below. The license invocation statements may need to be read or parsed which could include every licensing header of every file. Furthermore, projects may change licenses over time which can introduce license conflicts as happened with ReactJS. REACTJS LICENSE HISTORY. Originally in 2013, Facebook released ReactJS under ALv2, , and required community contributors to submit to a contributors license agreement assigning all their rights to Facebook, https://github.com/facebook/react/commit/75897c2dcd1dd3a6ca46284dd37e13d22b4... . In 2014, the license terms were changed to Facebook BSD+Patents, https://github.com/facebook/react/commit/dcf415c2b91ce52fd5d4dd02b70875ba9d3... . In 2015, the patent terms were modified with a version 2 for the PATENTS file, https://github.com/facebook/react/commit/b8ba8c83f318b84e42933f6928f231dc091... . FACEBOOK BSD+PATENTS LICENSE. Facebook have been applying a Facebook BSD+Patents license to Facebook Open Source projects generally. The current license terms are invoked with language such as the following from README.md, https://github.com/facebook/react/blob/master/README.md . "React is BSD licensed. We also provide an additional patent grant." The LICENSE file contains a the permissively compatible 3 clause BSD copyright license in LICENSE, https://github.com/facebook/react/blob/master/LICENSE . The patent license in PATENTS is problematic, https://github.com/facebook/react/blob/master/PATENTS . Facebook have an Open Source License FAQ with a few sentences for just a little clarification of their Facebook BSD+Patents license, https://code.facebook.com/pages/850928938376556 . The following question and answer may be confirming the understanding that the breadth of conditions for terminating the Facebook patent grant applies to any Facebook patents which are granted for any and all software which Facebook have released under the Facebook BSD+Patents license, not merely those Facebook patents for one particular program at issue. "Does the additional patent grant in the Facebook BSD+Patents license terminate if Facebook sues me for patent infringement first, and then I respond with a patent counterclaim against Facebook? No, unless your patent counterclaim is related to Facebook's software licensed under the Facebook BSD+Patents license." Facebook patent terms appear to be designed to protect Facebook from patent litigation in a broader and more one sided manner than patent terms in free software licenses such as ALv2 and GPLv3 which do not have such breadth of termination, thus depriving users of patent defences under more circumstances. Roy T Fielding at the Apache Software Foundation has received confirmation from Facebook legal council that the explicit patent grant in the Facebook BSD+Patents license is intended to revoke any implied patent grant from the 3 clause BSD license, https://issues.apache.org/jira/browse/LEGAL-303?focusedCommentId=16046579 . Revocation of the implied patent grant is sufficient for incompatibility with the ALv2 and the Facebook BSD+Patents license . Accordingly, the Apache Software Foundation have required Apache Software Foundation projects to not incorporate software with the Facebook BSD+Patents License, https://www.apache.org/legal/resolved#category-x . Those Apache Software Foundation projects which have already included software with the Facebook BSD+Patents license are required to remove the covered Facebook software from their projects. Revocation of the implied patent grant also seems to be sufficient for incompatibility with the GPL. GPLv3 has the following language to protect patent defenses in section 11 Patents. "Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law." GPLv2 had other language to the same effect. Some discussion of the issue at the Apache Software Foundation for ReactJS specifically can be found at https://issues.apache.org/jira/browse/LEGAL-319 . Aaron Williamson writing under the username copiesofcopies has the best description of the complexities of patent relationships involved in the Facebook patent terms, https://github.com/facebook/react/issues/10191#issuecomment-316380810 . [I have consulted Aaron in the past for Koha when he was a lawyer at the Software Freedom Law Center.] REQUESTING REACTJS LICENSE CHANGE. Recently, people at Facebook conceded to change the license for RocksDB to the choice of ALv2 or GPLv2 only https://github.com/facebook/rocksdb/commit/3c327ac2d0fd50bbd82fe1f1af5de909d... . [Remember that ALv2 is compatible with GPLv3.] There is an effort to encourage people at Facebook to similarly change the license for ReactJS, https://github.com/facebook/react/issues/10191 . WHO WORRIES ABOUT PATENTS? Patents reading on software may not be a problem in your jurisdiction currently. A copyright license without any implied patent grant may seem good enough for you and never mind the incompatibility of software licenses if the incompatible terms are only about patents. Even in the US where the problem of patents reading on software originated, the US Supreme Court seems to be eroding the problem as some cases emerge. However, the problem of patents being read to cover software is not going away any time soon and the hazard may have merely been temporarily constrained a little in the US while patent lawyers work around newer constraints. The patent problem will remain for software in the US without either the unlikely event of a court case in which can only be concluded by excluding software from the scope of patents or the US Congress passing legislation to that effect. Even if tomorrow software would be found out of scope for patents in the US, the problem would still remain in many other jurisdictions where the US trade representative has worked tirelessly over years to export an overly broad scope for patents by hook or by crook in local laws, treaties, or wherever the application of patents can be added. People pursuing the interests of businesses, such as many large corporations, which use patents to suppress innovation and competition will also continually try to lobby governments to broaden the scope of patents to cover software even in jurisdictions where the breadth of patents has continually been restricted to exclude software. Some states in the US have legislative mandates for the state universities to pursue patents. Some of these universities may have an interest in using Koha. Using Koha should not expose any user to greater patent litigation risks than using some other software. Even if you or your organisation do not exercise patents, any jurisdiction in which patent infringement lawsuits can be brought exposes everyone in that jurisdiction to the hazard of possibly needing to defend against patent litigation or pay protection money to anyone posing a credible threat of such litigation. News reports about patent lawsuits mostly refer to those who create or distribute whatever may be covered by patents at issue, however, users who do not create or distribute but who are perceived as having sufficient resources to pay enough are targeted privately with the mere threat of patent lawsuits and coerced into paying protection money. ADDITIONAL REACTJS LICENSE PROBLEMS. Even if people at Facebook would relicense ReactJS again under a suitable GPLv3 compatible license, there are still other license problems about which to be wary. Facebook does not grant any license to redistribute code from code examples provided in the ReactJS documention or elsewhere, https://github.com/facebook/react/blob/master/LICENSE-examples . In my experience, Facebook are an outlier in their treatment of their own code examples so differently from the license for their own software project. License policies for Facebook Open Source should be expected to protect the interests of Facebook but there is a need for enough common ground to trust including software in Koha even without anything from code examples. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783
Hi! Thank you for your insight. I wouldn't be overtly alarmed by this license issue, however if there is a more free alternative we should use it. I don't mind having inconveniences due to using more free software. Struggle for our privacy, freedom of speech, and environment is inconvenient, but well worth the investment, however costly. The important framework improvements are "one-way data flow" and the underlying "state machine" (Redux-compatibility). Maybe server-side rendering. Looks like atleast InfernoJS proclaims support for those. Another take on the issue: https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revokable-patent-lice... OAK ________________________________________ From: koha-devel-bounces@lists.koha-community.org [koha-devel-bounces@lists.koha-community.org] on behalf of Thomas Dukleth [kohadevel@agogme.com] Sent: Friday, July 21, 2017 10:29 PM To: koha-devel@lists.koha-community.org Subject: [Koha-devel] ReactJS license problems Recently, people at the Apache Software Foundation have found that software released by Facebook using the Facebook BSD+Patents license, such as ReactJs, has patent terms which are incompatible with patent terms in Apache License version 2 (ALv2). Similar incompatibility seems to exist for patent terms in GPLv3 which Koha uses and GPLv2 which Koha had used previously. Unless Facebook chooses to fix the issue for ReactJS in some satisfactory manner as they have with RocksDB, there seems to be an insurmountable licensing issue preventing the use of ReactJS in Koha which had been proposed for the use with the OPAC. ReactJS alternatives such as Preact, https://preactjs.com/ , and Inferno, https://www.infernojs.org/ , should be investigated. Preact and Inferno use the permissively compatible MIT Athena license: https://github.com/developit/preact/blob/master/LICENSE, https://github.com/infernojs/inferno/blob/master/LICENSE.md . Inferno changed to the MIT Athena license in 2016 after previously using the Mozilla Public License version 2, https://github.com/infernojs/inferno/commit/144f96e8cf55c0ff3a7b27ab151f5d37... . In general, we need to be somewhat wary of potential licensing issues when using programming libraries. Merely reading the license file is not always sufficient for knowing the license which is applies to the software as in the example of ReactJS detailed further below. The license invocation statements may need to be read or parsed which could include every licensing header of every file. Furthermore, projects may change licenses over time which can introduce license conflicts as happened with ReactJS. REACTJS LICENSE HISTORY. Originally in 2013, Facebook released ReactJS under ALv2, , and required community contributors to submit to a contributors license agreement assigning all their rights to Facebook, https://github.com/facebook/react/commit/75897c2dcd1dd3a6ca46284dd37e13d22b4... . In 2014, the license terms were changed to Facebook BSD+Patents, https://github.com/facebook/react/commit/dcf415c2b91ce52fd5d4dd02b70875ba9d3... . In 2015, the patent terms were modified with a version 2 for the PATENTS file, https://github.com/facebook/react/commit/b8ba8c83f318b84e42933f6928f231dc091... . FACEBOOK BSD+PATENTS LICENSE. Facebook have been applying a Facebook BSD+Patents license to Facebook Open Source projects generally. The current license terms are invoked with language such as the following from README.md, https://github.com/facebook/react/blob/master/README.md . "React is BSD licensed. We also provide an additional patent grant." The LICENSE file contains a the permissively compatible 3 clause BSD copyright license in LICENSE, https://github.com/facebook/react/blob/master/LICENSE . The patent license in PATENTS is problematic, https://github.com/facebook/react/blob/master/PATENTS . Facebook have an Open Source License FAQ with a few sentences for just a little clarification of their Facebook BSD+Patents license, https://code.facebook.com/pages/850928938376556 . The following question and answer may be confirming the understanding that the breadth of conditions for terminating the Facebook patent grant applies to any Facebook patents which are granted for any and all software which Facebook have released under the Facebook BSD+Patents license, not merely those Facebook patents for one particular program at issue. "Does the additional patent grant in the Facebook BSD+Patents license terminate if Facebook sues me for patent infringement first, and then I respond with a patent counterclaim against Facebook? No, unless your patent counterclaim is related to Facebook's software licensed under the Facebook BSD+Patents license." Facebook patent terms appear to be designed to protect Facebook from patent litigation in a broader and more one sided manner than patent terms in free software licenses such as ALv2 and GPLv3 which do not have such breadth of termination, thus depriving users of patent defences under more circumstances. Roy T Fielding at the Apache Software Foundation has received confirmation from Facebook legal council that the explicit patent grant in the Facebook BSD+Patents license is intended to revoke any implied patent grant from the 3 clause BSD license, https://issues.apache.org/jira/browse/LEGAL-303?focusedCommentId=16046579 . Revocation of the implied patent grant is sufficient for incompatibility with the ALv2 and the Facebook BSD+Patents license . Accordingly, the Apache Software Foundation have required Apache Software Foundation projects to not incorporate software with the Facebook BSD+Patents License, https://www.apache.org/legal/resolved#category-x . Those Apache Software Foundation projects which have already included software with the Facebook BSD+Patents license are required to remove the covered Facebook software from their projects. Revocation of the implied patent grant also seems to be sufficient for incompatibility with the GPL. GPLv3 has the following language to protect patent defenses in section 11 Patents. "Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law." GPLv2 had other language to the same effect. Some discussion of the issue at the Apache Software Foundation for ReactJS specifically can be found at https://issues.apache.org/jira/browse/LEGAL-319 . Aaron Williamson writing under the username copiesofcopies has the best description of the complexities of patent relationships involved in the Facebook patent terms, https://github.com/facebook/react/issues/10191#issuecomment-316380810 . [I have consulted Aaron in the past for Koha when he was a lawyer at the Software Freedom Law Center.] REQUESTING REACTJS LICENSE CHANGE. Recently, people at Facebook conceded to change the license for RocksDB to the choice of ALv2 or GPLv2 only https://github.com/facebook/rocksdb/commit/3c327ac2d0fd50bbd82fe1f1af5de909d... . [Remember that ALv2 is compatible with GPLv3.] There is an effort to encourage people at Facebook to similarly change the license for ReactJS, https://github.com/facebook/react/issues/10191 . WHO WORRIES ABOUT PATENTS? Patents reading on software may not be a problem in your jurisdiction currently. A copyright license without any implied patent grant may seem good enough for you and never mind the incompatibility of software licenses if the incompatible terms are only about patents. Even in the US where the problem of patents reading on software originated, the US Supreme Court seems to be eroding the problem as some cases emerge. However, the problem of patents being read to cover software is not going away any time soon and the hazard may have merely been temporarily constrained a little in the US while patent lawyers work around newer constraints. The patent problem will remain for software in the US without either the unlikely event of a court case in which can only be concluded by excluding software from the scope of patents or the US Congress passing legislation to that effect. Even if tomorrow software would be found out of scope for patents in the US, the problem would still remain in many other jurisdictions where the US trade representative has worked tirelessly over years to export an overly broad scope for patents by hook or by crook in local laws, treaties, or wherever the application of patents can be added. People pursuing the interests of businesses, such as many large corporations, which use patents to suppress innovation and competition will also continually try to lobby governments to broaden the scope of patents to cover software even in jurisdictions where the breadth of patents has continually been restricted to exclude software. Some states in the US have legislative mandates for the state universities to pursue patents. Some of these universities may have an interest in using Koha. Using Koha should not expose any user to greater patent litigation risks than using some other software. Even if you or your organisation do not exercise patents, any jurisdiction in which patent infringement lawsuits can be brought exposes everyone in that jurisdiction to the hazard of possibly needing to defend against patent litigation or pay protection money to anyone posing a credible threat of such litigation. News reports about patent lawsuits mostly refer to those who create or distribute whatever may be covered by patents at issue, however, users who do not create or distribute but who are perceived as having sufficient resources to pay enough are targeted privately with the mere threat of patent lawsuits and coerced into paying protection money. ADDITIONAL REACTJS LICENSE PROBLEMS. Even if people at Facebook would relicense ReactJS again under a suitable GPLv3 compatible license, there are still other license problems about which to be wary. Facebook does not grant any license to redistribute code from code examples provided in the ReactJS documention or elsewhere, https://github.com/facebook/react/blob/master/LICENSE-examples . In my experience, Facebook are an outlier in their treatment of their own code examples so differently from the license for their own software project. License policies for Facebook Open Source should be expected to protect the interests of Facebook but there is a need for enough common ground to trust including software in Koha even without anything from code examples. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
I take Kivilahti Olli-Antti's response as helpfully encouraging examination of alternatives to ReactJS. I also try to emphasise that the actual sufficiently disqualifying problems with the ReactJS license are with license incompatibility as opposed to some possibility of problems over some scenario with patents which might never become an issue for any Koha user or contributor. [Remainder of reply inline.] On Mon, July 24, 2017 10:25, Kivilahti Olli-Antti wrote: [...] LICENSE INCOMPATIBILITY.
I wouldn't be overtly alarmed by this license issue,
The problem is primarily that the current ReactJS license seems to be incompatible with GPLv3, the license which we use for Koha as a whole. All the code which we incorporate into Koha, such as any programming libraries incorporated into Koha, must be compatible with the overall license for Koha. The Free Software Foundation (FSF) have a helpful guide to various software license and their GPL compatibility of various licenses, https://www.gnu.org/licenses/license-list.en.html . FSF have not yet included the Facebook BSD+Patents license in their licenses page which is updated very infrequently and cannot include every variation on standard license terms. In the absence of specific comment from FSF or their lawyers which we could obtain if the issue seemed too unclear, we may take the issue as carefully treated after consideration over months as reported by people at the Apache Software Foundation in communication with Facebook legal counsel confirming intended incompatibility between the Facebook BSD+Patents license for patent terms in Apache License version 2 (ALv2) where there is some language in GPLv3 which seems to also be incompatible on the same point of revocation of the implied patent license in the 3 clause BSD license. I cited Roy T Fielding's comment in my original message, https://issues.apache.org/jira/browse/LEGAL-303?focusedCommentId=16046579 . FREE SOFTWARE ALTERNATIVES.
however if there is a more free alternative we should use it.
Some have questioned whether the Facebook BSD+Patents license could qualify as a recognised free software license at all as the breadth of the patent license termination terms seem to violate the minimal requirements for freedom and the patent terms of the Open Standards Requirements of the Open Source Initiative (OSI), https://opensource.org/osr . The Facebook BSD+Patents license has very different terms from the OSI BSD+Patents license, https://opensource.org/licenses/BSDplusPatent . Some alternatives to ReactJS are under licenses for which there are no doubts about whether they are free software compatible with GPLv3.
I don't mind having inconveniences due to using more free software.
Struggle for our privacy, freedom of speech, and environment is inconvenient, but well worth the investment, however costly.
The important framework improvements are "one-way data flow" and the underlying "state machine" (Redux-compatibility). Maybe server-side rendering. Looks like atleast InfernoJS proclaims support for those.
MINIMISING PATENT PROBLEMS. There would be different issues to consider if the ReactJS license had some problematic patent terms but somehow not so problematic as to be incompatible with GPLv3.
Another take on the issue: https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revokable-patent-lice...
Dennis Walsh ignores the license incompatibility issue of Facebook BSD+Patents license in relation to ALv2 and also seems to similarly affect GPLv3 and GPLv2. He assumes that the primary hazard over patents from a Facebook BSD+Patents license is from Facebook directly. He assumes that no Facebook patents exist which read on ReactJS where he did not find them easily enough and no one has reported them to him. He does not treat the breadth of conditions for patent termination unrelated to any particular software under the Facebook BSD+Patents license which obviates assumptions about costs of replacing software relative to the costs of litigation. He dismisses any alternative scenarios citing one particular unlikely case, however, the most likely scenarios are indirect from the breadth of termination conditions and outside the scope of anything which he has considered. Any scenario for which there is an actual problem may be unlikely, however, if you or your organisation are in the midst of such a scenario the likelihood of its occurrence is moot for you or your organisation. Problems in patent disputes are often indirect as in the scenario described by Aaron Williamson which I had originally cited, https://github.com/facebook/react/issues/10191#issuecomment-316380810 . Starting from Aaron's example I could imagine some scenario which corresponds to what I am informed is the usual type of problem which is faced over patents, however, my alteration of Aaron's example may suffer in some detail from not being a lawyer. A university with a state mandate in law to pursue patents arising from government funded research could be be substituted for Cisco in Aaron's example. An issue covered by a traditional patent, not one reading on software, could be the issue pursued against a Facebook subsidiary. After terminating all patent licenses granted to the university under the Facebook BSD+Patents license, Facebook might not pursue a patent action over ReactJS use by the university especially where the use prior to termination would have been licensed. Yet, the university's loss of any Facebook patent license to assert in defence may be the opportunity for a patent troll (holding patents without any product using them) to threaten the university over some patent reading on ReactJS. The patent troll would know that the university would be likely to agree to pay protection money to license the patent held by the troll to avoid the cost of litigation especially without a Facebook patent license for the university to assert in defence. The troll would also not have to risk any possible Facebook patents being asserted by the university to invalidate any claims in the patent which the troll would be asserting. The goal of the patent troll is to obtain protection money without much risk of actually having to face the financial costs or other hazards of litigation. Even if GPLv3 license compatibility would not be a problem and even if almost all Koha users would never have even a traditional patent nor a mandate to pursue patents, we should not create potential burdens upon organisations which may be candidates for using Koha beyond the relatively simple obligations respecting free software. Certainly, we should not create a burden which Aaron Williamson describes as "compliance requires a burdensome -- maybe impossible -- degree of diligence." Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783
While I personally believe that patent aggression from Facebook would be suicidal for their open-source presence and gain them little, there is enough of a possibility to raise some concern. I keep my fingers crossed that Facebook will do the same for React as RocksDB, and dual-license under the APL. I have no arguments against using Preact; it is MIT licensed and seems to be drop-in compatible with React (including JSX, if we decide to make use of that in the future) aside from a few small differences. We could start now with Preact and switch to React if the license situation is settled down the road. 2017-07-24 9:21 GMT-06:00 Thomas Dukleth <kohadevel@agogme.com>:
I take Kivilahti Olli-Antti's response as helpfully encouraging examination of alternatives to ReactJS. I also try to emphasise that the actual sufficiently disqualifying problems with the ReactJS license are with license incompatibility as opposed to some possibility of problems over some scenario with patents which might never become an issue for any Koha user or contributor.
[Remainder of reply inline.]
On Mon, July 24, 2017 10:25, Kivilahti Olli-Antti wrote:
[...]
LICENSE INCOMPATIBILITY.
I wouldn't be overtly alarmed by this license issue,
The problem is primarily that the current ReactJS license seems to be incompatible with GPLv3, the license which we use for Koha as a whole. All the code which we incorporate into Koha, such as any programming libraries incorporated into Koha, must be compatible with the overall license for Koha. The Free Software Foundation (FSF) have a helpful guide to various software license and their GPL compatibility of various licenses, https://www.gnu.org/licenses/license-list.en.html . FSF have not yet included the Facebook BSD+Patents license in their licenses page which is updated very infrequently and cannot include every variation on standard license terms. In the absence of specific comment from FSF or their lawyers which we could obtain if the issue seemed too unclear, we may take the issue as carefully treated after consideration over months as reported by people at the Apache Software Foundation in communication with Facebook legal counsel confirming intended incompatibility between the Facebook BSD+Patents license for patent terms in Apache License version 2 (ALv2) where there is some language in GPLv3 which seems to also be incompatible on the same point of revocation of the implied patent license in the 3 clause BSD license. I cited Roy T Fielding's comment in my original message, https://issues.apache.org/jira/browse/LEGAL-303?focusedCommentId=16046579 .
FREE SOFTWARE ALTERNATIVES.
however if there is a more free alternative we should use it.
Some have questioned whether the Facebook BSD+Patents license could qualify as a recognised free software license at all as the breadth of the patent license termination terms seem to violate the minimal requirements for freedom and the patent terms of the Open Standards Requirements of the Open Source Initiative (OSI), https://opensource.org/osr . The Facebook BSD+Patents license has very different terms from the OSI BSD+Patents license, https://opensource.org/licenses/BSDplusPatent .
Some alternatives to ReactJS are under licenses for which there are no doubts about whether they are free software compatible with GPLv3.
I don't mind having inconveniences due to using more free software.
Struggle for our privacy, freedom of speech, and environment is inconvenient, but well worth the investment, however costly.
The important framework improvements are "one-way data flow" and the underlying "state machine" (Redux-compatibility). Maybe server-side rendering. Looks like atleast InfernoJS proclaims support for those.
MINIMISING PATENT PROBLEMS.
There would be different issues to consider if the ReactJS license had some problematic patent terms but somehow not so problematic as to be incompatible with GPLv3.
Another take on the issue: https://medium.com/@dwalsh.sdlr/react-facebook-and-the- revokable-patent-license-why-its-a-paper-25c40c50b562
Dennis Walsh ignores the license incompatibility issue of Facebook BSD+Patents license in relation to ALv2 and also seems to similarly affect GPLv3 and GPLv2. He assumes that the primary hazard over patents from a Facebook BSD+Patents license is from Facebook directly. He assumes that no Facebook patents exist which read on ReactJS where he did not find them easily enough and no one has reported them to him. He does not treat the breadth of conditions for patent termination unrelated to any particular software under the Facebook BSD+Patents license which obviates assumptions about costs of replacing software relative to the costs of litigation. He dismisses any alternative scenarios citing one particular unlikely case, however, the most likely scenarios are indirect from the breadth of termination conditions and outside the scope of anything which he has considered. Any scenario for which there is an actual problem may be unlikely, however, if you or your organisation are in the midst of such a scenario the likelihood of its occurrence is moot for you or your organisation.
Problems in patent disputes are often indirect as in the scenario described by Aaron Williamson which I had originally cited, https://github.com/facebook/react/issues/10191#issuecomment-316380810 . Starting from Aaron's example I could imagine some scenario which corresponds to what I am informed is the usual type of problem which is faced over patents, however, my alteration of Aaron's example may suffer in some detail from not being a lawyer. A university with a state mandate in law to pursue patents arising from government funded research could be be substituted for Cisco in Aaron's example. An issue covered by a traditional patent, not one reading on software, could be the issue pursued against a Facebook subsidiary. After terminating all patent licenses granted to the university under the Facebook BSD+Patents license, Facebook might not pursue a patent action over ReactJS use by the university especially where the use prior to termination would have been licensed. Yet, the university's loss of any Facebook patent license to assert in defence may be the opportunity for a patent troll (holding patents without any product using them) to threaten the university over some patent reading on ReactJS. The patent troll would know that the university would be likely to agree to pay protection money to license the patent held by the troll to avoid the cost of litigation especially without a Facebook patent license for the university to assert in defence. The troll would also not have to risk any possible Facebook patents being asserted by the university to invalidate any claims in the patent which the troll would be asserting. The goal of the patent troll is to obtain protection money without much risk of actually having to face the financial costs or other hazards of litigation.
Even if GPLv3 license compatibility would not be a problem and even if almost all Koha users would never have even a traditional patent nor a mandate to pursue patents, we should not create potential burdens upon organisations which may be candidates for using Koha beyond the relatively simple obligations respecting free software. Certainly, we should not create a burden which Aaron Williamson describes as "compliance requires a burdensome -- maybe impossible -- degree of diligence."
Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
-- Jesse Weaver
[Reply inline.] On Tue, July 25, 2017 06:42, Jesse wrote:
While I personally believe that patent aggression from Facebook would be suicidal for their open-source presence and gain them little, there is enough of a possibility to raise some concern.
As I tried to emphasise previously, the problem with Facebook BSD+Patents license is incompatibility with use in a program under free software licenses including it seems GPLv3. If the ReactJS license is incompatible with GPLv3, we need not analyse further. The Facebook BSD+Patents does protect from much possibility of Facebook patent aggression. Facebook need not do anything worse than issue software under such a license. If license incompatibility would not be a problem, the most likely hazard would be indirect as in the example case which I cited from Aaron Williamson which I tried to modify for something closer to a hypothetical situation affecting some possible organisation using Koha. [See the Minimising Patent Problems section in my previous message quoted further below.]
I keep my fingers crossed that Facebook will do the same for React as RocksDB, and dual-license under the APL.
A significant distinction which might lead Facebook to change the license away from Facebook BSD+Patents for RocksDB but not for ReactJS is that much of the code in RocksDB is from LevelDB written at Google. Yet, Facebook originally released ReactJS under Apache License version 2 which gives hope. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783
I have no arguments against using Preact; it is MIT licensed and seems to be drop-in compatible with React (including JSX, if we decide to make use of that in the future) aside from a few small differences. We could start now with Preact and switch to React if the license situation is settled down the road.
2017-07-24 9:21 GMT-06:00 Thomas Dukleth <kohadevel@agogme.com>:
I take Kivilahti Olli-Antti's response as helpfully encouraging examination of alternatives to ReactJS. I also try to emphasise that the actual sufficiently disqualifying problems with the ReactJS license are with license incompatibility as opposed to some possibility of problems over some scenario with patents which might never become an issue for any Koha user or contributor.
[Remainder of reply inline.]
On Mon, July 24, 2017 10:25, Kivilahti Olli-Antti wrote:
[...]
LICENSE INCOMPATIBILITY.
I wouldn't be overtly alarmed by this license issue,
The problem is primarily that the current ReactJS license seems to be incompatible with GPLv3, the license which we use for Koha as a whole. All the code which we incorporate into Koha, such as any programming libraries incorporated into Koha, must be compatible with the overall license for Koha. The Free Software Foundation (FSF) have a helpful guide to various software license and their GPL compatibility of various licenses, https://www.gnu.org/licenses/license-list.en.html . FSF have not yet included the Facebook BSD+Patents license in their licenses page which is updated very infrequently and cannot include every variation on standard license terms. In the absence of specific comment from FSF or their lawyers which we could obtain if the issue seemed too unclear, we may take the issue as carefully treated after consideration over months as reported by people at the Apache Software Foundation in communication with Facebook legal counsel confirming intended incompatibility between the Facebook BSD+Patents license for patent terms in Apache License version 2 (ALv2) where there is some language in GPLv3 which seems to also be incompatible on the same point of revocation of the implied patent license in the 3 clause BSD license. I cited Roy T Fielding's comment in my original message, https://issues.apache.org/jira/browse/LEGAL-303?focusedCommentId=16046579 .
FREE SOFTWARE ALTERNATIVES.
however if there is a more free alternative we should use it.
Some have questioned whether the Facebook BSD+Patents license could qualify as a recognised free software license at all as the breadth of the patent license termination terms seem to violate the minimal requirements for freedom and the patent terms of the Open Standards Requirements of the Open Source Initiative (OSI), https://opensource.org/osr . The Facebook BSD+Patents license has very different terms from the OSI BSD+Patents license, https://opensource.org/licenses/BSDplusPatent .
Some alternatives to ReactJS are under licenses for which there are no doubts about whether they are free software compatible with GPLv3.
I don't mind having inconveniences due to using more free software.
Struggle for our privacy, freedom of speech, and environment is inconvenient, but well worth the investment, however costly.
The important framework improvements are "one-way data flow" and the underlying "state machine" (Redux-compatibility). Maybe server-side rendering. Looks like atleast InfernoJS proclaims support for those.
MINIMISING PATENT PROBLEMS.
There would be different issues to consider if the ReactJS license had some problematic patent terms but somehow not so problematic as to be incompatible with GPLv3.
Another take on the issue: https://medium.com/@dwalsh.sdlr/react-facebook-and-the- revokable-patent-license-why-its-a-paper-25c40c50b562
Dennis Walsh ignores the license incompatibility issue of Facebook BSD+Patents license in relation to ALv2 and also seems to similarly affect GPLv3 and GPLv2. He assumes that the primary hazard over patents from a Facebook BSD+Patents license is from Facebook directly. He assumes that no Facebook patents exist which read on ReactJS where he did not find them easily enough and no one has reported them to him. He does not treat the breadth of conditions for patent termination unrelated to any particular software under the Facebook BSD+Patents license which obviates assumptions about costs of replacing software relative to the costs of litigation. He dismisses any alternative scenarios citing one particular unlikely case, however, the most likely scenarios are indirect from the breadth of termination conditions and outside the scope of anything which he has considered. Any scenario for which there is an actual problem may be unlikely, however, if you or your organisation are in the midst of such a scenario the likelihood of its occurrence is moot for you or your organisation.
Problems in patent disputes are often indirect as in the scenario described by Aaron Williamson which I had originally cited, https://github.com/facebook/react/issues/10191#issuecomment-316380810 . Starting from Aaron's example I could imagine some scenario which corresponds to what I am informed is the usual type of problem which is faced over patents, however, my alteration of Aaron's example may suffer in some detail from not being a lawyer. A university with a state mandate in law to pursue patents arising from government funded research could be be substituted for Cisco in Aaron's example. An issue covered by a traditional patent, not one reading on software, could be the issue pursued against a Facebook subsidiary. After terminating all patent licenses granted to the university under the Facebook BSD+Patents license, Facebook might not pursue a patent action over ReactJS use by the university especially where the use prior to termination would have been licensed. Yet, the university's loss of any Facebook patent license to assert in defence may be the opportunity for a patent troll (holding patents without any product using them) to threaten the university over some patent reading on ReactJS. The patent troll would know that the university would be likely to agree to pay protection money to license the patent held by the troll to avoid the cost of litigation especially without a Facebook patent license for the university to assert in defence. The troll would also not have to risk any possible Facebook patents being asserted by the university to invalidate any claims in the patent which the troll would be asserting. The goal of the patent troll is to obtain protection money without much risk of actually having to face the financial costs or other hazards of litigation.
Even if GPLv3 license compatibility would not be a problem and even if almost all Koha users would never have even a traditional patent nor a mandate to pursue patents, we should not create potential burdens upon organisations which may be candidates for using Koha beyond the relatively simple obligations respecting free software. Certainly, we should not create a burden which Aaron Williamson describes as "compliance requires a burdensome -- maybe impossible -- degree of diligence."
Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
-- Jesse Weaver
This problem is about to be solved, it seems: https://code.facebook.com/posts/300798627056246/relicensing-react-jest-flow-... Regards El mar., 25 jul. 2017 a las 9:16, Thomas Dukleth (<kohadevel@agogme.com>) escribió:
[Reply inline.]
On Tue, July 25, 2017 06:42, Jesse wrote:
While I personally believe that patent aggression from Facebook would be suicidal for their open-source presence and gain them little, there is enough of a possibility to raise some concern.
As I tried to emphasise previously, the problem with Facebook BSD+Patents license is incompatibility with use in a program under free software licenses including it seems GPLv3. If the ReactJS license is incompatible with GPLv3, we need not analyse further.
The Facebook BSD+Patents does protect from much possibility of Facebook patent aggression. Facebook need not do anything worse than issue software under such a license. If license incompatibility would not be a problem, the most likely hazard would be indirect as in the example case which I cited from Aaron Williamson which I tried to modify for something closer to a hypothetical situation affecting some possible organisation using Koha. [See the Minimising Patent Problems section in my previous message quoted further below.]
I keep my fingers crossed that Facebook will do the same for React as RocksDB, and dual-license under the APL.
A significant distinction which might lead Facebook to change the license away from Facebook BSD+Patents for RocksDB but not for ReactJS is that much of the code in RocksDB is from LevelDB written at Google. Yet, Facebook originally released ReactJS under Apache License version 2 which gives hope.
Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 <(212)%20674-3783>
I have no arguments against using Preact; it is MIT licensed and seems to be drop-in compatible with React (including JSX, if we decide to make use of that in the future) aside from a few small differences. We could start now with Preact and switch to React if the license situation is settled down the road.
2017-07-24 9:21 GMT-06:00 Thomas Dukleth <kohadevel@agogme.com>:
I take Kivilahti Olli-Antti's response as helpfully encouraging examination of alternatives to ReactJS. I also try to emphasise that the actual sufficiently disqualifying problems with the ReactJS license are with license incompatibility as opposed to some possibility of problems over some scenario with patents which might never become an issue for any Koha user or contributor.
[Remainder of reply inline.]
On Mon, July 24, 2017 10:25, Kivilahti Olli-Antti wrote:
[...]
LICENSE INCOMPATIBILITY.
I wouldn't be overtly alarmed by this license issue,
The problem is primarily that the current ReactJS license seems to be incompatible with GPLv3, the license which we use for Koha as a whole. All the code which we incorporate into Koha, such as any programming libraries incorporated into Koha, must be compatible with the overall license for Koha. The Free Software Foundation (FSF) have a helpful guide to various software license and their GPL compatibility of various licenses, https://www.gnu.org/licenses/license-list.en.html . FSF have not yet included the Facebook BSD+Patents license in their licenses page which is updated very infrequently and cannot include every variation on standard license terms. In the absence of specific comment from FSF or their lawyers which we could obtain if the issue seemed too unclear, we may take the issue as carefully treated after consideration over months as reported by people at the Apache Software Foundation in communication with Facebook legal counsel confirming intended incompatibility between the Facebook BSD+Patents license for patent terms in Apache License version 2 (ALv2) where there is some language in GPLv3 which seems to also be incompatible on the same point of revocation of the implied patent license in the 3 clause BSD license. I cited Roy T Fielding's comment in my original message,
https://issues.apache.org/jira/browse/LEGAL-303?focusedCommentId=16046579
.
FREE SOFTWARE ALTERNATIVES.
however if there is a more free alternative we should use it.
Some have questioned whether the Facebook BSD+Patents license could qualify as a recognised free software license at all as the breadth of the patent license termination terms seem to violate the minimal requirements for freedom and the patent terms of the Open Standards Requirements of the Open Source Initiative (OSI), https://opensource.org/osr . The Facebook BSD+Patents license has very different terms from the OSI BSD+Patents license, https://opensource.org/licenses/BSDplusPatent .
Some alternatives to ReactJS are under licenses for which there are no doubts about whether they are free software compatible with GPLv3.
I don't mind having inconveniences due to using more free software.
Struggle for our privacy, freedom of speech, and environment is inconvenient, but well worth the investment, however costly.
The important framework improvements are "one-way data flow" and the underlying "state machine" (Redux-compatibility). Maybe server-side rendering. Looks like atleast InfernoJS proclaims support for those.
MINIMISING PATENT PROBLEMS.
There would be different issues to consider if the ReactJS license had some problematic patent terms but somehow not so problematic as to be incompatible with GPLv3.
Another take on the issue: https://medium.com/@dwalsh.sdlr/react-facebook-and-the- revokable-patent-license-why-its-a-paper-25c40c50b562
Dennis Walsh ignores the license incompatibility issue of Facebook BSD+Patents license in relation to ALv2 and also seems to similarly affect GPLv3 and GPLv2. He assumes that the primary hazard over patents from a Facebook BSD+Patents license is from Facebook directly. He assumes that no Facebook patents exist which read on ReactJS where he did not find them easily enough and no one has reported them to him. He does not treat the breadth of conditions for patent termination unrelated to any particular software under the Facebook BSD+Patents license which obviates assumptions about costs of replacing software relative to the costs of litigation. He dismisses any alternative scenarios citing one particular unlikely case, however, the most likely scenarios are indirect from the breadth of termination conditions and outside the scope of anything which he has considered. Any scenario for which there is an actual problem may be unlikely, however, if you or your organisation are in the midst of such a scenario the likelihood of its occurrence is moot for you or your organisation.
Problems in patent disputes are often indirect as in the scenario described by Aaron Williamson which I had originally cited, https://github.com/facebook/react/issues/10191#issuecomment-316380810 . Starting from Aaron's example I could imagine some scenario which corresponds to what I am informed is the usual type of problem which is faced over patents, however, my alteration of Aaron's example may suffer in some detail from not being a lawyer. A university with a state mandate in law to pursue patents arising from government funded research could be be substituted for Cisco in Aaron's example. An issue covered by a traditional patent, not one reading on software, could be the issue pursued against a Facebook subsidiary. After terminating all patent licenses granted to the university under the Facebook BSD+Patents license, Facebook might not pursue a patent action over ReactJS use by the university especially where the use prior to termination would have been licensed. Yet, the university's loss of any Facebook patent license to assert in defence may be the opportunity for a patent troll (holding patents without any product using them) to threaten the university over some patent reading on ReactJS. The patent troll would know that the university would be likely to agree to pay protection money to license the patent held by the troll to avoid the cost of litigation especially without a Facebook patent license for the university to assert in defence. The troll would also not have to risk any possible Facebook patents being asserted by the university to invalidate any claims in the patent which the troll would be asserting. The goal of the patent troll is to obtain protection money without much risk of actually having to face the financial costs or other hazards of litigation.
Even if GPLv3 license compatibility would not be a problem and even if almost all Koha users would never have even a traditional patent nor a mandate to pursue patents, we should not create potential burdens upon organisations which may be candidates for using Koha beyond the relatively simple obligations respecting free software. Certainly, we should not create a burden which Aaron Williamson describes as "compliance requires a burdensome -- maybe impossible -- degree of diligence."
Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 <(212)%20674-3783>
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
-- Jesse Weaver
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F
participants (8)
-
David Cook -
Jesse -
Kivilahti Olli-Antti -
Mansur Ali -
Michael Hafen -
Tajoli Zeno -
Thomas Dukleth -
Tomas Cohen Arazi