神刀安全网

Does Running Java on Docker Containers Violate Agreements?

In a recent blog post Henn Idan raised an issue that using Oracle Java in containers could be violating the Oracle licensing agreements . This was raised in response to an initial tweet recommending a recompiled version of Java for Alpine Linux to which Ben Evans suggested this was an express violation of the Oracle license .

Although OpenJDK is available under the GPL , the OracleJDK compiled binaries that are available for download from java.com have a different binary license. Since Oracle owns the copyright to the code, they are able to release versions that aren’t under the GPL – and the JRE that comes from Oracle also includes certain technologies like the Applet plug-in and Java WebStart which are used by companies to launch GUIs in a platform-independent manner. It also includes features such as Flight Recorder and Mission Control that are free for development use but require additional licenses for production use.

The Oracle Binary Code License Agreement for Java SE comes with a license to use the product (either the JDK or the JRE):

2. LICENSE TO USE. Subject to the terms and conditions of this Agreement including, but not limited to, the Java Technology Restrictions of the Supplemental License Terms, Oracle grants you a non-exclusive, non-transferable, limited license without license fees to reproduce and use internally the Software complete and unmodified for the sole purpose of running Programs.

Since this license is non-transferrable, it does not grant the ability to distribute software, nor does it allow for those to whom the software has been distributed to use it.

There is an additional supplemental license term which gives some limited rights to redistribute the software:

C. LICENSE TO DISTRIBUTE SOFTWARE. Subject to the terms and conditions of this Agreement and restrictions and exceptions set forth in the README File, including, but not limited to the Java Technology Restrictions and Limitations on Redistribution of these Supplemental Terms, Oracle grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Programs, (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software, (iv) you do not remove or alter any proprietary legends or notices contained in the Software, (v) you only distribute the Software subject to a license agreement that: (a) is a complete, unmodified reproduction of this Agreement; or (b) protects Oracle’s interests consistent with the terms contained in this Agreement and that includes the notice set forth in Section H, and (vi) you agree to defend and indemnify Oracle and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys’ fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. The license set forth in this Section C does not extend to the Software identified in Section G.

Apart from the liability and indemnification (which may be of concern to some) the license itself allows the Java technology to be used for the sole purpose of running the programs (and, for example, that the programs aren’t just a simple Java launcher application). So if the Java runtime was distributed in conjunction with a product that might be acceptable; but in the case of Docker containers, when the Java runtime is in a different container image from the Java application itself, that may not be possible under these terms.

(The Section G defines restrictions on security patches that have been provided by Oracle Premier Support and is mentioned for reference only, as it does not affect the legitimacy of the standard Java redistribution itself. There’s even a Section E that defines publishers the rights to include JDK on electronic media with printed books or magazines; remember when printed magazines had CDs on them? Remember printed magazines, or for that matter, CDs?)

However, there is an additional supplemental term that permits distributing redistributables :

D. LICENSE TO DISTRIBUTE REDISTRIBUTABLES. Subject to the terms and conditions of this Agreement and restrictions and exceptions set forth in the README File, including but not limited to the Java Technology Restrictions and Limitations on Redistribution of these Supplemental Terms, Oracle grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute those files specifically identified as redistributable in the README File ("Redistributables") provided that: (i) you distribute the Redistributables complete and unmodified, and only bundled as part of Programs, (ii) the Programs add significant and primary functionality to the Redistributables, (iii) you do not distribute additional software intended to supersede any component(s) of the Redistributables (unless otherwise specified in the applicable README File), (iv) you do not remove or alter any proprietary legends or notices contained in or on the Redistributables, (v) you only distribute the Redistributables pursuant to a license agreement that: (a) is a complete, unmodified reproduction of this Agreement; or (b) protects Oracle’s interests consistent with the terms contained in the Agreement and includes the notice set forth in Section H, (vi) you agree to defend and indemnify Oracle and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys’ fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. The license set forth in this Section D does not extend to the Software identified in Section G.

Oracle’s README file contains a reference to Oracle’s website , that contains links to different README files. (The fact that they are not distributed or part of the JDK or JRE may be a concern to some, since there is no traceability as to the content of the README file over time.) The current version for JDK 8 has a section on redistribution for released versions (beta and pre-release versions may not be redistributed):

You may reproduce and distribute the Software (and also portions of Software identified below as Redistributable), provided that you comply with the terms and conditions of the Oracle Binary Code License Agreement for the Java SE Platform Products.

The term "vendors" used here refers to licensees, developers, and independent software vendors (ISVs) who license and distribute the Java Runtime Environment (JRE) with their programs.

Vendors must follow the terms of the Oracle Binary Code License Agreement for the Java SE Platform Products.

There are separate required and optional files in the distribution for both the JDK and the JRE:

Required vs. Optional Files

The files that make up the Java Runtime Environment (JRE) are divided into two categories: required and optional. Optional files may be excluded from redistributions of the JRE at the vendor’s discretion.

Please refer to the JRE Readme for details of which files are required and which files are optional when distributing a JRE.

The JRE Readme provides rights to reproduce and distribute versions (and portions) of the software under the Oracle Binary Code License. For example, JavaFX may be excluded, as may the contents of jre/ext . All non-optional files are required files, and must be distributed with the JRE; the JDK files must only be distributed in conjunction with a JRE.

These files are described in terms of the JDK and JRE version 8 and below. The reorganisation of JDK and JRE version 9 and above will result in a different agreement about what may be excluded or must be included. Some files, such as the cacerts certificate file, can be amended in order to keep up-to-date with changing certificates.

Java also ships with a limited form of security with 40-bit key strength, widely assumed to be trivially broken and the target of several degrade attacks (such asBEAST andPOODLE) but can be upgraded using the unlimited strength cryptography upgrade. However, it appears that these may not be redistributed but require the user to download them directly:

An unlimited strength version of these files indicating no restrictions on cryptographic strengths is available on the JDK web site for those living in eligible countries. Those living in eligible countries may download the unlimited strength version and replace the strong cryptography jar files with the unlimited strength files.

Since it’s likely that most modern applications will require a sane level of encryption out of the box, even if the rest of the environment could be redistributed the lack of security might be a significant issue. This may also be an issue with builds of the OpenJDK, separately from OracleJDK.

There are builds available for OpenJDK which suggests running  sudo apt-get install openjdk-8-jre or  su -c "yum install java-1.8.0-openjdk" from unspecified remote repositories. In Debian (and presumably Ubuntu’s) case, the latest version is openjdk-7 , although openjdk-8 is available in testing and openjdk-9 is available in experimental . These builds aren’t created by Oracle and therefore don’t have any support; in addition, it’s not necessarily clear what other patches have been applied or which tags were used to build from them.

Henn Idan describes this as Mystery Meat – you don’t know what you’re getting, and you don’t know its origin or history. Gil Tene, founder of Azul Systems , followed up and said that provided that the Java distribution has been tested with the Java Testing Compatibility Kit (TCK) it should be safe to use. He highlighted that Azul’s builds of Open JDK come with a certificate that confirms which version the build was performed from and an assertion that it passes the TCK. (Azul is one of several TCK licensees for Java.)

One of the problems highlighted in the Henn Idan blog post is the fact that the Docker openjdk image is built using the version from Debian unstable, since OpenJDK 8 is not yet available in a stable release. That would suggest anyone who has based a Docker image from this base repository has been using a release that explicitly has not been tested by Debian for Java conformance or any history. Since Debian has not made Java 8 available they are not likely to be interested in certification at this stage; however, the docker/openjdk repository appears to be the canonically available one from Docker. Regardless of the issues raised earlier regarding the redistribution of JDK parts, the fact that the canonical Docker image is based on a known unstable version from Debian should be a concern.

Finally, questions were raised about the legality of writing or using Docker files that download Oracle’s JDK  automatically. By setting a cookie value to represent clicking the "I agree" to the Oracle Java download it is possible to automate the download and installation of the JDK (or JRE) onto a target system. Although the Docker file itself isn’t against Oracle’s licensing rights, the downloaded image does not have redistribution rights. Since the Docker client will build an image snapshot based on the result of this command’s execution, but before the application’s files have been laid down, and then potentially make that image available for binary download elsewhere (for example, Docker Hub), that resulting image may itself be infringing. Since these rights are not necessarily transferrable, anyone then using such an Oracle image may be in violation of Oracle’s copyrights.

To avoid potential problems, Java users may instead decide to use another TCK certified Java runtime such as Zulu which has certified Docker images available for Java 6, 7 and 8 based on Ubuntu , on  Debian , or on Centos ; or by adding the Zulu repository to the package repository sources list. A separate (unsupported by Azul) smaller  JRE is available for Alpine Linux , along with a JDK . Note that the Zulu terms of use add additional terms, which include:

You also agree that you will not (and will not allow any third party to) use the Product, or allow the transfer, transmission, export, or re-export of the Product or any portion thereof in violation of any export control laws or regulations administered by the U.S. Commerce Department, OFAC, or any other government agency.

Since there are no ways of enforcing this from builds based on Docker Hub it may not be possible to use images distributed in that way. It’s also not clear whether these terms are in conflict with OpenJDK’s GPL, which states:

You may not impose any further restrictions on the recipients’ exercise of the rights granted herein.

At present there have been no publicly identified letters for copyright holders in the on-going Java debate, but with the rise of containers, the distribution of software becoming more modular and separate distribution for container layers, it is clear that distribution of these images may open both the users and the publishers of these images to public repositories to legal action. Those wishing to avoid this should seek independent legal advice.

InfoQ has summarised this information as is, and this should not be considered legal advice. Further corrections and updates to this post may occur as the situation changes or is re-evaluated.

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » Does Running Java on Docker Containers Violate Agreements?

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
分享按钮