netbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <>
Subject Re: Optional modules with GPL dependencies (was: What to include/exclude in code donation to Apache)
Date Sat, 05 Nov 2016 16:22:35 GMT
I think there is “what can be at Apache; source or built artifacts” and “what can my
platform application include in its final build; which isn’t at Apache; even if it uses
an Apache license” and “how can Apache NetBeans help me package my dependencies, per my
choices, regardless of Apache’s business and legal decisions for their own products/projects”.
I think these are inevitably going to be part of the concerns, and perhaps some of yours Neil;
if I’m off base, then fine. However, even if someone has based their product on the full
IDE, and not just the platform, I think we could design the project in such a way that dependencies
could be pre-bundled or not, depending on how things are built, but Apache never do the part
where the dependencies are “included” in an official Apache build. To me, that completely
satisfies the “resolved” page.


> On Nov 5, 2016, at 09:47, Neil C Smith <> wrote:
> Hi All,
> Finally joined up to this mailing list, so may be missing a lot of
> context on this, but this concerns what was probably my first question
> back to Geertjan when he asked if I'd be included in the initial
> announcement ..
> On 5 November 2016 at 05:52, Niclas Hedhman <> wrote:
>> Ideally, I think ASF as a whole would like to see a solution where there is
>> no dependency on such a component, and that a "regular OpenJDK system
>> requirement" existed instead.
> This has to be the goal in my opinion, if not the immediate outcome.
> My platform application uses both the Java cluster and (another)
> forked javac as part of its runtime - I've done more looking at the
> relationships here than I'd like!  I don't think it's possible to
> truly separate out the licensing and technical details.  The Java
> cluster depends on internal aspects of javac (or a fork of it), in
> turn depending on internal features of the JRE.  That might all get
> more fun with Java 9.  Having the regular OpenJDK tooling support what
> this project requires surely benefits all projects building similar
> tools?!
>> Netbeans community need an unambiguous answer from VP Legal Affairs, whether the
>> "java" cluster at Apache Netbeans, that will end up depending on nb-javac,
>> is exempt from required to be released as GPL. I am pretty sure a lawyer's
>> input is needed on this.
> I'd be surprised if that proved to be the case, because surely that
> would demolish the CPE?  However, I share your concerns about this
> being somewhat annoying - in fact, probably more than somewhat!
> Apologies if this is covering old ground (I need to read through the
> archives!), but -
> * what actually is the plan for developing / maintaining nb-javac as a
> "separate" project, and ensuring it keeps track of the potentially
> shifting landscape of internal APIs?
> * in what way is nb-javac actually forked? and what stops those
> changes being adopted upstream to be (semi)official API in javac
> itself?
> * has the option of dual-licensing javac and other tools been
> considered by Oracle? Extreme long shot I realise, but it's really not
> unprecedented, and potentially highly beneficial, for tooling to be
> more liberally licensed!

View raw message