As you are approaching the 2.0 release, this question gets more important for packagers.
I'd like to emphasize the legal problem with "JSON" again, because we have no way to update it, if our version in Fedora does not work. We therefore could not ship this component of Zabbix.
Thanks for reporting both issues. I'd like to address them asap in one of 2.0.x releases.
There is some discussion about this issue on zabbix blog http://blog.zabbix.com/putting-dots-on-jmx-monitoring/1673/#comment-9996
2.0.4 still contains non-free source-less org.json 
Read more about the JSON licensing problem in the following article:
https://bugzilla.redhat.com/show_bug.cgi?id=958533 – "android-json-org-java - Androids rewrite of the evil licensed Json.org" sounds like an option!
I'm not sure why that needs documenting. I'd rather say it needs action! Replace "json" with android-json or consider json-simple. That's how Gentoo ships the JMX gateway. It's almost 2 years now!
Debian is shipping "zabbix-java-gateway" with "libandroid-json-org-java" instead of evil-licensed non-free "libjson-java". Please drop/replace JSON and use only free dependencies. Thanks.
after solving licensing issue, version requirements should be still documented
Debian and Gentoo are shipping Java gateway with a different JSON library already. Could you please describe considerations that were thought of when choosing a replacement library?
Also, Zabbix is licensed under GPLv2 and json-simple (https://code.google.com/p/json-simple/) is licensed under "Apache License 2.0". According to https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses , these licenses are not compatible. Do we understand it correctly?
json_simple is under ASL 2.0 indeed. GPLv2 and ASL 2.0 are not compatible in the sense that ASL 2.0 is stricter. It is compatible with GPLv3 though.
Having a bundled Java component under a different free license isn't an issue, at all, as far as my legal knowledge goes. You are not linking binaries there! Best practice would be to remove them from the source tree in the first place.
Me leaning towards json_simple is purely pragmatic:
- Another distribution did it too
- It's already in the versions of Fedora/EPEL I need it in
- The current android-json RPM uses Maven, which is not available in EL5 and 6. I don't know about 7.
JSON.simple does not seem to developed anymore, does not support generics and we will need a wrapper to avoid "unchecked" warnings, see following issues:
- https://code.google.com/p/json-simple/issues/detail?id=15
- https://code.google.com/p/json-simple/issues/detail?id=84
- https://code.google.com/p/json-simple/issues/detail?id=93
What does the Gentoo package do to avoid these warnings?
There is a fork of JSON.simple called json-smart (https://code.google.com/p/json-smart/) and it supports generics, but it is not available in Debian, for instance.
The following issues might or might not be a problem for Zabbix, to be investigated:
- https://code.google.com/p/json-simple/issues/detail?id=73 (precision loss for big numbers)
- https://code.google.com/p/json-simple/issues/detail?id=91 (dependency on JUnit)
json-lib (http://json-lib.sourceforge.net/) is problematic, because it has dependencies and has a suspicious bug: http://sourceforge.net/p/json-lib/bugs/71/ .
Jackson looks promising: http://jackson.codehaus.org/ (no dependencies).
<richlv> what about licensing ?
"Open Source (Apache License – or, until 2.1, alternatively LGPL)"
asaveljevs See http://wiki.fasterxml.com/JacksonLicensing . As far as I understand Volker's answer above, we can use it, can't we?
asaveljevs Seems too heavyweight though.
Regarding Android's version of the JSON library, the Debian package (https://packages.debian.org/sid/libandroid-json-org-java) lists https://android.googlesource.com/platform/libcore/+/master/json as the homepage, but it is just a repository browser.
Is the Android's JSON library available for download somewhere (except the repository) and is it versioned?
It is versioned by the means of Git tags and that seems to be the one official place to get them:
http://pkgs.fedoraproject.org/cgit/android-json-org-java.git/tree/android-json-org-java.spec#n10
So it seems the decision is between JSON.simple and the Android's version. Other libraries either have dependencies, are too heavy-weight for this task, or are not available in the repositories.
Between these two, Android's version seems the best choice, because it is a live and respectable project, and is just a ready drop-in replacement for the original library. We shall probably go with it.
Now, the question is how do we keep these JAR files in the repository.
We have to keep them in the repository for now, because we are using Make. There is no Maven that will download the dependencies for us and we are not like writing ./configure checks to find the correct JAR files in the system.
Currently, all the JAR files in the repository (logback-core-0.9.27.jar, logback-classic-0.9.27.jar, slf4j-api-1.6.1.jar) are without source. Packages for Linux and other operating systems are going to remove them and use versions from other packages from the same packaging system. These JAR files will only be used for those getting Zabbix from Subversion or from a distribution archive. Does it matter that these JAR files are without source code?
Alternatively, Volker, you suggested that it would be best to remove libraries from the source tree. Did you have a vision of how to accomplish that?
Jackson actually has dependencies and quite a few:
Requires: joda-time >= 1.6.2
Requires: stax2-api >= 3.1.1
Requires: jsr-311 >= 1.1.1
Requires: objectweb-asm3 >= 3.3
BuildRequires: ant >= 1.8.2
BuildRequires: joda-time >= 1.6.2
BuildRequires: stax2-api >= 3.1.1
BuildRequires: jsr-311 >= 1.1.1
BuildRequires: objectweb-asm3 >= 3.3
BuildRequires: cglib >= 2.2
BuildRequires: groovy >= 1.8.5
The ant requirement is too new for EL6 and various other packages are not available there at all. The license(s) are fine from my understanding.
If you opt for Android-JSON, I'll try to get that packaged in EL6 somehow.
As far as your source code repository is concerned, you can keep whatever you want in there. That is totally up to you. I'm mostly concerned about the tarball. Its content shall be under free licenses only.
As of finding the JARs on a system, I suppose you can leave that up to the packager to sort out in the spec file and init script/unit file or whatever. But you can try to make this task as easy as possible for the packager.
Ad JAR sources: I think, if somebody asked you for the source code, you'll have to supply it. But there are no legal concerns, to my best knowledge. You can go ahead just like you did.
Thank you for the detailed answer, Volker. We shall opt for Android JSON.
Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-4800 .
The fix includes the following:
- JSON.org library was replaced by Android's JSON library;
- Java gateway now outputs compact JSON (see
ZBX-5546); - Java virtual machine requirements were documented (see
ZBX-5913); - versions of dependencies were documented;
- typo fix in one of the items in "Template JMX Generic".
For documentation updates, see the following pages:
(1) Volker suggested the following documentation fix on IRC: "... necessary dependencies are already included into the source tree." -> "... included in the source tree.".
<richlv> it would be highly useful to have a list of all gateway deps + their licences in the manual
asaveljevs Volker has also shared a list of licenses for C libraries that we use at http://fpaste.org/82166/39372021/:
iksemel LGPLv2+ mysql GPLv2 with exceptions postgresql PostgreSQL sqlite Public Domain libxml2 MIT curl MIT net-snmp BSD libssh2 BSD OpenIPMI LGPLv2+ and GPLv2+ or BSD openldap OpenLDAP unixODBC GPLv2+ and LGPLv2+ gnutls GPLv3+ and LGPLv2+
asaveljevs Applied Volker's suggestion and documented gateway dependency licenses:
- https://www.zabbix.com/documentation/2.0/manual/installation/requirements?&#java_gateway
- https://www.zabbix.com/documentation/2.2/manual/installation/requirements?&#java_gateway
- https://www.zabbix.com/documentation/2.4/manual/installation/requirements?&#java_gateway
asaveljevs RESOLVED.
<dimir> CLOSED
(2) listed template update in :
- https://www.zabbix.com/documentation/2.0/manual/introduction/whatsnew2012
- https://www.zabbix.com/documentation/2.2/manual/introduction/whatsnew223
wiper CLOSED
asaveljevs Removed the update from the links above and added to the following instead:
- https://www.zabbix.com/documentation/2.0/manual/introduction/whatsnew2013
- https://www.zabbix.com/documentation/2.2/manual/introduction/whatsnew226
asaveljevs RESOLVED.
<dimir> CLOSED
(3) I am still not confident about the license issue, what it requires us to do and what it does not. Let me share my doubts:
- https://android.googlesource.com/platform/libcore/+/master/json has an empty file named "MODULE_LICENSE_BSD_LIKE";
- https://android.googlesource.com/platform/libcore/+/master/json/src/main/java/org/json/JSON.java says the license is Apache License 2.0;
- http://www.apache.org/foundation/license-faq.html#WhatDoesItMEAN says that:
It requires you to:
- include a copy of the license in any redistribution you may make that includes Apache software;
- provide clear attribution to The Apache Software Foundation for any distributions that include Apache software.
- http://stackoverflow.com/questions/1007338/can-i-use-a-library-under-the-apache-software-license-2-0-in-a-commercial-applic says that:
You can use Apache-licensed libraries in your program so long as you include a copy of the Apache license, and you display a copy of the required copyright notice wherever your program displays copyright notices, for example in an installer package or "about" screen.
So, should we include Apache License into the JAR file? Should we show an attribution to The Apache Software foundation and where?
wiper Answering to the last question - would it be ok just to print out in console when starting java gateway?
andris After looking how other projects include licenses, I propose to create a directory src/zabbix_java/lib/licenses with files android-json-4.3_r3.1.txt, logback-classic-0.9.27.txt, logback-core-0.9.27.txt, slf4j-api-1.6.1.txt containing texts of component licenses. For example, android-json-4.3_r3.1.txt will contain text of Apache License 2.0. Then the licenses would be kept close to *.jar files.
To indicate that somewhere deep in the source tree we are redistributing components with different licenses, I propose to create a file LICENSES (in the top directory, where the file COPYING is placed) and write into the LICENSES file something like this:
Zabbix Java gateway includes components android-json-4.3_r3.1, Copyright (C) 2010 The Android Open Source Project logback-classic-0.9.27, Copyright (C) 1999-2012, QOS.ch logback-core-0.9.27, Copyright (C) 1999-2012, QOS.ch slf4j-api-1.6, Copyright (c) 2004-2013 QOS.ch. Their licenses are included in directory src/zabbix_java/lib/licenses.
But then we'll have to maintain the LICENSES and src/zabbix_java/lib/licenses/*.txt files when changing the *.jar files.
asaveljevs Useful introductory reading on free and open source software licenses: http://producingoss.com/en/legal.html .
asaveljevs Book "Understanding Open Source and Free Software Licensing" (see http://oreilly.com/openbook/osfreesoft/book/) goes more in-depth and describes each license in detail.
asaveljevs According to Apache License 2.0 (see http://www.apache.org/licenses/LICENSE-2.0.html), a derivative work is defined as follows:
"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.
Is Zabbix a derivative work according to this definition? Seems not and it seems that among rules in section 4 only rule 4a applies to us, but not rule 4d.
asaveljevs According to http://www.apache.org/licenses/GPL-compatibility.html and http://www.gnu.org/licenses/license-list.html#apache2 , Apache License 2.0 and GPLv2 are not compatible because of some patent-related issues. Still the question is open: can we use the Android JSON library at all?
asaveljevs http://www.dejacode.org/android_case_study.html describes the purpose of files like MODULE_LICENSE_BSD_LIKE.
asaveljevs Not sure whether we should include any mention of Apache license, but note that currently we do not display any copyright notices for the Java gateway.
volter I just spoke to Tom Callaway (Fedora legal). He confirmed what I think:
Due to the fact that no linking takes place, the licenses don't need to be compatible as they would have to be otherwise. Tom said it has to be considered like interpreted languages are:
That's to say, that you can keep the gateway under GPLv2+. It's not necessary to switch it to the ASL-2.0-compatible GPLv3+, since no linking takes place.
asaveljevs Thank you, Volker! Your input is of great help!
<dimir> CLOSED
(4) Oracle java 1.7 (1.7.0_45) compiler gives the following warning when compiling with -source 1.5
warning: [options] bootstrap class path not set in conjunction with -source 1.5
From Oracle blog (see https://blogs.oracle.com/darcy/entry/bootclasspath_older_source ):
To use javac from JDK N to cross-compiler to an older platform version, the correct practice is to:
Use the older -source setting.
Set the bootclasspath to compile against the rt.jar (or equivalent) for the older platform.If the second step is not taken, javac will dutifully use the old language rules combined with new libraries, which can result in class files that do not work on the older platform since references to non-existent methods can get included.
asaveljevs So it seems that this bug stems from an improper use of "-source" option and it is improper in two ways.
First, as wiper pointed out above, "-bootclasspath" option has to be specified, too. It was unclear to me where to actually find bootstrap classes for an older version of Java, so I asked a question on Stack Overflow: http://stackoverflow.com/questions/22168437/where-to-find-bootstrap-classes-when-cross-compiling-for-older-versions-of-java . Let's wait a bit until that is answered.
Second, in addition to specifying "-source", "-target" option has to be specified, too. Otherwise, if we specify "-source 1.5" without "-target 1.5" and compile with JDK 1.6, then the resulting class files will have major version of 50, which corresponds to Java 1.6 (see http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/javac.html#crosscomp-options for the reason and http://en.wikipedia.org/wiki/Java_class_file#General_layout for the mapping between class file and Java versions):
$ javac -source 1.5 Test.java $ javap -verbose Test.class | grep major major version: 50
I have checked the libraries we currently rely on and their versions are as follows:
slf4j-api-1.6.1.jar (major version 47, corresponds to Java 1.3) logback-core-0.9.27.jar (major version 49, corresponds to Java 1.5) logback-classic-0.9.27.jar (major version 49, corresponds to Java 1.5)
Currently, our android-json-4.3_r3.1.jar library has major version 50, so we will have to recompile it.
Another topic under consideration is providing a precompiled version of Java gateway on our download page at http://www.zabbix.com/download.php . We have to make sure we compile it correctly so that it works on older versions of JRE.
asaveljevs Turns out older versions of Java can be downloaded from http://www.oracle.com/technetwork/java/archive-139210.html .
asaveljevs Our Java gateway does not compile with Java 1.5:
$ make
src/com/zabbix/gateway/BinaryProtocolSpeaker.java:76: cannot find symbol
symbol : constructor String(byte[],java.nio.charset.Charset)
location: class java.lang.String
String request = new String(data, UTF8_CHARSET);
^
src/com/zabbix/gateway/BinaryProtocolSpeaker.java:92: cannot find symbol
symbol : method getBytes(java.nio.charset.Charset)
location: class java.lang.String
responseBytes = response.getBytes(UTF8_CHARSET);
^
src/com/zabbix/gateway/JMXItemChecker.java:163: incompatible types
found : java.lang.Object
required: javax.management.ObjectName
for (ObjectName name : mbsc.queryNames(null, null))
^
src/com/zabbix/gateway/JMXItemChecker.java:266: incompatible types
found : java.lang.Object
required: java.lang.String
for (String key : comp.getCompositeType().keySet())
^
4 errors
make[2]: *** [bin/zabbix-java-gateway-2.0.13rc1.jar] Error 1
make[1]: *** [install-recursive] Error 1
make: *** [install-recursive] Error 1
Since Java 1.5 is very old by now and is only available for download in the archive link above, I propose we make Java 1.6 the minimum requirement. For this reason, it is not necessary to recompile the Android JSON library, as I proposed above earlier.
I have also removed "-source" flag in r48093, because it does not do what we need: using "-source 1.5 -target -1.5" the gateway compiled well using JDK 1.6, but that was only because rt.jar from JDK 1.6 was used, which, in the compilation error above, has String(byte[], java.nio.charset.Charset) constructor. Compilation with JDK 1.5 fails in this case, because it does not have this constructor and, consequently, it will not run on JRE 1.5.
So instead of using "-source 1.5 -target 1.5" we should probably just mention in the documentation that those who provide a precompiled version of the gateway should use JDK 1.6 for compilation so that it runs for all users. Did that on the following pages:
- https://www.zabbix.com/documentation/2.0/manual/installation/requirements?&#java_gateway
- https://www.zabbix.com/documentation/2.2/manual/installation/requirements?&#java_gateway
- https://www.zabbix.com/documentation/2.4/manual/installation/requirements?&#java_gateway
asaveljevs RESOLVED.
<dimir> CLOSED
Tested, but the (3), (4) are still open.
(5)
a) https://www.zabbix.com/documentation/2.0/manual/concepts/java (and 2.2/2.4 pages) still says "Dependencies of Java gateway: Logback, SLF4J, and JSON.org library." - now that we have dependencies in the requirement page, maybe that sentence can be simply removed ?
b) 2.0 and 2.2 pages now only describe the current situation, but they should also list that "up to version n json.org library was shipped" or something similar
asaveljevs Updated the following pages:
- https://www.zabbix.com/documentation/2.0/manual/concepts/java?&#overview_of_files_in_java_gateway_distribution
- https://www.zabbix.com/documentation/2.2/manual/concepts/java?&#overview_of_files_in_java_gateway_distribution
- https://www.zabbix.com/documentation/2.4/manual/concepts/java?&#overview_of_files_in_java_gateway_distribution
Note that these pages mention versions up to which JSON.org library was shipped. So if we miss their releases before this task is closed, we should update these pages. RESOLVED.
<dimir> Re a). Yes, maybe remove, add link to
https://www.zabbix.com/documentation/2.0/manual/concepts/java (and 2.2/2.4) ?
Ah, it's the same page!
CLOSED
Moved to (3).
Successfully tested and reviewed the licenses situation.
Fixed in pre-2.0.13 r48258, pre-2.2.6 r48260, and pre-2.3.4 (trunk) r48262.
(6) Updated "What's new" and "Upgrade notes" pages at the following locations:
- https://www.zabbix.com/documentation/2.0/manual/introduction/whatsnew2013#daemon_improvements
- https://www.zabbix.com/documentation/2.2/manual/introduction/whatsnew226#daemon_improvements
- https://www.zabbix.com/documentation/2.0/manual/installation/upgrade_notes_2013
- https://www.zabbix.com/documentation/2.2/manual/installation/upgrade_notes_226
martins-v Reviewed. CLOSED.
<richlv> template change page seemed to miss item name change - added at https://www.zabbix.com/documentation/2.2/manual/installation/template_changes#template_changes_in_226
asaveljevs Reviewed. CLOSED.