netbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <wadechand...@apache.org>
Subject Re: Optional modules with GPL dependencies (was: What to include/exclude in code donation to Apache)
Date Sun, 06 Nov 2016 05:15:02 GMT
I am not sure what isn't clear. The OpenJDK uses the same license as
nb-javac; GPL+CDE. Precedent is based on the reality that things exist now
with the same license and use. The "resolved" document  states clearly this
same use case in question. Why would a dependency on nb-javac differ from
OpenJDK with the same license with both being Java class dependencies
(java.lang.String versus X)? This strictly from a legal and business point
of view as outlined in "resolved", not of a specific dependency, but of
specific licenses and use.

Sure, we should ask legal if unsure, but if these documents which draw a
direct parallel to this discussion are only a guide even when as precise,
it is as if no decisions have been made, and the language in them should be
changed to include something along the lines of "Ask legal about your
specific case regardless of the same license and general use of a
dependency in question." in the case of those other licenses. "resolved"
has a specific connotation, as does the pages stated purpose and audience
at the top of its text.

Similar and identical seem misused here, as to me we are specifically
discussing licensing of dependencies, and their use, both of which are
addressed in the document, along with the exact license in question; GPL
with exceptions. Everyone understands nb-javac can't be distributed with an
Apache NetBeans per it's license; that everyone has agreed. We mentioned
making it easier for them to download the needed dependency, but that isn't
distribution from Apache or with the runtime.

If a license were in the "safe to use at Apache" list, surely the document
would be considered a rule. I doubt one would say, no don't do that;
regardless of the license, if it were in that list, and regardless of the
dependency.

In this case, the document specifically says if a dependency upon a
prohibited licensed dependency is needed, then a build and runtime
dependency are fine, just don't distribute the dependency. There is no
disputing that; this was part of what I copied and pasted it in my prior
email.

So, what is left? How does this differ from OpenJDK, mod_perl from httpd,
or any other dependency with a GPL exception based license (see Larry Walls
license comments on perl)?

I do not see a difference, and you are suggesting there is some
possibility, but not being precise as to what. If solved for OpenJDK, then
this should be solved for nb-javac, unless you are talking about something
else; classpath dependencies on OpenJDK are like classpath dependencies on
nb-javac, and the only reason, other than technical, is the same license,
and that is the question here with regard to legal that I see.

Perhaps we are seeing the words similar and identical differently as I am
focused on the license and a simple notion of a dependency where two things
deal in the notion of libraries and Java classes and classpaths, and not
the explicit named dependency. If we should check every case of a specific
named dependency, in this context, with the same license and use, then OK,
it is a mode of operation which is good to be aware of, but sounds heavy.

Regardless, if we trust the GPL+CPE classpath exception is considered
solved at Apache, considering the many Java libraries as precedent, then
there should not be a question of the Java cluster needing to be GPL+CPE
just because it has a GPL+CPE dependency which isn't distributed with it.
If so, then all the world's non-GPL+CPE Java projects are in trouble.

Perhaps you can clarify "Unless I am blind, this usecase is not examined
and explained", as we may not all be on the same page. What use case do you
have in mind explicitly, and does it differ with what I wrote above?

Wade

On Nov 5, 2016 10:17 PM, "Niclas Hedhman" <niclas@hedhman.org> wrote:

> Geerjan,
> my point is simply; Everyone say they understand, but then make comments
> that indicates that they don't.
>
>
> Like (not the only example),
>
> On Sun, Nov 6, 2016 at 3:20 AM, Wade Chandler <wadechandler@apache.org>
> wrote:
> > You would have to get specific here. nb-javac has a license now. It is
> > GPL+CPE, so it specifically, and how that would legally and technically
> > work per what is in the Apache legal "resolved" document, is a straight
> > line IMO; nothing to guess about other than implementation. The same
> would
> > be the case with any OpenJDK API ATM.
>
> "IMO" is not good enough. The "resolved" page is a guide, and not a rule
> book. It is a quick look up for *identical* usecases, not to be interpreted
> by laymen in *similar* ones.
> Unless I am blind, this usecase is not examined and explained, hence Legal
> input is strongly recommended. Licensing are not debatable items and not
> subject to layman's opinion what should be within our licensing principles
> or not. Even Legal expertise will disagree with each other, for instance a
> former Lawyer at ASF argued that GPL can not force someone else to provide
> their own copyrighted code under GPL, although the larger legal community
> tends to agree with FSF that it can. YMMV.
>
> > > Assuming the answer to my licensing question is no, then I'm
> > > interested in exactly how much nb-javac forks from javac and how
> > > maintainable it is from outside?
>
> Java (or more precisely, JRE, pre-OpenJDK) was deemed 15-20 years ago to be
> incompatible with Apache principles, and although Sun allowed
> redistribution of JRE, we couldn't do it. Java got classified the same as
> Windows, Linux and other prerequisites as a "System Requirement", and that
> term is only vaguely defined to be evaluated on a case-by-case basis. In
> the past (I was on Legal committee for 5 years or so) "System Requirement"
> questions that listed one or more library-type components, would be denied.
> IIRC, people tried that route for Hibernate, Berkley DB JE and Neo4j. Each
> case is different, and should be evaluated on its merits.
>
>
> > That could be done any way needed IMO. It could be forked and put on
> GitHub
> > directly by the NB community once NB is at Apache. So, it would just be
> an
> > OSS standalone component managed by the NB community; not Apache nor
> > Oracle. Other options are clearly open to discussion. I would like to
> hear
> > Oracle's POV on this.
>
> Yes. What I am requesting from the community is to find out form Legal
> whether this is for nb-javac only, or also the "java" cluster as a whole or
> in part.
>
> And as Geertjan pointed out else-thread, you want to find out "now" rather
> than at the first release, which would be more painful.
>
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message