You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by "Henri Yandell (Jira)" <ji...@apache.org> on 2019/10/25 05:32:00 UTC

[jira] [Commented] (LEGAL-484) Oracle JDK change of license terms

    [ https://issues.apache.org/jira/browse/LEGAL-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16959443#comment-16959443 ] 

Henri Yandell commented on LEGAL-484:
-------------------------------------

Reading the license text, my take is that ASF committers should not use Oracle JDK on ASF projects, and Oracle JDK should definitely not be included in any ASF releases. The license is anti-community. It's company-friendly but not friendly to individuals who don't happen to own a company or work on ASF code as a part of a company. 

The latter of these should nots (don't include in releases) is an easy one; the license does not permit distribution to third parties.

The former (do not use) is the result of more thought. The license does not permit individuals to work on ASF projects as they are not for only personal use. It feels that if you develop with Oracle JDK, the code you develop is now tainted and is intended to never be usable by anyone but yourself. Though that may be further than a license can go.

The only other option to use Oracle JDK is on behalf of a company or organization. Now, if you're contributing as a part of your dayjob, then that is probably okay, assuming your company is okay with the license. You can develop with Oracle JDK and contribute to Apache. The other way is if you are creating the software on behalf of the ASF themselves. The ASF has only a few employees where it is clear that they work on behalf of the ASF. The foundation officers also probably work on behalf of the ASF. After that it's less clear (members, committers, and contributors). 

Thus I end up with the view that only individuals who are contributing to the ASF as a part of their work for a company, and whose employer are okay with the Oracle JDK license, should be touching Oracle JDK. Otherwise it should be treated like the plague.

Very interested in others' thoughts :)

> Oracle JDK change of license terms 
> -----------------------------------
>
>                 Key: LEGAL-484
>                 URL: https://issues.apache.org/jira/browse/LEGAL-484
>             Project: Legal Discuss
>          Issue Type: Question
>            Reporter: Suresh Marru
>            Priority: Major
>
> As per [1], the oracle JDK license terms seem to have changed as of April 16th 2019. With a naive understanding of the changes, ss there a recommended guidance on how or if an apache project should react to any of these license term changes? 
> [https://www.oracle.com/technetwork/java/javase/downloads/jdk11-downloads-5066655.html] 
> Thanks,
> Suresh



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: [jira] [Commented] (LEGAL-484) Oracle JDK change of license terms

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Henri Yandell (Jira) wrote on Fri, Oct 25, 2019 at 05:32:00 +0000:
> Thus I end up with the view that only individuals who are contributing to the ASF as a part of their work for a company, and whose employer are okay with the Oracle JDK license, should be touching Oracle JDK. Otherwise it should be treated like the plague.
> 
> Very interested in others' thoughts :)

First things first, let me quote quote the relevant part of the agreement (let
me know if I missed anything):

[[[
Definitions
===========

"Oracle" refers to Oracle America, Inc.

"You" and "Your" refers to (a) a company or organization (“Entity”) accessing
the Programs, if use of the Programs will be on behalf of such Entity; or (b)
an individual accessing the Programs (“Individual”), if use of the Programs
will not be on behalf of an Entity.

⋮

“Development Use” refers to Your internal use of the Programs to develop, test,
prototype and demonstrate Your Applications. For purposes of clarity, the “to
develop” grant includes using the Programs to run profilers, debuggers and
Integrated Development Environments (IDE Tools) where the primary purpose of
the IDE Tools is profiling, debugging and source code editing Applications.

"Program(s)" refers to Oracle software provided by Oracle pursuant to this
Agreement and any updates, error corrections, and/or Program Documentation
provided by Oracle.

“Program Documentation” refers to the Licensing Information User Manual for
Oracle Java SE for the applicable version accessible at
https://www.oracle.com/technetwork/java/javase/documentation/ and other
documentation provided by Oracle with the Programs or accessible at
https://docs.oracle.com/en/java.

⋮

“Application” refers to applications intended to run on the Java Platform,
Standard Edition.

“Personal Use” refers to an Individual's use of the Programs solely on a
desktop or laptop computer under such Individual's control only to run Personal
Applications.

“Personal Applications” refers to Applications designed for individual personal
use only, such as games or personal productivity tools.

⋮

License Rights and Restrictions
===============================

Oracle grants You a nonexclusive, nontransferable, limited license to use the
Programs, subject to the restrictions stated in this Agreement and Program
Documentation, only for:

(i)     Personal Use,
(ii)    Development Use,
⋮
]]]

My read:

- Option (i) boils down to "it's allowed to use java on a desktop or laptop
  computer … to run Applications designed for individual personal use only".
  That doesn't actually allow running a Java compiler or debugger; it's
  a permission to run Java applications, but not to develop them.  #dealbreaker

- Option (ii) speaks about "Your internal use".  Let's assume arguendo that
  "Your" is taken to mean case (a) of the definition of "You", with
  -DEntity=ASF.  Even with this permissive¹ interpretation, the definition of
  "Development Use" refers to "Your internal use" and it's not clear that doing
  development work on an open source product, _whose trunk or master branch is
  public_, qualifies.
  
  If we assume not only that "You" is case (a) with -DEntity=ASF but also that
  ASF's development workflows qualify as "internal use", I'd next ask whether
  "develop, test, prototype and demonstrate" is sufficient permissions.  For
  starters, that doesn't actually give us or our committers permission to _run_
  the programs we develop, other than for development and demonstration purposes.
  To actually run them ourselves — for example, to use a Java reimplementation
  of STeVe for the annual members meeting — we'd have to obtain a separate
  license, or use another java(1) implementation.

  So, my tentative conclusion is that we _would_ qualify for option (ii)
  "Development Use", _if_ all the following are true:
  
  - "You" means case (a) with -DEntity=ASF;
  - We qualify for "internal use";
  - A java(1) implementation to actually _run_ the product we develop is
    considered a "system dependency" (like GNU libc for C projects), _and_
    no other permission is needed beyond "develop, test, prototype and
    demonstrate";

  However, more pragmatically, the answer is quite simply that we don't qualify
  for "Development Use", for two reasons.  First, the first two assumptions are
  questionable at best, and as they say, "Where there's a doubt, there's no
  doubt".²  Second, since this revision of the license is more restrictive than
  the preceding one (the link in the OP says so in so many words³), I would err
  on the side of assuming that the next revision of the license is more likely
  to make it even _more_ restrictive, and rule us out, than to make it _less_
  restrictive and, say, actually allow us to run the code we develop without
  using another java(1) implementation, or purchasing an additional license.

tl;dr: Category X.

*ducks*

Daniel

¹ It's not clear that it covers non-committers.

² In this case, meaning: if it's not crystal clear that our use case is
permitted by the license, we should assume it isn't permitted.

³ That page says "The new license permits certain uses, such as personal use
and development use, at no cost -- but other uses authorized under prior Oracle
JDK licenses may no longer be available".

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org