You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2016/11/04 15:27:22 UTC
Optional modules with GPL dependencies (was: What to include/exclude
in code donation to Apache)
Hi,
Creating a new thread as this now off-topic w.r.t to including things
in the donation or not.
On Fri, Nov 4, 2016 at 4:06 PM, Ate Douma <at...@douma.nu> wrote:
> ...The question, as I see it, being:
>
> Will the Apache NetBeans project be allowed to develop and release
> a (or more) optional module, the Java Editor module in casu, under the
> ASL 2.0 license at the ASF, which depends on external 3rd party module
> nb-javac which is available under the GPL v2 w/ CPE (Category X).
> End users willing to use the optional module will be required to provide
> the nb-javac module themselves during installation.
>
I think this is a great way to formulate the issue.
IMO the "can Apache projects rely on components under prohibited
licenses?" section of http://apache.org/legal/resolved.html applies,
and the key question is then whether the external component's license
terms affect the NetBeans product's licensing.
If for example NetBeans depends on GPL licensed APIs that would be an
obstacle IMO.
OTOH if the affected modules can be released under our license with no
impact from those GPL modules everything's fine, IMO.
-Bertrand
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Jan Lahoda <la...@gmail.com>.
On Fri, Nov 4, 2016 at 4:59 PM, Geertjan Wielenga <
geertjan.wielenga@googlemail.com> wrote:
> On Fri, Nov 4, 2016 at 4:51 PM, Bertrand Delacretaz wrote:
>
> I'm clueless about the NetBeans code structure and what clusters are,
>
>
> That's precisely why I am putting together this:
> https://cwiki.apache.org/confluence/display/NETBEANS/
> Overview%3A+NetBeans+Structure
>
> but do you mean that nb-javac is a (customized?) Java compiler that's
> > required to build some parts of NetBeans?
>
>
> Yes.
>
> Aside from nb-javac (two JARs in total) being needed to build the "java"
> cluster, and related non-core clusters, it is needed by end users as well,
> which is possible as stated by Ate they "will be required to provide the
> nb-javac module themselves during installation".
>
To provide some more information:
-I believe nb-javac is not intended to execute during compilation of
NetBeans modules
-nb-javac is used as a library to parse, attribute, model and compile Java
source code
-nb-javac is basically a tweaked copy of javac (the langtools repository)
from OpenJDK
-nb-javac build produces two jars:
--the API jar, which basically contains javax.lang.model,
javax.annotation.processing, javax.tools and com.sun.source APIs whose
signatures should be the same as signatures for the same APIs from the
corresponding upstream javac (also contains com.sun.javadoc API, but use of
that should be discouraged as there's a much better com.sun.source.doctree
API now)
--the impl jar, which contains the rest of the compiler implementation
-many modules that provide Java language related features directly depend
on/use the APIs from the API jar
-a handful of modules that are base to the support for the Java language
directly depend on classes from the impl jar (in addition to the APIs).
Jan
> Gj
>
>
>
>
> On Fri, Nov 4, 2016 at 4:51 PM, Bertrand Delacretaz <
> bdelacretaz@apache.org>
> wrote:
>
> > On Fri, Nov 4, 2016 at 4:41 PM, Geertjan Wielenga
> > <ge...@googlemail.com> wrote:
> > > On Fri, Nov 4, 2016 at 4:27 PM, Bertrand Delacretaz wrote:
> > >>... http://apache.org/legal/resolved.html applies, ...
> > >
> > > In the above reference, I see this: "For example, using a GPL'ed tool
> > > during the build is OK."
> > >
> > > That's the case of nb-javac in the context of the optional module
> > provided
> > > by the "java" cluster.
> >
> > I'm clueless about the NetBeans code structure and what clusters are,
> > but do you mean that nb-javac is a (customized?) Java compiler that's
> > required to build some parts of NetBeans?
> >
> > > ...The nb-javac libraries can be installed separately from NetBeans
> > itself,
> > > via the installer or a related update mechanism...
> >
> > Ok so if they don't affect the licensing of the Apache NetBeans code
> > that's fine.
> >
> > -Bertrand
> >
>
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Geertjan Wielenga <ge...@googlemail.com>.
On Fri, Nov 4, 2016 at 4:51 PM, Bertrand Delacretaz wrote:
I'm clueless about the NetBeans code structure and what clusters are,
That's precisely why I am putting together this:
https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+NetBeans+Structure
but do you mean that nb-javac is a (customized?) Java compiler that's
> required to build some parts of NetBeans?
Yes.
Aside from nb-javac (two JARs in total) being needed to build the "java"
cluster, and related non-core clusters, it is needed by end users as well,
which is possible as stated by Ate they "will be required to provide the
nb-javac module themselves during installation".
Gj
On Fri, Nov 4, 2016 at 4:51 PM, Bertrand Delacretaz <bd...@apache.org>
wrote:
> On Fri, Nov 4, 2016 at 4:41 PM, Geertjan Wielenga
> <ge...@googlemail.com> wrote:
> > On Fri, Nov 4, 2016 at 4:27 PM, Bertrand Delacretaz wrote:
> >>... http://apache.org/legal/resolved.html applies, ...
> >
> > In the above reference, I see this: "For example, using a GPL'ed tool
> > during the build is OK."
> >
> > That's the case of nb-javac in the context of the optional module
> provided
> > by the "java" cluster.
>
> I'm clueless about the NetBeans code structure and what clusters are,
> but do you mean that nb-javac is a (customized?) Java compiler that's
> required to build some parts of NetBeans?
>
> > ...The nb-javac libraries can be installed separately from NetBeans
> itself,
> > via the installer or a related update mechanism...
>
> Ok so if they don't affect the licensing of the Apache NetBeans code
> that's fine.
>
> -Bertrand
>
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Nov 4, 2016 at 4:41 PM, Geertjan Wielenga
<ge...@googlemail.com> wrote:
> On Fri, Nov 4, 2016 at 4:27 PM, Bertrand Delacretaz wrote:
>>... http://apache.org/legal/resolved.html applies, ...
>
> In the above reference, I see this: "For example, using a GPL'ed tool
> during the build is OK."
>
> That's the case of nb-javac in the context of the optional module provided
> by the "java" cluster.
I'm clueless about the NetBeans code structure and what clusters are,
but do you mean that nb-javac is a (customized?) Java compiler that's
required to build some parts of NetBeans?
> ...The nb-javac libraries can be installed separately from NetBeans itself,
> via the installer or a related update mechanism...
Ok so if they don't affect the licensing of the Apache NetBeans code
that's fine.
-Bertrand
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Geertjan Wielenga <ge...@googlemail.com>.
On Sat, Nov 5, 2016 at 6:52 AM, Niclas Hedhman wrote:
> I don't like to come off as a preacher, so please don't take this the wrong
> way. I am trying to avoid future headaches...
I don't really understand your point. Ate has explained the legal question
that needs to be resolved and Bertrand has started this thread to put focus
on it. I think we all agree that, yes, a legal issue needs to be resolved.
Yes, I think everybody wants to see a resolution to this and clarity on the
position of the "java" cluster in relation to nb-javac.
And part of that is to clarify exactly what we're talking about and hence I
am putting together this:
https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+NetBeans+Structure
So... what is the point you are trying to re-re-re-reiterate at this stage?
We're all in agreement that this needs to be resolved, aren't we?
Gj
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Wade Chandler <wa...@apache.org>.
On Nov 5, 2016 1:53 AM, "Niclas Hedhman" <ni...@hedhman.org> wrote:
>
>
> Yes, I think we all understand the "end user interaction model" that you
> have in mind to overcome the licensing issues.
>
> However, I am talking about licensing principles and how the ASF has
> operated over the last 15-20 years. We take licensing extremely seriously,
> to ensure that there are as little risk as possible for ALL downstream
> users, regardless if they are individuals or large companies, regardless
of
> their intended use, building what you offer or repackaging completely.
This
> is Open SOURCE, not OLB (openly licensed binaries) software.
>
> And as already outlined and identified by you and others, the most
sticking
> point is nb-javac being GPL'd (leaving of the LGPL parts for now).
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.
>
Resolved seems pretty clear on this to me, especially in the context of
existing projects...see below... But I do not believe you can leave LGPL or
GPL+CPE for now. It is definitely part of the answer. I mentioned some
clauses from resolved in another reply which are directly related as well.
> If it is exempt, then your strategy will be "somewhat annoying" but not a
> show-stopper for the "java" cluster to remain at Apache.
>
Here is a big question though. How is this different than httpd (example
... mod_perl), any Java project depending on java.*, the systems needing
glibc, or any other gnu tools suite compiler and headers, to build, which
are already at Apache?
> If it is not exempt from the GPL virality, then either the "java" cluster
> need to be developed outside Apache Netbeans (with naming issues, I guess)
> OR a technical solution be provided, where the nb-javac is made to depend
> on Apache Netbeans and not the other way around.
>
> 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 to me isn't inherently different. GNU+CPE IS why Java continues to
work for all the Java projects. Am I missing something? I am just looking
for the apples to oranges difference here. It seems the same.
Thanks
Wade
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Sven Reimers <sv...@gmail.com>.
Hi all,
for me it seems there are two parts of this discussion:
1. The legal part about GPL+CPE
2. The technical problem of maintaining a javac fork
I think 2 is already a problem (a BIG thanks to Jan Lahoda who still keeps
this working and even provides branches working with Valhalla...) that not
crashed up to now and would be good to be solved without especially looking
at the current transition.
I will not comment on 1 - I think all is said..
Just my 2c€
-Sven
On Sun, Nov 6, 2016 at 11:26 AM, Neil C Smith <neilcsmith.net@googlemail.com
> wrote:
> Hi,
>
> On 5 November 2016 at 19:20, Wade Chandler <wa...@apache.org>
> wrote:
> > On Nov 5, 2016 2:00 PM, "Neil C Smith" <ne...@googlemail.com>
> > wrote:
> >>Why I think this
> >> is different to reliance on almost any other library is the way javac
> >> uses the internals of the JRE. eg. the last time I looked, javac had
> >> specific exceptions in place to bypass module restrictions in Java 9.
> >> It just feels like shakier ground to rely on than it could be.
> >>
> > The same would
> > be the case with any OpenJDK API ATM.
>
> I think you're missing the point I'm trying to make, or I'm not
> explaining very well - what javac relies on is not part of the OpenJDK
> API, or any public and stable one - hence shakier ground!
>
> >> 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?
> >
> > 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.
>
> So would I!
>
> Yes, the community could (not ideal but could) work on it on GitHub,
> but this is not my concern about maintainability. javac relies on
> access to internals of the JRE. I'm assuming the nb-javac fork still
> does? Jigsaw may have implications here - javac has specific
> exceptions. I know other javac forks have had issues.
>
> What I'm saying about maintainability is that changes in the internals
> of OpenJDK have the potential to stop nb-javac from functioning. So,
> while we, the NetBeans community, may be able to manage the code on
> our side, it may also require commitment from Oracle / OpenJDK to not
> break access to internal features that the nb-javac library relies on.
>
> As I said earlier, this is tangentially related to the license
> argument IMO, because a fudge now to meet the immediate needs of that
> without the agreement of how this plays out into the future to meet
> technical and maintenance concerns feels wrong.
>
> > Either way, that doesn't make NB less viable. You use
> > it now...
>
> Yes, but that is not a guarantee this keeps working?!
>
> Best wishes,
>
> Neil
>
> --
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
>
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>
--
Sven Reimers
* Senior Expert Software Architect
* Java Champion
* NetBeans Dream Team Member: http://dreamteam.netbeans.org
* Community Leader NetBeans: http://community.java.net/netbeans
Desktop Java:
http://community.java.net/javadesktop
* JUG Leader JUG Bodensee: http://www.jug-bodensee.de
* Duke's Choice Award Winner 2009
* XING: https://www.xing.com/profile/Sven_Reimers8
* LinkedIn: http://www.linkedin.com/in/svenreimers
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Wade Chandler <wa...@apache.org>.
On Nov 6, 2016 5:26 AM, "Neil C Smith" <ne...@googlemail.com>
wrote:
>
> Hi,
>
> On 5 November 2016 at 19:20, Wade Chandler <wa...@apache.org>
wrote:
> > On Nov 5, 2016 2:00 PM, "Neil C Smith" <ne...@googlemail.com>
> > wrote:
> >>
> > The same would
> > be the case with any OpenJDK API ATM.
>
> I think you're missing the point I'm trying to make, or I'm not
> explaining very well - what javac relies on is not part of the OpenJDK
> API, or any public and stable one - hence shakier ground!
>
The rest is irrelevant. nb-javac is a fork of GPL+CPE sources. It is GPL+
CPE. NB interacts with its classes, and nothing else. If you see different,
be specific and spell it out, this is a fact.
Wade
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 08/11/16 à 18:47, Jim Jagielski a écrit :
> Look at it this way: If it was required in order to develop *all*
> languages, then it would be a problem.
>
> However, it is only required for those who desire to use NetBeans
> to develop Java. At that point, they have already accepted a requirement
> for non-ALv2 dependencies, and so we are not really adding anything
> additional (consider the scenario where they would be developing
> a completely proprietary language... ).
Jim, I think you nailed it :-)
Re: Optional modules with GPL dependencies (was: What to include/exclude in code donation to Apache)
Posted by Jim Jagielski <ji...@jaguNET.com>.
Look at it this way: If it was required in order to develop *all*
languages, then it would be a problem.
However, it is only required for those who desire to use NetBeans
to develop Java. At that point, they have already accepted a requirement
for non-ALv2 dependencies, and so we are not really adding anything
additional (consider the scenario where they would be developing
a completely proprietary language... ).
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Geertjan Wielenga <ge...@googlemail.com>.
On Sun, Nov 6, 2016 at 4:59 PM, Ate Douma wrote:
> Geertjan and others already clarified and are documenting the modularity of
> NetBeans [2], with the core NetBeans platform being the only required part.
> All other modules (or clusters) being optional.
> So many users might not need the NetBeans Java cluster.
>
> However is this actually true for a majority of NetBeans users?
> Although I'm not a NetBeans user myself, I honestly think a majority
> actually
> do want and need to use the Java cluster in NetBeans, for development or
> education purposes (the latter also often pointed out as a major usage).
>
> So while formally the Java cluster is optionally I don't think anyone
> can claim only a minority will want/need to use it.
Java is an important optional module, though not core to NetBeans. Neither
technically nor functionally.
If Java is core, then what about JavaScript? What about PHP? What about
C/C++?
The "platform" cluster is certainly "core" to NetBeans.
I could go along with you further and say that the "ide" cluster is "core"
to NetBeans, providing generic editing capabilities, including integration
with Git, Subversion, Hudson, etc.
But the "java" cluster is on the same level as the "cnd" cluster (i.e.
C/C++) and the "php" cluster. These are language packs on top of "platform"
together with "ide".
I could gather some evidence for this assertion if needed: the majority of
users of NetBeans are not using the "java" cluster at all, instead they're
using the "platform" cluster together with a variety of applications on top
of it, in some cases NetBeans IDE, in other cases Microchip MPLAB X, in
other cases totally other applications such as these:
https://en.wikipedia.org/wiki/CD-adapco
We need to be clear on this point before discussing the legal aspect of
nb-javac in relation to the "java" cluster -- really, "java" is just an
optional module, an important optional module for a lot of but by no means
all NetBeans users.
Thanks for the thorough intervention and please bear the above points in
mind.
Gj
On Sun, Nov 6, 2016 at 4:59 PM, Ate Douma <at...@douma.nu> wrote:
> I'm top posting on just the last response in this thread, as I think
> the discussion is drifting too much and not adding much value nor new
> insights.
> And it seems to be building up unnecessary irritations as result.
>
> Instead I will try to recap and summarize the current state to break out of
> the re-re-re-re-... iterations loop :-)
>
> The main question to be answered is, as I already proposed before:
>
> Will the Apache NetBeans project be allowed to develop and release
> a (or more) optional module, the Java Editor module in casu, under the
> ASL 2.0 license at the ASF, which depends on external 3rd party module
> nb-javac which is available under the GPL v2 w/ CPE (Category X).
> End users willing to use the optional module will be required to provide
> the nb-javac module themselves during installation.
>
> Relevant in this context is what the Apache Legal Policy *guidelines* [1]
> says
> about the meaning of the word "Optional":
>
> Optional means that the component is not required for standard use of the
> product or for the product to achieve a desirable level of quality.
> The question to ask yourself in this situation is:
>
> "Will the majority of users want to use my product without adding the
> optional components?"
>
> Geertjan and others already clarified and are documenting the modularity of
> NetBeans [2], with the core NetBeans platform being the only required part.
> All other modules (or clusters) being optional.
> So many users might not need the NetBeans Java cluster.
>
> However is this actually true for a majority of NetBeans users?
> Although I'm not a NetBeans user myself, I honestly think a majority
> actually
> do want and need to use the Java cluster in NetBeans, for development or
> education purposes (the latter also often pointed out as a major usage).
>
> So while formally the Java cluster is optionally I don't think anyone
> can claim only a minority will want/need to use it.
> IMO this means that the common guideline as described at [1] is *not*
> sufficient to answer the above question with yes...
>
> Hence, we need to get an explicit answer from Apache Legal Affairs
> Committee.
>
> And if *they* decide the answer is no, a different solution will be needed.
>
> One of the alternatives then might be asking Oracle for a compatible
> dual-license of nb-javac.
> Or else we need to decide how and where to proceed with the NetBeans Java
> cluster development, *outside* the ASF...
>
> Or maybe the nb-javac fork might be brought back into OpenJDK.
> I have no clue how feasible or realistic that would be.
> But that, and only that, would change the current dependency on nb-javac
> into
> a 'platform' dependency, which we can allow by the ASF Legal Policy.
>
> In the current state, discussing about nb-javac as possible platform or OS
> dependency, or even comparing it with the OpenJDK, is useless.
>
> A platform dependency like Java or even OpenJDK is in general OK because
> users
> will already have an upfront requirement on such dependencies anyway.
> But the nb-javac jar AFAICT is *only* useful/needed *when* users want to
> use NetBeans. And serves no other purpose than to enable the usage of
> NetBeans.
>
> I will raise the question as described above by creating a LEGAL issue [3]
> for
> it later today. And I'll forward the link to that issue here.
> This might also lead to follow up discussion in the legal-discuss@ list
> [4], so
> anyone interested might want to monitor that list or even subscribe it.
>
> And to keep the current thread relevant and meaningful, I kindly request
> others
> to start a new thread for additional discussions not specifically
> addressing the
> above.
>
> Kind regards,
> Ate
>
> [1] http://www.apache.org/legal/resolved.html#optional
> [2] https://cwiki.apache.org/confluence/display/NETBEANS/Overvie
> w%3A+NetBeans+Structure
> [3] https://issues.apache.org/jira/browse/LEGAL
> [4] http://www.apache.org/foundation/mailinglists.html#foundation-legal
>
>
>
> On 2016-11-06 16:49, Neil C Smith wrote:
>
>> On 6 November 2016 at 14:32, Wade Chandler <wa...@apache.org>
>> wrote:
>>
>>> I totally see your point here, but yes, separate from the license
>>> discussion. I still think NB has this problem now, so nothing changes
>>> there, so what would you do different, right now, even if NB were not
>>> going
>>> to Apache? This is why I say we have to iterate. It can't all be done at
>>> once.
>>>
>>
>> Agreed, this would still be an issue, although less of one while both
>> projects have connections within the same company. And I'm really not
>> suggesting that this all be done at once.
>>
>> But, I really think this relates to the question of licensing, or how
>> to handle something that can't be donated to Apache because of code
>> licensing. In particular, Niclas' comments that "This
>> is Open SOURCE, not OLB (openly licensed binaries) software.", and
>> that ASF would like to see dependency on a regular OpenJDK system.
>> nb-javac has similarities to a binary blob, in that its functionality
>> can never be entirely maintained on the NetBeans community side -
>> there is a similar lack of control.
>>
>> So, what I would want to see if I was on the Apache side, and I think
>> would be good for the NetBeans community, is some commitments from
>> Oracle, OpenJDK and ASF / NB on a direction of travel to remove this
>> dependency as part of the code donation. That would include a
>> commitment from Oracle / OpenJDK to not break any required internal
>> interfaces, provide fixes / updates, even maintain it, as and until
>> it's possible to remove nb-javac. I presume removing it is going to
>> require the OpenJDK and NetBeans projects to agree what can be added
>> to core javac and what has to be reworked on the NetBeans side.
>>
>> That all of course relies on the initial dependency / licensing being
>> accepted for a least an interim period!
>>
>> That's pretty much the sum of what's in my head - IMO solving the
>> licensing question and the clarification of how to handle the
>> resulting technical / development needs cannot be handled usefully in
>> isolation - particularly with regards to the realities of this
>> particular code. The agreed solution has to suit both. I'll shut up
>> on that now! :-)
>>
>> Best wishes,
>>
>> Neil
>>
>>
>
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Ate Douma <at...@douma.nu>.
I'm top posting on just the last response in this thread, as I think
the discussion is drifting too much and not adding much value nor new insights.
And it seems to be building up unnecessary irritations as result.
Instead I will try to recap and summarize the current state to break out of
the re-re-re-re-... iterations loop :-)
The main question to be answered is, as I already proposed before:
Will the Apache NetBeans project be allowed to develop and release
a (or more) optional module, the Java Editor module in casu, under the
ASL 2.0 license at the ASF, which depends on external 3rd party module
nb-javac which is available under the GPL v2 w/ CPE (Category X).
End users willing to use the optional module will be required to provide
the nb-javac module themselves during installation.
Relevant in this context is what the Apache Legal Policy *guidelines* [1] says
about the meaning of the word "Optional":
Optional means that the component is not required for standard use of the
product or for the product to achieve a desirable level of quality.
The question to ask yourself in this situation is:
"Will the majority of users want to use my product without adding the
optional components?"
Geertjan and others already clarified and are documenting the modularity of
NetBeans [2], with the core NetBeans platform being the only required part.
All other modules (or clusters) being optional.
So many users might not need the NetBeans Java cluster.
However is this actually true for a majority of NetBeans users?
Although I'm not a NetBeans user myself, I honestly think a majority actually
do want and need to use the Java cluster in NetBeans, for development or
education purposes (the latter also often pointed out as a major usage).
So while formally the Java cluster is optionally I don't think anyone
can claim only a minority will want/need to use it.
IMO this means that the common guideline as described at [1] is *not*
sufficient to answer the above question with yes...
Hence, we need to get an explicit answer from Apache Legal Affairs Committee.
And if *they* decide the answer is no, a different solution will be needed.
One of the alternatives then might be asking Oracle for a compatible
dual-license of nb-javac.
Or else we need to decide how and where to proceed with the NetBeans Java
cluster development, *outside* the ASF...
Or maybe the nb-javac fork might be brought back into OpenJDK.
I have no clue how feasible or realistic that would be.
But that, and only that, would change the current dependency on nb-javac into
a 'platform' dependency, which we can allow by the ASF Legal Policy.
In the current state, discussing about nb-javac as possible platform or OS
dependency, or even comparing it with the OpenJDK, is useless.
A platform dependency like Java or even OpenJDK is in general OK because users
will already have an upfront requirement on such dependencies anyway.
But the nb-javac jar AFAICT is *only* useful/needed *when* users want to
use NetBeans. And serves no other purpose than to enable the usage of
NetBeans.
I will raise the question as described above by creating a LEGAL issue [3] for
it later today. And I'll forward the link to that issue here.
This might also lead to follow up discussion in the legal-discuss@ list [4], so
anyone interested might want to monitor that list or even subscribe it.
And to keep the current thread relevant and meaningful, I kindly request others
to start a new thread for additional discussions not specifically addressing the
above.
Kind regards,
Ate
[1] http://www.apache.org/legal/resolved.html#optional
[2]
https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+NetBeans+Structure
[3] https://issues.apache.org/jira/browse/LEGAL
[4] http://www.apache.org/foundation/mailinglists.html#foundation-legal
On 2016-11-06 16:49, Neil C Smith wrote:
> On 6 November 2016 at 14:32, Wade Chandler <wa...@apache.org> wrote:
>> I totally see your point here, but yes, separate from the license
>> discussion. I still think NB has this problem now, so nothing changes
>> there, so what would you do different, right now, even if NB were not going
>> to Apache? This is why I say we have to iterate. It can't all be done at
>> once.
>
> Agreed, this would still be an issue, although less of one while both
> projects have connections within the same company. And I'm really not
> suggesting that this all be done at once.
>
> But, I really think this relates to the question of licensing, or how
> to handle something that can't be donated to Apache because of code
> licensing. In particular, Niclas' comments that "This
> is Open SOURCE, not OLB (openly licensed binaries) software.", and
> that ASF would like to see dependency on a regular OpenJDK system.
> nb-javac has similarities to a binary blob, in that its functionality
> can never be entirely maintained on the NetBeans community side -
> there is a similar lack of control.
>
> So, what I would want to see if I was on the Apache side, and I think
> would be good for the NetBeans community, is some commitments from
> Oracle, OpenJDK and ASF / NB on a direction of travel to remove this
> dependency as part of the code donation. That would include a
> commitment from Oracle / OpenJDK to not break any required internal
> interfaces, provide fixes / updates, even maintain it, as and until
> it's possible to remove nb-javac. I presume removing it is going to
> require the OpenJDK and NetBeans projects to agree what can be added
> to core javac and what has to be reworked on the NetBeans side.
>
> That all of course relies on the initial dependency / licensing being
> accepted for a least an interim period!
>
> That's pretty much the sum of what's in my head - IMO solving the
> licensing question and the clarification of how to handle the
> resulting technical / development needs cannot be handled usefully in
> isolation - particularly with regards to the realities of this
> particular code. The agreed solution has to suit both. I'll shut up
> on that now! :-)
>
> Best wishes,
>
> Neil
>
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Neil C Smith <ne...@googlemail.com>.
On 6 November 2016 at 14:32, Wade Chandler <wa...@apache.org> wrote:
> I totally see your point here, but yes, separate from the license
> discussion. I still think NB has this problem now, so nothing changes
> there, so what would you do different, right now, even if NB were not going
> to Apache? This is why I say we have to iterate. It can't all be done at
> once.
Agreed, this would still be an issue, although less of one while both
projects have connections within the same company. And I'm really not
suggesting that this all be done at once.
But, I really think this relates to the question of licensing, or how
to handle something that can't be donated to Apache because of code
licensing. In particular, Niclas' comments that "This
is Open SOURCE, not OLB (openly licensed binaries) software.", and
that ASF would like to see dependency on a regular OpenJDK system.
nb-javac has similarities to a binary blob, in that its functionality
can never be entirely maintained on the NetBeans community side -
there is a similar lack of control.
So, what I would want to see if I was on the Apache side, and I think
would be good for the NetBeans community, is some commitments from
Oracle, OpenJDK and ASF / NB on a direction of travel to remove this
dependency as part of the code donation. That would include a
commitment from Oracle / OpenJDK to not break any required internal
interfaces, provide fixes / updates, even maintain it, as and until
it's possible to remove nb-javac. I presume removing it is going to
require the OpenJDK and NetBeans projects to agree what can be added
to core javac and what has to be reworked on the NetBeans side.
That all of course relies on the initial dependency / licensing being
accepted for a least an interim period!
That's pretty much the sum of what's in my head - IMO solving the
licensing question and the clarification of how to handle the
resulting technical / development needs cannot be handled usefully in
isolation - particularly with regards to the realities of this
particular code. The agreed solution has to suit both. I'll shut up
on that now! :-)
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Wade Chandler <wa...@apache.org>.
On Nov 6, 2016 5:26 AM, "Neil C Smith" <ne...@googlemail.com>
wrote.
>
> What I'm saying about maintainability is that changes in the internals
> of OpenJDK have the potential to stop nb-javac from functioning. So,
> while we, the NetBeans community, may be able to manage the code on
> our side, it may also require commitment from Oracle / OpenJDK to not
> break access to internal features that the nb-javac library relies on.
>
> As I said earlier, this is tangentially related to the license
> argument IMO, because a fudge now to meet the immediate needs of that
> without the agreement of how this plays out into the future to meet
> technical and maintenance concerns feels wrong.
>
> > Either way, that doesn't make NB less viable. You use
> > it now...
>
> Yes, but that is not a guarantee this keeps working?!
>
I totally see your point here, but yes, separate from the license
discussion. I still think NB has this problem now, so nothing changes
there, so what would you do different, right now, even if NB were not going
to Apache? This is why I say we have to iterate. It can't all be done at
once.
Wade
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Neil C Smith <ne...@googlemail.com>.
Hi,
On 5 November 2016 at 19:20, Wade Chandler <wa...@apache.org> wrote:
> On Nov 5, 2016 2:00 PM, "Neil C Smith" <ne...@googlemail.com>
> wrote:
>>Why I think this
>> is different to reliance on almost any other library is the way javac
>> uses the internals of the JRE. eg. the last time I looked, javac had
>> specific exceptions in place to bypass module restrictions in Java 9.
>> It just feels like shakier ground to rely on than it could be.
>>
> The same would
> be the case with any OpenJDK API ATM.
I think you're missing the point I'm trying to make, or I'm not
explaining very well - what javac relies on is not part of the OpenJDK
API, or any public and stable one - hence shakier ground!
>> 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?
>
> 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.
So would I!
Yes, the community could (not ideal but could) work on it on GitHub,
but this is not my concern about maintainability. javac relies on
access to internals of the JRE. I'm assuming the nb-javac fork still
does? Jigsaw may have implications here - javac has specific
exceptions. I know other javac forks have had issues.
What I'm saying about maintainability is that changes in the internals
of OpenJDK have the potential to stop nb-javac from functioning. So,
while we, the NetBeans community, may be able to manage the code on
our side, it may also require commitment from Oracle / OpenJDK to not
break access to internal features that the nb-javac library relies on.
As I said earlier, this is tangentially related to the license
argument IMO, because a fudge now to meet the immediate needs of that
without the agreement of how this plays out into the future to meet
technical and maintenance concerns feels wrong.
> Either way, that doesn't make NB less viable. You use
> it now...
Yes, but that is not a guarantee this keeps working?!
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Wade Chandler <wa...@apache.org>.
On Nov 6, 2016 3:59 AM, "Niclas Hedhman" <ni...@hedhman.org> wrote:
>
> 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.
One, the OS isn't even in this conversation. Two, it is clear the JDK and
JRE, even javac, in this context, are discussed as APIs, as we are
discussing access and a specific license, as well the use of APIs. Three,
we are talking about dependencies and their license.
This is why I asked you to be specific. The interaction you are talking
about with lawyers, requires specifics too, so be clear. It isn't a
re-iteration if you have yet to be specific; talking about the OS is
completely off topic at this point.
If a legal precedent is understood, then it is understood, and I don't call
my lawyer if it is clear. This is pretty clear to me unless there is an
Apache specific concern you have not specified as it relates to the
GPL+CPE. The NB community and platform apps devs have delt with this
license for many years.
>
> I am done.
>
Per your own choice of words and phrases, fine. It isn't exactly
constructive when you are not specific. You were the one who said it may be
possible the Java cluster may need to be GPL+CPE.
That makes no sense without something specific as it is accessed by classes
and API from the Java cluster, and it has already been made clear nb-javac
will not be distributed. This is exactly/specifically how this conversation
relates to OpenJDK and Java projects, as well as mod_perl and Perl; neither
an OS. This is also specifically pointed out in "resolved".
I asserted what I understand, and asked where the difference and concern
specifically was. I completely assume mentors will run things like this by
legal, but regardless, if you are arguing a point, be specific if it
requires legal.
Wade
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Niclas Hedhman <ni...@hedhman.org>.
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.
Niclas
On Sun, Nov 6, 2016 at 1:15 PM, Wade Chandler <wa...@apache.org>
wrote:
> 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" <ni...@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 <wa...@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
> >
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Wade Chandler <wa...@apache.org>.
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" <ni...@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 <wa...@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
>
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Wade Chandler <wa...@apache.org>.
On Nov 6, 2016 5:31 AM, "Neil C Smith" <ne...@googlemail.com>
wrote:
>
> On 6 November 2016 at 02:16, Niclas Hedhman <ni...@hedhman.org> wrote:
> >> > 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.
>
> Something I understand, but not something that actually relates to
> *my* licensing question, which was back to Oracle / Geertjan. That
> was the ultra-long-shot question of whether multiple licensing of
> javac and other tools had been considered? Tools having a more
> liberal license to their runtimes is not without precedent! I'm also
> not holding my breath. :-)
>
The specific point addressed here to which you are replying doesn't appear
to be a legal question, outside of distribution, but a business practice
when it concerns dependencies, just purely as a dependency. Are these type
business requirements, which are not a question of legality, but of use and
"The Apache Way", also to be run through legal? These seem more related to
a vote of a PMC to move forward on a business decision. We are talking
about protocol and an Apache specific way of doing business it seems. If
such questions also go to legal, at Apache, then good and important
specifics to know.
Wade
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Neil C Smith <ne...@googlemail.com>.
On 6 November 2016 at 02:16, Niclas Hedhman <ni...@hedhman.org> wrote:
>> > 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.
Something I understand, but not something that actually relates to
*my* licensing question, which was back to Oracle / Geertjan. That
was the ultra-long-shot question of whether multiple licensing of
javac and other tools had been considered? Tools having a more
liberal license to their runtimes is not without precedent! I'm also
not holding my breath. :-)
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Niclas Hedhman <ni...@hedhman.org>.
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 <wa...@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
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Wade Chandler <wa...@apache.org>.
On Nov 5, 2016 2:00 PM, "Neil C Smith" <ne...@googlemail.com>
wrote:
>
> Hi,
>
> Is top-posting or inline replying the norm here? Anyway, replies below
:-)
>
It depends on devices and whether one is replying to pieces or a whole I
guess; for inline. I do think in the age of diverse connected smarter
devices, old arguments about top, bottom, and inline posting limits
communities, and as long as something is understandable, then we shouldn't
fret much...not saying you are, just my frame of reference take on this.
Snipping for replies seems more clear to me, but if one is limited, then
chime in and contribute as one can IMO.
>
> > On 5 November 2016 at 16:45, Wade Chandler <wa...@apache.org>
wrote:
> > Perhaps specific threads can be created to discuss the Java and
JavaScript support in NetBeans (independently/maybe together). I think a
big part of the question is what does Oracle think about supporting
nb-javac and graal.js if they are only used by NetBeans. I mean, is there
some long term support strategy there?
>. I should
> have said, having the regular OpenJDK tooling supporting what NetBeans
> requires surely benefits all projects building similar tools.
>
Sure, and I can certainly see that POV, but it has to be there first. So,
there is the now, future, and whatever the possibilities. There are ways to
do this now, and ways to make it better. That to me can be iterative, but
has to move forward from where we are. My guess is we can all agree on that.
> My concern is that without the Java cluster I don't believe NetBeans
> is really a viable project, and for that cluster to be viable requires
> the long term support of nb-javac that you mention.
I agree with this. I think the community can figure this out regardless
though. Whether it the NB community, Oracle, or OpenJDK who keeps up
nb-javac or Java support.next, and if we iterate, neither use case puts the
Java cluster outside NB, nor makes NB unviable.
>Why I think this
> is different to reliance on almost any other library is the way javac
> uses the internals of the JRE. eg. the last time I looked, javac had
> specific exceptions in place to bypass module restrictions in Java 9.
> It just feels like shakier ground to rely on than it could be.
>
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.
> 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?
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.
>Could nb-javac features be merged
> with javac, or become ide-javac within OpenJDK, providing similar
> services to any IDE?
>
This is a future question to me. Could it be asked and reviewed? I imagine
that answer is yes. How long? Can it actually happen? All would take
working with the OSS project which is OpenJDK to find out. Oracle perhaps
can help with that. Either way, that doesn't make NB less viable. You use
it now...
Thanks
Wade
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Emilian Bold <em...@apache.org>.
> Could nb-javac features be merged with javac, or become ide-javac within
OpenJDK, providing similar services to any IDE?
This would be pretty nice. Just like javac and Nashorn has an official Tree
API we could have an Editor API for both.
--emi
On Sat, Nov 5, 2016 at 8:00 PM, Neil C Smith <ne...@googlemail.com>
wrote:
> Hi,
>
> Is top-posting or inline replying the norm here? Anyway, replies below :-)
>
> >> On Nov 5, 2016, at 12:22, Wade Chandler <wa...@apache.org>
> wrote:
> >> 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.
>
> Not really ...
>
> > On 5 November 2016 at 16:45, Wade Chandler <wa...@apache.org>
> wrote:
> > Perhaps specific threads can be created to discuss the Java and
> JavaScript support in NetBeans (independently/maybe together). I think a
> big part of the question is what does Oracle think about supporting
> nb-javac and graal.js if they are only used by NetBeans. I mean, is there
> some long term support strategy there?
>
> This is more my concern, and reason for the questions I raised. I
> realise my use of the words "this project" may have been open to
> misinterpretation - I meant NetBeans, not my own platform application
> (although that is obviously of tangential concern for me!). I should
> have said, having the regular OpenJDK tooling supporting what NetBeans
> requires surely benefits all projects building similar tools.
>
> My concern is that without the Java cluster I don't believe NetBeans
> is really a viable project, and for that cluster to be viable requires
> the long term support of nb-javac that you mention. Why I think this
> is different to reliance on almost any other library is the way javac
> uses the internals of the JRE. eg. the last time I looked, javac had
> specific exceptions in place to bypass module restrictions in Java 9.
> It just feels like shakier ground to rely on than it could be.
>
> 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? Could nb-javac features be merged
> with javac, or become ide-javac within OpenJDK, providing similar
> services to any IDE?
>
> My 2c!
>
> Best wishes,
>
> Neil
>
> --
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
>
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Neil C Smith <ne...@googlemail.com>.
Hi,
Is top-posting or inline replying the norm here? Anyway, replies below :-)
>> On Nov 5, 2016, at 12:22, Wade Chandler <wa...@apache.org> wrote:
>> 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.
Not really ...
> On 5 November 2016 at 16:45, Wade Chandler <wa...@apache.org> wrote:
> Perhaps specific threads can be created to discuss the Java and JavaScript support in NetBeans (independently/maybe together). I think a big part of the question is what does Oracle think about supporting nb-javac and graal.js if they are only used by NetBeans. I mean, is there some long term support strategy there?
This is more my concern, and reason for the questions I raised. I
realise my use of the words "this project" may have been open to
misinterpretation - I meant NetBeans, not my own platform application
(although that is obviously of tangential concern for me!). I should
have said, having the regular OpenJDK tooling supporting what NetBeans
requires surely benefits all projects building similar tools.
My concern is that without the Java cluster I don't believe NetBeans
is really a viable project, and for that cluster to be viable requires
the long term support of nb-javac that you mention. Why I think this
is different to reliance on almost any other library is the way javac
uses the internals of the JRE. eg. the last time I looked, javac had
specific exceptions in place to bypass module restrictions in Java 9.
It just feels like shakier ground to rely on than it could be.
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? Could nb-javac features be merged
with javac, or become ide-javac within OpenJDK, providing similar
services to any IDE?
My 2c!
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Re: Optional modules with GPL dependencies (was: What to include/exclude in code donation to Apache)
Posted by Wade Chandler <wa...@apache.org>.
Perhaps specific threads can be created to discuss the Java and JavaScript support in NetBeans (independently/maybe together). I think a big part of the question is what does Oracle think about supporting nb-javac and graal.js if they are only used by NetBeans. I mean, is there some long term support strategy there?
Is there some other answer to this question? Does the NB community have github specific projects kept up by the community which are not donated to Apache which it depends upon which have GNU+CPE licenses? Perhaps that is an interim solution where later it is replaced, or maybe it is a long term thing… Either way, httpd has mod_perl, and other modules, which have unique dependencies, and thus the first Apache project set similar precedent.
I think we can figure out what it means to support nb-javac and graal.js outside of the questions related to “OpenJDK” or “Apache NetBeans” as long as we are clear on how dependencies can be managed, and how we support our current community. Then separately figure out whether there are interim and long term solutions to specific items. I don’t think either of those concepts, even the one of core versus optional, keeps the majority of NetBeans being donated to Apache per the items discussed in this thread.
Wade
> On Nov 5, 2016, at 12:22, Wade Chandler <wa...@apache.org> wrote:
>
> 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.
>
Re: Optional modules with GPL dependencies (was: What to include/exclude in code donation to Apache)
Posted by Wade Chandler <wa...@apache.org>.
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.
Wade
> On Nov 5, 2016, at 09:47, Neil C Smith <ne...@googlemail.com> 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 <ni...@hedhman.org> 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!
>
>>
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Neil C Smith <ne...@googlemail.com>.
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 <ni...@hedhman.org> 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!
> If it is not exempt from the GPL virality,
Any chance without weasel words?! ;-)
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Niclas Hedhman <ni...@hedhman.org>.
Geertjan,
I don't like to come off as a preacher, so please don't take this the wrong
way. I am trying to avoid future headaches...
Yes, I think we all understand the "end user interaction model" that you
have in mind to overcome the licensing issues.
However, I am talking about licensing principles and how the ASF has
operated over the last 15-20 years. We take licensing extremely seriously,
to ensure that there are as little risk as possible for ALL downstream
users, regardless if they are individuals or large companies, regardless of
their intended use, building what you offer or repackaging completely. This
is Open SOURCE, not OLB (openly licensed binaries) software.
And as already outlined and identified by you and others, the most sticking
point is nb-javac being GPL'd (leaving of the LGPL parts for now). 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.
If it is exempt, then your strategy will be "somewhat annoying" but not a
show-stopper for the "java" cluster to remain at Apache.
If it is not exempt from the GPL virality, then either the "java" cluster
need to be developed outside Apache Netbeans (with naming issues, I guess)
OR a technical solution be provided, where the nb-javac is made to depend
on Apache Netbeans and not the other way around.
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.
Cheers
Niclas
On Fri, Nov 4, 2016 at 11:41 PM, Geertjan Wielenga <
geertjan.wielenga@googlemail.com> wrote:
> On Fri, Nov 4, 2016 at 4:27 PM, Bertrand Delacretaz wrote:
>
>
> > IMO the "can Apache projects rely on components under prohibited
> > licenses?" section of http://apache.org/legal/resolved.html applies,
> > and the key question is then whether the external component's license
> > terms affect the NetBeans product's licensing.
>
>
> In the above reference, I see this: "For example, using a GPL'ed tool
> during the build is OK."
>
> That's the case of nb-javac in the context of the optional module provided
> by the "java" cluster.
>
> The core cluster, i.e., "platform" does not need the "java" cluster to
> build.
>
> The nb-javac libraries can be installed separately from NetBeans itself,
> via the installer or a related update mechanism.
>
> Gj
>
> On Fri, Nov 4, 2016 at 4:27 PM, Bertrand Delacretaz <
> bdelacretaz@apache.org>
> wrote:
>
> > Hi,
> >
> > Creating a new thread as this now off-topic w.r.t to including things
> > in the donation or not.
> >
> > On Fri, Nov 4, 2016 at 4:06 PM, Ate Douma <at...@douma.nu> wrote:
> > > ...The question, as I see it, being:
> > >
> > > Will the Apache NetBeans project be allowed to develop and release
> > > a (or more) optional module, the Java Editor module in casu, under
> the
> > > ASL 2.0 license at the ASF, which depends on external 3rd party
> module
> > > nb-javac which is available under the GPL v2 w/ CPE (Category X).
> > > End users willing to use the optional module will be required to
> > provide
> > > the nb-javac module themselves during installation.
> > >
> >
> > I think this is a great way to formulate the issue.
> >
> > IMO the "can Apache projects rely on components under prohibited
> > licenses?" section of http://apache.org/legal/resolved.html applies,
> > and the key question is then whether the external component's license
> > terms affect the NetBeans product's licensing.
> >
> > If for example NetBeans depends on GPL licensed APIs that would be an
> > obstacle IMO.
> >
> > OTOH if the affected modules can be released under our license with no
> > impact from those GPL modules everything's fine, IMO.
> >
> > -Bertrand
> >
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Geertjan Wielenga <ge...@googlemail.com>.
On Fri, Nov 4, 2016 at 4:27 PM, Bertrand Delacretaz wrote:
> IMO the "can Apache projects rely on components under prohibited
> licenses?" section of http://apache.org/legal/resolved.html applies,
> and the key question is then whether the external component's license
> terms affect the NetBeans product's licensing.
In the above reference, I see this: "For example, using a GPL'ed tool
during the build is OK."
That's the case of nb-javac in the context of the optional module provided
by the "java" cluster.
The core cluster, i.e., "platform" does not need the "java" cluster to
build.
The nb-javac libraries can be installed separately from NetBeans itself,
via the installer or a related update mechanism.
Gj
On Fri, Nov 4, 2016 at 4:27 PM, Bertrand Delacretaz <bd...@apache.org>
wrote:
> Hi,
>
> Creating a new thread as this now off-topic w.r.t to including things
> in the donation or not.
>
> On Fri, Nov 4, 2016 at 4:06 PM, Ate Douma <at...@douma.nu> wrote:
> > ...The question, as I see it, being:
> >
> > Will the Apache NetBeans project be allowed to develop and release
> > a (or more) optional module, the Java Editor module in casu, under the
> > ASL 2.0 license at the ASF, which depends on external 3rd party module
> > nb-javac which is available under the GPL v2 w/ CPE (Category X).
> > End users willing to use the optional module will be required to
> provide
> > the nb-javac module themselves during installation.
> >
>
> I think this is a great way to formulate the issue.
>
> IMO the "can Apache projects rely on components under prohibited
> licenses?" section of http://apache.org/legal/resolved.html applies,
> and the key question is then whether the external component's license
> terms affect the NetBeans product's licensing.
>
> If for example NetBeans depends on GPL licensed APIs that would be an
> obstacle IMO.
>
> OTOH if the affected modules can be released under our license with no
> impact from those GPL modules everything's fine, IMO.
>
> -Bertrand
>
Re: Optional modules with GPL dependencies (was: What to
include/exclude in code donation to Apache)
Posted by Wade Chandler <wa...@apache.org>.
On Nov 4, 2016 11:27 AM, "Bertrand Delacretaz" <bd...@apache.org>
wrote:
>
>
> IMO the "can Apache projects rely on components under prohibited
> licenses?" section of http://apache.org/legal/resolved.html applies,
> and the key question is then whether the external component's license
> terms affect the NetBeans product's licensing.
>
> If for example NetBeans depends on GPL licensed APIs that would be an
> obstacle IMO.
>
> OTOH if the affected modules can be released under our license with no
> impact from those GPL modules everything's fine, IMO.
>
That word depends and GPL (per sub licenses) gets messy to me in your
reply. I think resolved is very clear, and we can have builds that use GPL
with CPE/LGPL and we can have products that require the GPL with CPE/LGPL
to run, we just can't package that other component in the repository nor
the distributed product, but we can provide a downloader for the other
component if we explain to the user we will be doing that, and ask if they
would like to click some buttons. I think the same is true for GPL where we
use tools, but a different topic than nb-javac or graals.js.
I think the below spells this out, and to me means there are a couple
possibilities for how to make that happen either at install time or modules
can have abstractions which defer to a classpath when available or some
other implementation when not, and that implementation directs the user
about what to do. But the modules with the dependencies could still be
built and distributed by Apache.
Is there consensus on this?
CAN APACHE PROJECTS RELY ON COMPONENTS UNDER PROHIBITED LICENSES?
Apache projects cannot distribute any such components. As with the previous
question on platforms, the component can be relied on if the component's
licence terms do not affect the Apache product's licensing. For example,
using a GPL'ed tool during the build is OK.
CAN APACHE PROJECTS RELY ON COMPONENTS WHOSE LICENSING AFFECTS THE APACHE
PRODUCT?
Apache projects cannot distribute any such components. However, if the
component is only needed for optional features, a project can provide the
user with instructions on how to obtain and install the non-included work.
Optional means that the component is not required for standard use of the
product or for the product to achieve a desirable level of quality. The
question to ask yourself in this situation is:
"Will the majority of users want to use my product without adding the
optional components?"
Other resolved sections possibly affecting NetBeans but which are
manageable and not yet directly related
CAN APACHE PRODUCTS INCLUDE WORKS LICENSED UNDER THE JSON LICENSE?
No. As of 2016-11-03 this has been moved to the 'Category X' license list.
Prior to this, use of the JSON Java library was allowed. See Debian's page
for a list of alternatives.
CAN OSGI METADATA BE ADDED TO WEAK COPYLEFT BINARIES - THUS MODIFYING THE
BINARY JAR FILE?
Insertion of OSGi metadata into 'Category B' licensed jars is permitted;
even though that metadata becomes licensed under the 3rd party license when
it is put in the jar, assuming that a note that this has occurred is
included in the prominent labeling that the Category B language calls for.
CAN ASF PMCS HOST PROJECTS THAT ARE NOT UNDER THE APACHE LICENSE?
No. See the Apache Software Foundation licenses page for more details, and
the Apache Software Foundation page for additional background.
Thanks
Wade