netbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: Optional modules with GPL dependencies (was: What to include/exclude in code donation to Apache)
Date Sun, 06 Nov 2016 08:59:25 GMT
I give up. If you don't see that there is a difference between an operating
system and a JAR file (with the JRE somewhere in the middle), I am not
going to re-re-re-re-re-reiterate the view that we are not lawyers, and if
you had some more experience with interacting with them perhaps you would
be less assertive.

I am done.


On Sun, Nov 6, 2016 at 1:15 PM, Wade Chandler <>

> 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" <> 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 <>
> > 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
> > - New Energy for Java
> >

Niclas Hedhman, Software Developer - New Energy for Java

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