www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jan Lahoda (Jira)" <j...@apache.org>
Subject [jira] [Commented] (LEGAL-489) Distributing javac (GPLv2+CPE) with Apache NetBeans convenience binaries
Date Fri, 08 Nov 2019 10:46:00 GMT

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

Jan Lahoda commented on LEGAL-489:
----------------------------------

NetBeans is producing multiple artifacts. But the primary is a zip convenience binary of the
IDE, and platform specific installers that install the content of the zip. After unpacking
or installing, the user has a launcher (netbeans or netbeans.exe) that is intended and generally
used to run the IDE, so in my opinion (IANAL), this would qualify as an executable.

> Distributing javac (GPLv2+CPE) with Apache NetBeans convenience binaries
> ------------------------------------------------------------------------
>
>                 Key: LEGAL-489
>                 URL: https://issues.apache.org/jira/browse/LEGAL-489
>             Project: Legal Discuss
>          Issue Type: Question
>          Components: Policy Question
>            Reporter: Jan Lahoda
>            Priority: Major
>
> h1. Summary
> Following the following comment:
>  3) Can we use GPL CPE in Apache Foo to do XYZ?
>  Open a specific Jira issue.
> from:
>  https://issues.apache.org/jira/browse/LEGAL-336
> I have a specific question that involves Apache NetBeans (more are likely to follow):
> Could Apache NetBeans bundle the javac (under the GPLv2 *with Classpath Exception*) with
its convenience binaries?
> More details follow.
> h1. Apache NetBeans
> Apache NetBeans is a Rich Client Platform and an Integrated Development Environment (IDE).
The IDE supports multiple languages, but the part of the IDE that supports development in
the Java programming language is important here. This is mostly an end-user application (as
opposed to libraries, like Apache Lucene), althought some non-Apache distributions also exist.
> h1. History
> The Java editor in (Apache) NetBeans is using the JDK's Java compiler, javac, to parse
the user's source code, to provide various Java IDE features (like, but not only, code completion,
refactoring, semantic highlighting). This is done for more than a decade. Before joining the
ASF, NetBeans has had its own version of the compiler (nb-javac), which was distributed together
with NetBeans. With the transition to Apache, an option has been added to NetBeans to use
javac that is in the JDK on which NetBeans runs (for JDK 9+) and the nb-javac is no longer
maintained by the Apache NetBeans project. The user is however given an option to download
and install nb-javac, which may improve the stability, and allow to use the NetBeans Java
editor while running on JDK 8.
> h1. The Problem
> While I believe the current status is reasonably in line with the Apache policy it has
drawbacks in convenience for our user community, and potentially much more work for the testing
and developer communities. The javac is also used by tools like Apache Ant or Apache Maven.
But, I believe, that they, unlike Apache NetBeans, use fairly straightfoward, simple and broadly
used interfaces to work with javac. Apache NetBeans, on the other hand, is using javac much
deeper and more broad way, e.g. it uses the javac's abstract syntax tree (AST) model, including
AST for sources that are erroneous (as, while the user types/works in the IDE, the sources
are erroneous very often, if not most of the time). And a particular combination of javac
and NetBeans may handle the sources less than ideally - e.g. by failing with an exception,
failing to perform requested action, performing slower, etc. The situation is improving with
every OpenJDK and NetBeans release, but not all users are willing to run NetBeans on the most
recent version of JDK. So those running an older JDK may run into issues, depending on their
project's size and complexity.
> The user may decide to install the nb-javac, which should provide better (and more tested)
behavior even on older JDKs, but having to install something separately breaks the out-of-the-box
experience, and for some user's may be difficult. So the current state has drawbacks for the
user community.
> The testing community, ideally, should test on multiple JDKs, with and without nb-javac,
which leads to much more (human and machine) effort.
> The dev community needs to write code that supports all JDKs since 9 (or 11) as best
as it can, which means all access to the new APIs using reflection, more testing, and overall
more work etc.
> h1. The Proposal
> My proposal here would be that Apache NetBeans would:
>  -be allowed to include the nb-javac (GPLv2 with Classpath Exception) together with its
convenience binaries. The Apache NetBeans project as such would not be releasing the nb-javac,
and would use an unmodified version released by some other party.
>  -keep the ability to run without nb-javac, although (depending on the project's decision)
with the option to only support selected JDKs for this mode, like possibly only the most recent
released version of JDK, or alike.
> h1. Alternatives
> The alternatives I can see include:
>  1. continue with the current approach, with its effect on all the user, test and dev
communities.
>  2. restrict very specifically on which JDK's Apache NetBeans can run (e.g. the lastest
released JDK at the time NetBeans was released)
>  3. use a different Java parser.
> But, out of these options, only 1. appears to be at all realistic to me. 2. would have
detrimental effect on the user community, and the effort needed for 3. is likely to be vastly
bigger than what the project can undertake.
> So the only alternative I can see is to continue with the current approach, with the
effects on all the communities.
> h1. Drawbacks
> It is difficult for me to see any significant drawback in bundling nb-javac with Apache
NetBeans convenience binaries. For users, testers and devs, this should be simpler. In the
(unlikely, IMO) scenario that there are any downstream distributions that don't want to distribute
nb-javac, they would use the ability to use the JDK's javac.



--
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


Mime
View raw message