Dedicated Zebra Server

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Dedicated Zebra Server

mansuralih
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 | [hidden email]


_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dedicated Zebra Server

Tajoli Zeno
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: [hidden email] Fax: 051/6132198
*CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)
_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dedicated Zebra Server

mansuralih
Thank you for your valuable information.



On Tue, Jul 18, 2017 at 2:59 PM, Tajoli Zeno <[hidden email]> 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: [hidden email] Fax: 051/6132198
*CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)



--
Mansur Ali

+966568978721 | +919061635954 | [hidden email]


_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dedicated Zebra Server

Kivilahti Olli-Antti
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: [hidden email] [[hidden email]] on behalf of Mansur Ali [[hidden email]]
Sent: Tuesday, July 18, 2017 3:11 PM
To: Tajoli Zeno
Cc: [hidden email]
Subject: Re: [Koha-devel] Dedicated Zebra Server

Thank you for your valuable information.



On Tue, Jul 18, 2017 at 2:59 PM, Tajoli Zeno <[hidden email]> 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: [hidden email] Fax: 051/6132198
*CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)



--
Mansur Ali

+966568978721 | +919061635954 | [hidden email]


_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dedicated Zebra Server

Michael Hafen-4
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 <[hidden email]> 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: [hidden email] [[hidden email]] on behalf of Mansur Ali [[hidden email]]
Sent: Tuesday, July 18, 2017 3:11 PM
To: Tajoli Zeno
Cc: [hidden email]
Subject: Re: [Koha-devel] Dedicated Zebra Server

Thank you for your valuable information.



On Tue, Jul 18, 2017 at 2:59 PM, Tajoli Zeno <[hidden email]> 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: [hidden email] Fax: 051/6132198
*CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)



--
Mansur Ali

<a href="tel:+966%2056%20897%208721" value="+966568978721" target="_blank">+966568978721 | +919061635954 | [hidden email]


_______________________________________________
Koha-devel mailing list
[hidden email]
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
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dedicated Zebra Server

David Cook

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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Hafen
Sent: Wednesday, 19 July 2017 2:45 AM
To: Kivilahti Olli-Antti <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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: [hidden email] [[hidden email]] on behalf of Mansur Ali [[hidden email]]
Sent: Tuesday, July 18, 2017 3:11 PM
To: Tajoli Zeno
Cc: [hidden email]
Subject: Re: [Koha-devel] Dedicated Zebra Server

Thank you for your valuable information.

 

On Tue, Jul 18, 2017 at 2:59 PM, Tajoli Zeno <[hidden email]> 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: [hidden email] Fax: 051/6132198
*CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)




--

Mansur Ali

<a href="tel:+966%2056%20897%208721" target="_blank">+966568978721 | +919061635954 | [hidden email]


_______________________________________________
Koha-devel mailing list
[hidden email]
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
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dedicated Zebra Server

mansuralih

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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Hafen
Sent: Wednesday, 19 July 2017 2:45 AM
To: Kivilahti Olli-Antti <[hidden email]>


Cc: [hidden email]
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 <[hidden email]> 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: [hidden email] [[hidden email]] on behalf of Mansur Ali [[hidden email]]
Sent: Tuesday, July 18, 2017 3:11 PM
To: Tajoli Zeno
Cc: [hidden email]
Subject: Re: [Koha-devel] Dedicated Zebra Server

Thank you for your valuable information.

 

On Tue, Jul 18, 2017 at 2:59 PM, Tajoli Zeno <[hidden email]> 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: [hidden email] Fax: 051/6132198
*CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)




--

Mansur Ali

<a href="tel:+966%2056%20897%208721" target="_blank">+966568978721 | +919061635954 | [hidden email]


_______________________________________________
Koha-devel mailing list
[hidden email]
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
[hidden email]
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 | [hidden email]


_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ReactJS license problems

Thomas Dukleth
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/144f96e8cf55c0ff3a7b27ab151f5d376b1106cc
.

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/75897c2dcd1dd3a6ca46284dd37e13d22b4b16b4
.  In 2014, the license terms were changed to Facebook BSD+Patents,
https://github.com/facebook/react/commit/dcf415c2b91ce52fd5d4dd02b70875ba9d33290f#diff-6a3371457528722a734f3c51d9238c13
.  In 2015, the patent terms were modified with a version 2 for the
PATENTS file,
https://github.com/facebook/react/commit/b8ba8c83f318b84e42933f6928f231dc0918f864#diff-7373d27f0ea94a5b649f893e20fffeda
.


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/3c327ac2d0fd50bbd82fe1f1af5de909dad769e6
.  [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
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ReactJS license problems

Kivilahti Olli-Antti
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-license-why-its-a-paper-25c40c50b562

OAK
________________________________________
From: [hidden email] [[hidden email]] on behalf of Thomas Dukleth [[hidden email]]
Sent: Friday, July 21, 2017 10:29 PM
To: [hidden email]
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/144f96e8cf55c0ff3a7b27ab151f5d376b1106cc
.

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/75897c2dcd1dd3a6ca46284dd37e13d22b4b16b4
.  In 2014, the license terms were changed to Facebook BSD+Patents,
https://github.com/facebook/react/commit/dcf415c2b91ce52fd5d4dd02b70875ba9d33290f#diff-6a3371457528722a734f3c51d9238c13
.  In 2015, the patent terms were modified with a version 2 for the
PATENTS file,
https://github.com/facebook/react/commit/b8ba8c83f318b84e42933f6928f231dc0918f864#diff-7373d27f0ea94a5b649f893e20fffeda
.


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/3c327ac2d0fd50bbd82fe1f1af5de909dad769e6
.  [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
[hidden email]
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/
_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ReactJS license problems

Thomas Dukleth
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
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ReactJS license problems

Jesse-34
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 <[hidden email]>:
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
[hidden email]
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
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ReactJS license problems

Thomas Dukleth
[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 <[hidden email]>:
>
>> 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
>> [hidden email]
>> 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
[hidden email]
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/
Loading...