You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Geertjan Wielenga <ge...@googlemail.com> on 2016/11/03 07:42:47 UTC
What to include/exclude in code donation to Apache
Hi all,
A key discussion going on right now that we should externalize via this,
the dev list, is what exactly is included in the code donation by Oracle of
NetBeans to Apache.
In principle, what we'd like to say is that we're donating 'NetBeans' to
Apache. But what is 'NetBeans'? The more specifically we define it, the
greater the chance that we'll accidentally exclude something; the more
generically we define it, the greater the chance that we'll end up with
misunderstandings about what exactly the donation consists of.
So -- on the level of the code (i.e., separate from documentation,
netbeans.org, etc) -- we could say we are donating 'everything at
hg.netbeans.org'. A problem with this is that this is not correct -- in
particular, Oracle is not donating the 'nb-javac' libraries, i.e., the fork
of the Java compiler, which is licensed GPLv2 with CPE and is part of the
JDK and is explicitly not part of the donation to Apache.
The question is how to formulate that for the code donation, i.e., for the
software grant document.
Since nb-javac has its own repo where it is developed, i.e.,
http://hg.netbeans.org/main/nb-javac, which results in 2 JAR files
(nb-javac-api.jar and nb-javac-impl) used in Java cluster, we could try
this verbiage: "NetBeans source code at hg.netbeans.org, excluding
hg.netbeans.org/main/nb-javac". I think that's very clear.
A related point is that, of course, nb-javac is needed (not by the core of
NetBeans, which is the NetBeans Platform but by the optional modules that
relate to the Java Editor) both for building and using the Java tooling of
NetBeans. For that, we have solutions in mind -- Oracle continues to
develop nb-javac, makes it available outside Apache, via build scripts
these will be included into the build process, and during installation
they'll be accessed from their external location and included in the right
location in the installed NetBeans.
So, that deals with nb-javac. Aside from that, there's also Graal.js, the
ECMAScript 6 parser by Oracle Labs that is not being donated by Oracle,
which needs to be explicitly stated as well. Furthermore, Emilian, as
mentioned in the thread he's started, has created a shell script for
identifying potentially other parts of NetBeans that we need to investigate
together in terms of where they stand in terms of the Oracle code donation.
These items above I will be adding to the Wiki so that it's documented and
I encourage any feedback to the above, as well as encouraging anyone with
proposals of any kind to put together a Wiki around that topic.
Many thanks,
Gj
Re: What to include/exclude in code donation to Apache
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Thu, Nov 3, 2016 at 10:02 AM, Emilian Bold <em...@gmail.com> wrote:
> ...Could any of the mentors / legal confirm my interpretation wrt GPL w/ CPE
> dependencies?...
http://apache.org/legal/resolved.html should have all the info about
that, if you have questions those are best backed by specific
examples.
-Bertrand
Re: What to include/exclude in code donation to Apache
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Fri, Nov 4, 2016 at 11:06 PM, Ate Douma <at...@douma.nu> wrote:
>
> While I agree to a large extend, I'm wondering why this specific use-case
> isn't already concrete enough to have ASF Legal make a concrete decision
> about?
> 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.
>
> If ASF Legal can provide a formal response on the above question, I see
> no reason to postpone this until a first NetBeans release.
> And this would take away a lot (probably not all) uncertainties around this
> potentially blocking hurdle.
>
>
I agree with Ate. I don't know if legal-discuss@ has a canned answer for
this question, but if not, it follows the general guideline of Legal
Affairs Committee that the question is concrete, i.e. "I have X and I need
to Y, can I do this?", unlike the many hypotheticals that were forwarded to
that list when I was on it.
So, I suggest that one of the mentors reach out to legal-discuss@ for an
answer. I would also add the copyright holder of each part involved, in
case that matters.
Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: What to include/exclude in code donation to Apache
Posted by Ate Douma <at...@douma.nu>.
On 2016-11-04 09:12, Bertrand Delacretaz wrote:
> On Fri, Nov 4, 2016 at 2:35 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
>> ...it is *possible* that the Java Editor itself
>> (not the nb-javac) can not be released under Apache License....
>
> I agree that it's hard to give a definite answer on this right now,
> the core issue is which NetBeans modules can be considered core and
> which ones optional - as the former cannot have dependencies with
> incompatible licenses as per http://apache.org/legal/resolved.html
>
> This will be clarified once NetBeans makes its first release, that's
> when we'll need to clearly define what's core and what's optional.
>
> Once the Incubator PMC votes and accepts that first release that's the
> official ASF decision on that classification and we can then move
> forward. In a top-level ASF project that decision would be made by the
> project's PMC, but for a podling the PPMC has no formal power to make
> such decisions.
>
> Until then, I don't think it's useful to discuss this in much more
> detail, before the code is here so that we can look at a potential
> release candidate and discuss the details on a concrete basis.
While I agree to a large extend, I'm wondering why this specific use-case
isn't already concrete enough to have ASF Legal make a concrete decision about?
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.
If ASF Legal can provide a formal response on the above question, I see
no reason to postpone this until a first NetBeans release.
And this would take away a lot (probably not all) uncertainties around this
potentially blocking hurdle.
Ate
>
> This core/optional classification is totally orthogonal with Oracle's
> selection of what to donate. We'll accept whatever Oracle donates, and
> then sort it out to decide what we can release or not.
>
> -Bertrand
>
Re: What to include/exclude in code donation to Apache
Posted by Ate Douma <at...@douma.nu>.
On 2016-11-04 12:42, Bertrand Delacretaz wrote:
> On Fri, Nov 4, 2016 at 12:38 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
>> ...I suggest we pause this thread, and gather with the mentors in Seville
>> (it's in 2 weeks), in order to have a F2F discussion about the ins and
>> outs. That will take way less time, and we will be able to discuss all
>> the aspects of this problem...
>
> Sounds good, I'll be there the whole week.
>
> If the Software Grant can be filed before that we might discuss more
> concrete things, but if not we can also discuss the grant.
Regrettably I won't be there.
Ate
Re: What to include/exclude in code donation to Apache
Posted by Geertjan Wielenga <ge...@googlemail.com>.
On Fri, Nov 4, 2016 at 12:42 PM, Bertrand Delacretaz wrote:
Sounds good, I'll be there the whole week.
A problem for me is that, though I have been trying to figure out how to
make it to Seville, I have three other conferences in that same week. I am
not sure if I can make it, though if I can make it I'll only be there for
part of the 18th.
Gj
On Fri, Nov 4, 2016 at 12:42 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> On Fri, Nov 4, 2016 at 12:38 PM, Emmanuel Lécharny <el...@gmail.com>
> wrote:
> > ...I suggest we pause this thread, and gather with the mentors in Seville
> > (it's in 2 weeks), in order to have a F2F discussion about the ins and
> > outs. That will take way less time, and we will be able to discuss all
> > the aspects of this problem...
>
> Sounds good, I'll be there the whole week.
>
> If the Software Grant can be filed before that we might discuss more
> concrete things, but if not we can also discuss the grant.
>
> -Bertrand
>
Re: What to include/exclude in code donation to Apache
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Nov 4, 2016 at 12:38 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
> ...I suggest we pause this thread, and gather with the mentors in Seville
> (it's in 2 weeks), in order to have a F2F discussion about the ins and
> outs. That will take way less time, and we will be able to discuss all
> the aspects of this problem...
Sounds good, I'll be there the whole week.
If the Software Grant can be filed before that we might discuss more
concrete things, but if not we can also discuss the grant.
-Bertrand
Re: What to include/exclude in code donation to Apache
Posted by Emmanuel Lécharny <el...@gmail.com>.
Guys,
we are starting to imagine worse case scenario out of the vacuum.
I suggest we pause this thread, and gather with the mentors in Seville
(it's in 2 weeks), in order to have a F2F discussion about the ins and
outs. That will take way less time, and we will be able to discuss all
the aspects of this problem.
In the mean time, that leave 2 weeks for the netbeans people to check
what will be donated and what will not.
Thoughts ?
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: What to include/exclude in code donation to Apache
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 04/11/16 à 11:51, Emilian Bold a écrit :
> It would allow Oracle to resume NetBeans development under the original
> dual license in case of a failed incubation.
I don't see the point. If incubation fails, ORA can still resume the
project, eitehr under an AL 2.0 license or under whatever license they
like : it's perfectly allowed to relicense AL 2.0 code, as soon as you
respect the AL 2.0 clauses :
http://www.apache.org/foundation/license-faq.html#Distribute-changes
That means ORA can distribute NetBeans under GPL, assuming the inner
code is AL 2.0 and attribution is being made. Or ORA can decide to
rollback to the original GPL code, and aply the AL 2.0 changes made,
whch will remain AL 2.0., under a GPL license.
Sorry, but it sounds like you are preparing for divorce even before
being married... :-)
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: What to include/exclude in code donation to Apache
Posted by Emilian Bold <em...@gmail.com>.
It would allow Oracle to resume NetBeans development under the original
dual license in case of a failed incubation.
--emi
On Fri, Nov 4, 2016 at 12:32 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> On Fri, Nov 4, 2016 at 11:08 AM, Emilian Bold <em...@apache.org> wrote:
> > ...A simple solution to this would be to have all the contributors sign
> the
> > Apache CLA *and* the Oracle Contributor agreement during incubation....
>
> I don't see what this would fix.
>
> The Software Grant only grants the ASF a license to use the code, but
> AFAIK Oracle does not lose any of their existing rights by doing so.
>
> -Bertrand
>
Re: What to include/exclude in code donation to Apache
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Nov 4, 2016 at 11:08 AM, Emilian Bold <em...@apache.org> wrote:
> ...A simple solution to this would be to have all the contributors sign the
> Apache CLA *and* the Oracle Contributor agreement during incubation....
I don't see what this would fix.
The Software Grant only grants the ASF a license to use the code, but
AFAIK Oracle does not lose any of their existing rights by doing so.
-Bertrand
Re: What to include/exclude in code donation to Apache
Posted by Emilian Bold <em...@apache.org>.
>> [...] Apache NetBeans will not succeed, the code will need to be donated
back to Oracle....
> Anyone can take code from an Apache project and fork it elsewhere, so if
some modules can't be released as part of Apache NetBeans anyone is free to
take them anywhere.
IANAL, but Oracle right now owns the copyright on the NetBeans codebase and
is even allowed to change the license according to the Oracle Contributor
Agreement for 3rd party contributions. This is what allows Oracle to sign
the code grant and the switch to the Apache License [1].
My impression is that the question is not about doing a fork of the Apache
licensed code base, but of continuing with the original GPL w/ CPE + CDDL
dual license, while also having the same OCA rights on 3rd party
contributions.
So it seems to me like this is a flaw of the incubation process which
should be seen as a joint effort.
A potential incubation failure should not kill a product nor have the
original contributor go back in time to the codebase before incubation and
lose all the 3rd party contributions made in between by the (existing)
community.
A simple solution to this would be to have all the contributors sign the
Apache CLA *and* the Oracle Contributor agreement during incubation.
[1] Note how the Apache CCLA does not mention the Apache License by name or
a given version. The CCLA allows the ASF to use any license they see fit,
including future Apache License versions or something else.
--emi
On Fri, Nov 4, 2016 at 11:04 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> Hi,
>
> On Fri, Nov 4, 2016 at 9:47 AM, Geertjan Wielenga
> <ge...@googlemail.com> wrote:
> > ...Once we get to the release and it is voted down, i.e.,
> > we cannot leave the incubator, because of dependencies between the Java
> > Editor and nb-javac, i.e., Apache NetBeans will not succeed, the code
> will
> > need to be donated back to Oracle....
>
> Anyone can take code from an Apache project and fork it elsewhere, so
> if some modules can't be released as part of Apache NetBeans anyone is
> free to take them anywhere.
>
> The limitations to this are Java package names (we'll complain if
> someone else uses org.apache) and the NetBeans name itself which needs
> to be donated to Apache, before the first release IMO. Package names
> can stay as is during incubation so no concerns here.
>
> But this has no impact on the software grant, if that includes some
> modules that we cannot use here we'll just ignore them and people can
> take them elsewhere.
>
> if you want to define now what's core or not I suggest that you create
> a wiki page describing that, and we can have a PPMC vote on it, or
> even an Incubator PMC vote, as a complement to the NetBeans podling
> acceptance vote, if people think that's really useful.
>
> -Bertrand
>
Re: What to include/exclude in code donation to Apache
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Fri, Nov 4, 2016 at 9:47 AM, Geertjan Wielenga
<ge...@googlemail.com> wrote:
> ...Once we get to the release and it is voted down, i.e.,
> we cannot leave the incubator, because of dependencies between the Java
> Editor and nb-javac, i.e., Apache NetBeans will not succeed, the code will
> need to be donated back to Oracle....
Anyone can take code from an Apache project and fork it elsewhere, so
if some modules can't be released as part of Apache NetBeans anyone is
free to take them anywhere.
The limitations to this are Java package names (we'll complain if
someone else uses org.apache) and the NetBeans name itself which needs
to be donated to Apache, before the first release IMO. Package names
can stay as is during incubation so no concerns here.
But this has no impact on the software grant, if that includes some
modules that we cannot use here we'll just ignore them and people can
take them elsewhere.
if you want to define now what's core or not I suggest that you create
a wiki page describing that, and we can have a PPMC vote on it, or
even an Incubator PMC vote, as a complement to the NetBeans podling
acceptance vote, if people think that's really useful.
-Bertrand
Re: What to include/exclude in code donation to Apache
Posted by Geertjan Wielenga <ge...@googlemail.com>.
On Fri, Nov 4, 2016 at 9:12 AM, Bertrand Delacretaz wrote:
> Until then, I don't think it's useful to discuss this in much more
> detail, before the code is here so that we can look at a potential
> release candidate and discuss the details on a concrete basis.
Thanks for this intervention.
A concern I have is that we can only make the code available to Apache
after the CCLA/SGA has been completed. At that point, the NetBeans source
code, except for nb-javac and other exclusions, will belong to Apache.
We'll then go through a process together of working on the code and putting
a release together. Once we get to the release and it is voted down, i.e.,
we cannot leave the incubator, because of dependencies between the Java
Editor and nb-javac, i.e., Apache NetBeans will not succeed, the code will
need to be donated back to Oracle.
That seems like a very large amount of work, all for nothing. Can we not
start off from a few premises up front? I.e., if we need to wait until
right before the release for a definition of what is core and what is not
core -- that seems problematic to me. The core is the NetBeans Platform,
i.e., the basis of NetBeans IDE and all the language features are optional
modules. Sure, some optional modules are very important to some people,
while others are very important to other people.
But, really, I would feel a lot more comfortable if we could establish a
decision up front and as soon as possible about the specific question about
what is core.
Thanks,
Geertjan
On Fri, Nov 4, 2016 at 9:12 AM, Bertrand Delacretaz <bd...@apache.org>
wrote:
> On Fri, Nov 4, 2016 at 2:35 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> > ...it is *possible* that the Java Editor itself
> > (not the nb-javac) can not be released under Apache License....
>
> I agree that it's hard to give a definite answer on this right now,
> the core issue is which NetBeans modules can be considered core and
> which ones optional - as the former cannot have dependencies with
> incompatible licenses as per http://apache.org/legal/resolved.html
>
> This will be clarified once NetBeans makes its first release, that's
> when we'll need to clearly define what's core and what's optional.
>
> Once the Incubator PMC votes and accepts that first release that's the
> official ASF decision on that classification and we can then move
> forward. In a top-level ASF project that decision would be made by the
> project's PMC, but for a podling the PPMC has no formal power to make
> such decisions.
>
> Until then, I don't think it's useful to discuss this in much more
> detail, before the code is here so that we can look at a potential
> release candidate and discuss the details on a concrete basis.
>
> This core/optional classification is totally orthogonal with Oracle's
> selection of what to donate. We'll accept whatever Oracle donates, and
> then sort it out to decide what we can release or not.
>
> -Bertrand
>
Re: What to include/exclude in code donation to Apache
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Nov 4, 2016 at 2:35 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> ...it is *possible* that the Java Editor itself
> (not the nb-javac) can not be released under Apache License....
I agree that it's hard to give a definite answer on this right now,
the core issue is which NetBeans modules can be considered core and
which ones optional - as the former cannot have dependencies with
incompatible licenses as per http://apache.org/legal/resolved.html
This will be clarified once NetBeans makes its first release, that's
when we'll need to clearly define what's core and what's optional.
Once the Incubator PMC votes and accepts that first release that's the
official ASF decision on that classification and we can then move
forward. In a top-level ASF project that decision would be made by the
project's PMC, but for a podling the PPMC has no formal power to make
such decisions.
Until then, I don't think it's useful to discuss this in much more
detail, before the code is here so that we can look at a potential
release candidate and discuss the details on a concrete basis.
This core/optional classification is totally orthogonal with Oracle's
selection of what to donate. We'll accept whatever Oracle donates, and
then sort it out to decide what we can release or not.
-Bertrand
Re: What to include/exclude in code donation to Apache
Posted by Niclas Hedhman <ni...@hedhman.org>.
Emanuel,
you know that the "type of users" isn't part of the Legal aspect. There are
only "downstream users" and doesn't matter if that is you (Java developer),
Google (say an IDE company) or Boeing (separate app). ASF cares about the
principles. There are similar situations from the past.
My point, Geertjan, is that it is *possible* that the Java Editor itself
(not the nb-javac) can not be released under Apache License. That means
development of that will need to be outside of ASF. And from what Wade is
hinting at, a bunch of other components may follow suit from that.
So, it needs to be worked out;
1. Can Java Editor be released under Apache License. Check with Legal for
that.
2. If not,
a. Is it within the scope of the community to find/create a working
replacement for nb-javac?
b. Or, will Java Editor (and everything depending on it or nb-javac) be
developed outside ASF, and how is that going to work in practice?
I am not asking for answers here and now, just that you all are aware of
this, and that it doesn't come as a big surprise when the first release is
voted down due to legal issues.
Cheers
Niclas
On Thu, Nov 3, 2016 at 11:35 PM, Emmanuel Lécharny <el...@gmail.com>
wrote:
>
>
> Le 03/11/16 à 15:31, Niclas Hedhman a écrit :
> > Again, if the Java Editor depends on nb-javac (and not the other way
> > around), the Java Editor needs clearance from VP Legal (who might need to
> > seek advice from Legal Counsel), whether the Java Editor can be licensed
> as
> > ALv2. I am not sure if there is a precedent in Apache before, but I have
> > seen FSF express that the CPE is not compatible with GPL for dynamically
> > linked languages. If the Java Editor will be deemed incompatible with
> ALv2,
> > then that too would need to reside outside ASF, and what would that mean
> > for overall credibility?
> >
> > "Netbeans - An Application Platform from Apache. With optional Add-ons
> for,
> > among many others, editing Java applications..., available from
> third-party
> > sources" doesn't rhyme well, does it?
> > Is Apache Netbeans willing to ship a package that can not contain the
> > central part of a Java IDE? I suspect not... and that is why Legal should
> > be consulted.
> Again, I don't think so. First because NetBeans is just a platform, and
> second because who knows if a replacement for nb-javac, under a AL 2.0
> license, will not be proposed in the next coming months ? But more
> important, the reason we don't allow the inclusion of GPL/CPE code is
> different.
>
> The full idea is really to protect those who will repackage the source
> to sell/release it on their own name, so that they can't be fooled :
> they *know* what they are doing because they *have* to pull a third
> party package under an AL 2.0 incompatible license. For end users, like
> you ad me, this is really a no-brainer.
>
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: What to include/exclude in code donation to Apache
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 03/11/16 à 15:31, Niclas Hedhman a écrit :
> Again, if the Java Editor depends on nb-javac (and not the other way
> around), the Java Editor needs clearance from VP Legal (who might need to
> seek advice from Legal Counsel), whether the Java Editor can be licensed as
> ALv2. I am not sure if there is a precedent in Apache before, but I have
> seen FSF express that the CPE is not compatible with GPL for dynamically
> linked languages. If the Java Editor will be deemed incompatible with ALv2,
> then that too would need to reside outside ASF, and what would that mean
> for overall credibility?
>
> "Netbeans - An Application Platform from Apache. With optional Add-ons for,
> among many others, editing Java applications..., available from third-party
> sources" doesn't rhyme well, does it?
> Is Apache Netbeans willing to ship a package that can not contain the
> central part of a Java IDE? I suspect not... and that is why Legal should
> be consulted.
Again, I don't think so. First because NetBeans is just a platform, and
second because who knows if a replacement for nb-javac, under a AL 2.0
license, will not be proposed in the next coming months ? But more
important, the reason we don't allow the inclusion of GPL/CPE code is
different.
The full idea is really to protect those who will repackage the source
to sell/release it on their own name, so that they can't be fooled :
they *know* what they are doing because they *have* to pull a third
party package under an AL 2.0 incompatible license. For end users, like
you ad me, this is really a no-brainer.
Re: What to include/exclude in code donation to Apache
Posted by Geertjan Wielenga <ge...@googlemail.com>.
On Thu, Nov 3, 2016 at 3:31 PM, Niclas Hedhman wrote:
> Is Apache Netbeans willing to ship a package that can not contain the
> central part of a Java IDE?
Yes. Indeed. During installation, the user will be able to specify that
they want Java support, at which point nb-javac will be downloaded (from
outside Apache) and installed into the local NetBeans installation. I
imagine the installer will ask which languages the user wants to make use
of, when Java is selected (and note that NetBeans is not only a Java IDE,
many people don't use Java with NetBeans at all, instead, they use PHP or
JavaScript or something else), nb-javac will be installed.
Gj
On Thu, Nov 3, 2016 at 3:31 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> Again, if the Java Editor depends on nb-javac (and not the other way
> around), the Java Editor needs clearance from VP Legal (who might need to
> seek advice from Legal Counsel), whether the Java Editor can be licensed as
> ALv2. I am not sure if there is a precedent in Apache before, but I have
> seen FSF express that the CPE is not compatible with GPL for dynamically
> linked languages. If the Java Editor will be deemed incompatible with ALv2,
> then that too would need to reside outside ASF, and what would that mean
> for overall credibility?
>
> "Netbeans - An Application Platform from Apache. With optional Add-ons for,
> among many others, editing Java applications..., available from third-party
> sources" doesn't rhyme well, does it?
> Is Apache Netbeans willing to ship a package that can not contain the
> central part of a Java IDE? I suspect not... and that is why Legal should
> be consulted.
>
>
> Niclas
>
>
> On Thu, Nov 3, 2016 at 6:19 PM, Emmanuel Lécharny <el...@gmail.com>
> wrote:
>
> >
> >
> > Le 03/11/16 à 11:09, Geertjan Wielenga a écrit :
> > > Well, the purpose of NetBeans is quite diverse, i.e., it is an open
> > source
> > > development environment, tooling platform, and application framework,
> all
> > > at the same time.
> > >
> > > For organizations like NATO and Boeing, the key purpose of NetBeans is
> an
> > > application framework, for example. For Gluon, and other organizations
> > > providing plugins, the key purpose of NetBeans is as a tooling
> platform.
> > >
> > > Essentially, on a technical level, indeed, the Java Editor and all
> > editing
> > > features are not core to NetBeans at all, regardless of the purpose of
> > > NetBeans.
> >
> > Pretty much like eclipse :-)
> >
> > I don't see that being an issue at all. If I want to use NetBeans to
> > code in C, I don't need the Java editor. Thsi si what I do with eclipse,
> > too...
> >
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>
Re: What to include/exclude in code donation to Apache
Posted by Niclas Hedhman <ni...@hedhman.org>.
Again, if the Java Editor depends on nb-javac (and not the other way
around), the Java Editor needs clearance from VP Legal (who might need to
seek advice from Legal Counsel), whether the Java Editor can be licensed as
ALv2. I am not sure if there is a precedent in Apache before, but I have
seen FSF express that the CPE is not compatible with GPL for dynamically
linked languages. If the Java Editor will be deemed incompatible with ALv2,
then that too would need to reside outside ASF, and what would that mean
for overall credibility?
"Netbeans - An Application Platform from Apache. With optional Add-ons for,
among many others, editing Java applications..., available from third-party
sources" doesn't rhyme well, does it?
Is Apache Netbeans willing to ship a package that can not contain the
central part of a Java IDE? I suspect not... and that is why Legal should
be consulted.
Niclas
On Thu, Nov 3, 2016 at 6:19 PM, Emmanuel Lécharny <el...@gmail.com>
wrote:
>
>
> Le 03/11/16 à 11:09, Geertjan Wielenga a écrit :
> > Well, the purpose of NetBeans is quite diverse, i.e., it is an open
> source
> > development environment, tooling platform, and application framework, all
> > at the same time.
> >
> > For organizations like NATO and Boeing, the key purpose of NetBeans is an
> > application framework, for example. For Gluon, and other organizations
> > providing plugins, the key purpose of NetBeans is as a tooling platform.
> >
> > Essentially, on a technical level, indeed, the Java Editor and all
> editing
> > features are not core to NetBeans at all, regardless of the purpose of
> > NetBeans.
>
> Pretty much like eclipse :-)
>
> I don't see that being an issue at all. If I want to use NetBeans to
> code in C, I don't need the Java editor. Thsi si what I do with eclipse,
> too...
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: What to include/exclude in code donation to Apache
Posted by Wade Chandler <wa...@apache.org>.
But let's not kid ourselves. Java support is very important to NetBeans
future; one can't build plugins without it. Oracle has committed to 2
releases from what I read, but I think if I am reading right, then perhaps
when JDK 9 support comes about nb-javac will be in NB main? Does that mean
with a new license or it is something different to replace it?
Next, Groovy support has dependencies on the Java modules. That also means
Gradle and Maven support do too I guess (I need to check on the Maven
part). The whole works out of the box bit or batteries included stuff
starts to look a bit different, and still trying to wrap my head around it.
That is a big chunk of the IDE. So, I am curious what things look like in
that context.
Too, any systems which have been built and depend on the Java support (or
Groovy) start to behave different or at least now must be deployed
differently; versus a static package or so it sounds. A good bit to mull
over. The whole IDE has been "the platform" to some degree in the past (a
long time); even a game platform was based on the IDE at one point.
My first thoughts are those things need to be redone some how to only have
to depend on things from the JDK or pure Apache NetBeans dependencies. That
or we are starting to see different branches of Java and JS support where
the old ones are supported one way, and new things another. My second is
that maybe it doesn't matter, but need to dwell on it more.
Wade
On Nov 3, 2016 6:23 AM, "Geertjan Wielenga" <
geertjan.wielenga@googlemail.com> wrote:
> On Thu, Nov 3, 2016 at 11:19 AM, Emmanuel Lécharny wrote:
>
> Pretty much like eclipse :-)
> >
> > I don't see that being an issue at all. If I want to use NetBeans to
> > code in C, I don't need the Java editor. Thsi si what I do with eclipse,
> > too...
>
>
>
> Exactly.
>
> Gj
>
>
> On Thu, Nov 3, 2016 at 11:19 AM, Emmanuel Lécharny <el...@gmail.com>
> wrote:
>
> >
> >
> > Le 03/11/16 à 11:09, Geertjan Wielenga a écrit :
> > > Well, the purpose of NetBeans is quite diverse, i.e., it is an open
> > source
> > > development environment, tooling platform, and application framework,
> all
> > > at the same time.
> > >
> > > For organizations like NATO and Boeing, the key purpose of NetBeans is
> an
> > > application framework, for example. For Gluon, and other organizations
> > > providing plugins, the key purpose of NetBeans is as a tooling
> platform.
> > >
> > > Essentially, on a technical level, indeed, the Java Editor and all
> > editing
> > > features are not core to NetBeans at all, regardless of the purpose of
> > > NetBeans.
> >
> > Pretty much like eclipse :-)
> >
> > I don't see that being an issue at all. If I want to use NetBeans to
> > code in C, I don't need the Java editor. Thsi si what I do with eclipse,
> > too...
> >
>
Re: What to include/exclude in code donation to Apache
Posted by Geertjan Wielenga <ge...@googlemail.com>.
On Thu, Nov 3, 2016 at 11:19 AM, Emmanuel Lécharny wrote:
Pretty much like eclipse :-)
>
> I don't see that being an issue at all. If I want to use NetBeans to
> code in C, I don't need the Java editor. Thsi si what I do with eclipse,
> too...
Exactly.
Gj
On Thu, Nov 3, 2016 at 11:19 AM, Emmanuel Lécharny <el...@gmail.com>
wrote:
>
>
> Le 03/11/16 à 11:09, Geertjan Wielenga a écrit :
> > Well, the purpose of NetBeans is quite diverse, i.e., it is an open
> source
> > development environment, tooling platform, and application framework, all
> > at the same time.
> >
> > For organizations like NATO and Boeing, the key purpose of NetBeans is an
> > application framework, for example. For Gluon, and other organizations
> > providing plugins, the key purpose of NetBeans is as a tooling platform.
> >
> > Essentially, on a technical level, indeed, the Java Editor and all
> editing
> > features are not core to NetBeans at all, regardless of the purpose of
> > NetBeans.
>
> Pretty much like eclipse :-)
>
> I don't see that being an issue at all. If I want to use NetBeans to
> code in C, I don't need the Java editor. Thsi si what I do with eclipse,
> too...
>
Re: What to include/exclude in code donation to Apache
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 03/11/16 à 11:09, Geertjan Wielenga a écrit :
> Well, the purpose of NetBeans is quite diverse, i.e., it is an open source
> development environment, tooling platform, and application framework, all
> at the same time.
>
> For organizations like NATO and Boeing, the key purpose of NetBeans is an
> application framework, for example. For Gluon, and other organizations
> providing plugins, the key purpose of NetBeans is as a tooling platform.
>
> Essentially, on a technical level, indeed, the Java Editor and all editing
> features are not core to NetBeans at all, regardless of the purpose of
> NetBeans.
Pretty much like eclipse :-)
I don't see that being an issue at all. If I want to use NetBeans to
code in C, I don't need the Java editor. Thsi si what I do with eclipse,
too...
Re: What to include/exclude in code donation to Apache
Posted by Geertjan Wielenga <ge...@googlemail.com>.
Well, the purpose of NetBeans is quite diverse, i.e., it is an open source
development environment, tooling platform, and application framework, all
at the same time.
For organizations like NATO and Boeing, the key purpose of NetBeans is an
application framework, for example. For Gluon, and other organizations
providing plugins, the key purpose of NetBeans is as a tooling platform.
Essentially, on a technical level, indeed, the Java Editor and all editing
features are not core to NetBeans at all, regardless of the purpose of
NetBeans.
Gj
On Thu, Nov 3, 2016 at 11:04 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> Yes, I know... I wrote an application on the platform back in 2001-2002, so
> I am very aware of it. But is that what we are going to make the primary
> purpose? Sorry to be a PITA about it...
>
> On Thu, Nov 3, 2016 at 6:02 PM, Geertjan Wielenga <
> geertjan.wielenga@googlemail.com> wrote:
>
> > The core of NetBeans is the NetBeans Platform, there's no Java Editor
> there
> > at all, take a look at what people are doing with the NetBeans Platform
> > here:
> >
> > https://platform.netbeans.org/screenshots.html
> >
> > Gj
> >
> > On Thu, Nov 3, 2016 at 10:56 AM, Niclas Hedhman <ni...@hedhman.org>
> > wrote:
> >
> > > On Thu, Nov 3, 2016 at 5:21 PM, Emmanuel Lécharny <elecharny@gmail.com
> >
> > > wrote:
> > >
> > > > For users to have them, they will have to install them on their side.
> > > > That could be done in many ways (market place, download, etc). The
> idea
> > > > is that it requires a *conscient* action from a user.
> > > >
> > >
> > > And there is also a strong expectation that core functionality doesn't
> > have
> > > "unusual systems requirements".
> > >
> > > Also, if Netbeans IDE in fact depends on nb-java means (in FSF's
> > > interpretation) that all of of Netbeans IDE needs to be licensed as
> GPL.
> > > and we can't have that, regardless of whether the user is required to
> > > download the piece manually. ONLY if the optional piece depend on
> > Netbeans
> > > IDE (not other way), then can such dependency exist from a licensing
> > point
> > > of view. I don't remember what Legal committee concluded about the
> > > "Classpath Exception", which FSF doesn't recognize as legit.
> > >
> > > If Netbeans IDE is not usable without this component, OR if the IDE is
> > > dependent on nb-javac, then this needs to be resolved. IMVHO, it is
> not a
> > > show-stopper for incubation, but will definitely be a a high priority
> > item
> > > prior to graduation.
> > >
> > > Just read Tulach comment on it; It doesn't change the basic underlying
> > > principles (those nagging bits that we take seriously). It is a
> Licensing
> > > issue, determined by what depends on what, and whether it is reasonably
> > > optional or not. The rest is mechanics, and solved by technologists,
> > which
> > > we have plenty... :-)
> > >
> > > 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: What to include/exclude in code donation to Apache
Posted by Niclas Hedhman <ni...@hedhman.org>.
Yes, I know... I wrote an application on the platform back in 2001-2002, so
I am very aware of it. But is that what we are going to make the primary
purpose? Sorry to be a PITA about it...
On Thu, Nov 3, 2016 at 6:02 PM, Geertjan Wielenga <
geertjan.wielenga@googlemail.com> wrote:
> The core of NetBeans is the NetBeans Platform, there's no Java Editor there
> at all, take a look at what people are doing with the NetBeans Platform
> here:
>
> https://platform.netbeans.org/screenshots.html
>
> Gj
>
> On Thu, Nov 3, 2016 at 10:56 AM, Niclas Hedhman <ni...@hedhman.org>
> wrote:
>
> > On Thu, Nov 3, 2016 at 5:21 PM, Emmanuel Lécharny <el...@gmail.com>
> > wrote:
> >
> > > For users to have them, they will have to install them on their side.
> > > That could be done in many ways (market place, download, etc). The idea
> > > is that it requires a *conscient* action from a user.
> > >
> >
> > And there is also a strong expectation that core functionality doesn't
> have
> > "unusual systems requirements".
> >
> > Also, if Netbeans IDE in fact depends on nb-java means (in FSF's
> > interpretation) that all of of Netbeans IDE needs to be licensed as GPL.
> > and we can't have that, regardless of whether the user is required to
> > download the piece manually. ONLY if the optional piece depend on
> Netbeans
> > IDE (not other way), then can such dependency exist from a licensing
> point
> > of view. I don't remember what Legal committee concluded about the
> > "Classpath Exception", which FSF doesn't recognize as legit.
> >
> > If Netbeans IDE is not usable without this component, OR if the IDE is
> > dependent on nb-javac, then this needs to be resolved. IMVHO, it is not a
> > show-stopper for incubation, but will definitely be a a high priority
> item
> > prior to graduation.
> >
> > Just read Tulach comment on it; It doesn't change the basic underlying
> > principles (those nagging bits that we take seriously). It is a Licensing
> > issue, determined by what depends on what, and whether it is reasonably
> > optional or not. The rest is mechanics, and solved by technologists,
> which
> > we have plenty... :-)
> >
> > 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: What to include/exclude in code donation to Apache
Posted by Geertjan Wielenga <ge...@googlemail.com>.
The core of NetBeans is the NetBeans Platform, there's no Java Editor there
at all, take a look at what people are doing with the NetBeans Platform
here:
https://platform.netbeans.org/screenshots.html
Gj
On Thu, Nov 3, 2016 at 10:56 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Thu, Nov 3, 2016 at 5:21 PM, Emmanuel Lécharny <el...@gmail.com>
> wrote:
>
> > For users to have them, they will have to install them on their side.
> > That could be done in many ways (market place, download, etc). The idea
> > is that it requires a *conscient* action from a user.
> >
>
> And there is also a strong expectation that core functionality doesn't have
> "unusual systems requirements".
>
> Also, if Netbeans IDE in fact depends on nb-java means (in FSF's
> interpretation) that all of of Netbeans IDE needs to be licensed as GPL.
> and we can't have that, regardless of whether the user is required to
> download the piece manually. ONLY if the optional piece depend on Netbeans
> IDE (not other way), then can such dependency exist from a licensing point
> of view. I don't remember what Legal committee concluded about the
> "Classpath Exception", which FSF doesn't recognize as legit.
>
> If Netbeans IDE is not usable without this component, OR if the IDE is
> dependent on nb-javac, then this needs to be resolved. IMVHO, it is not a
> show-stopper for incubation, but will definitely be a a high priority item
> prior to graduation.
>
> Just read Tulach comment on it; It doesn't change the basic underlying
> principles (those nagging bits that we take seriously). It is a Licensing
> issue, determined by what depends on what, and whether it is reasonably
> optional or not. The rest is mechanics, and solved by technologists, which
> we have plenty... :-)
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>
Re: What to include/exclude in code donation to Apache
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, Nov 3, 2016 at 5:21 PM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> For users to have them, they will have to install them on their side.
> That could be done in many ways (market place, download, etc). The idea
> is that it requires a *conscient* action from a user.
>
And there is also a strong expectation that core functionality doesn't have
"unusual systems requirements".
Also, if Netbeans IDE in fact depends on nb-java means (in FSF's
interpretation) that all of of Netbeans IDE needs to be licensed as GPL.
and we can't have that, regardless of whether the user is required to
download the piece manually. ONLY if the optional piece depend on Netbeans
IDE (not other way), then can such dependency exist from a licensing point
of view. I don't remember what Legal committee concluded about the
"Classpath Exception", which FSF doesn't recognize as legit.
If Netbeans IDE is not usable without this component, OR if the IDE is
dependent on nb-javac, then this needs to be resolved. IMVHO, it is not a
show-stopper for incubation, but will definitely be a a high priority item
prior to graduation.
Just read Tulach comment on it; It doesn't change the basic underlying
principles (those nagging bits that we take seriously). It is a Licensing
issue, determined by what depends on what, and whether it is reasonably
optional or not. The rest is mechanics, and solved by technologists, which
we have plenty... :-)
Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: What to include/exclude in code donation to Apache
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 03/11/16 à 10:02, Emilian Bold a écrit :
> There are about 4 nb-javac repositories you need to exclude.
>
> I don't believe it's sufficient for Oracle to maintain nb-javac and provide
> binaries under GPL v2 w/ CPE because we cannot include GPL binaries in
> Apache products (category X).
>
> This seems like a blocker to me for the Java editor.
>
> One solution would be for this to be part of OpenJDK/Oracle JDK proper and
> then we have it at runtime.
>
> Same with Graal.js, I don't believe we can use it. Either Graal.js becomes
> part of Nashorn APIs and we have it at runtime in OpenJDK or we switch to
> something else. We could revive the previous JavaScript editor based on
> Mozilla Rhino which is MPL.
>
> Could any of the mentors / legal confirm my interpretation wrt GPL w/ CPE
> dependencies?
You can't distribute GPL components, that's clear.
For users to have them, they will have to install them on their side.
That could be done in many ways (market place, download, etc). The idea
is that it requires a *conscient* action from a user.
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: What to include/exclude in code donation to Apache
Posted by Martin Balin <Ma...@Oracle.COM>.
Hello,
On 3.11.2016 10:02, Emilian Bold wrote:
> There are about 4 nb-javac repositories you need to exclude.
main/nb-javac-9 <http://hg.netbeans.org/main/nb-javac-9/>
main/nb-javac-jdk8 <http://hg.netbeans.org/main/nb-javac-jdk8/>
main/nb-javac-jdk9 <http://hg.netbeans.org/main/nb-javac-jdk9/>
are experimental used for JDK9 and Jigsaw development and they are not
needed anymore as JDK9 support is now in trunk of NB sources. They will
be removed to not confuse.
Martin
>
> I don't believe it's sufficient for Oracle to maintain nb-javac and provide
> binaries under GPL v2 w/ CPE because we cannot include GPL binaries in
> Apache products (category X).
>
> This seems like a blocker to me for the Java editor.
>
> One solution would be for this to be part of OpenJDK/Oracle JDK proper and
> then we have it at runtime.
>
> Same with Graal.js, I don't believe we can use it. Either Graal.js becomes
> part of Nashorn APIs and we have it at runtime in OpenJDK or we switch to
> something else. We could revive the previous JavaScript editor based on
> Mozilla Rhino which is MPL.
>
> Could any of the mentors / legal confirm my interpretation wrt GPL w/ CPE
> dependencies?
>
>
> Pe joi, 3 noiembrie 2016, Geertjan Wielenga <
> geertjan.wielenga@googlemail.com> a scris:
>
>> Hi all,
>>
>> A key discussion going on right now that we should externalize via this,
>> the dev list, is what exactly is included in the code donation by Oracle of
>> NetBeans to Apache.
>>
>> In principle, what we'd like to say is that we're donating 'NetBeans' to
>> Apache. But what is 'NetBeans'? The more specifically we define it, the
>> greater the chance that we'll accidentally exclude something; the more
>> generically we define it, the greater the chance that we'll end up with
>> misunderstandings about what exactly the donation consists of.
>>
>> So -- on the level of the code (i.e., separate from documentation,
>> netbeans.org, etc) -- we could say we are donating 'everything at
>> hg.netbeans.org'. A problem with this is that this is not correct -- in
>> particular, Oracle is not donating the 'nb-javac' libraries, i.e., the fork
>> of the Java compiler, which is licensed GPLv2 with CPE and is part of the
>> JDK and is explicitly not part of the donation to Apache.
>>
>> The question is how to formulate that for the code donation, i.e., for the
>> software grant document.
>>
>> Since nb-javac has its own repo where it is developed, i.e.,
>> http://hg.netbeans.org/main/nb-javac, which results in 2 JAR files
>> (nb-javac-api.jar and nb-javac-impl) used in Java cluster, we could try
>> this verbiage: "NetBeans source code at hg.netbeans.org, excluding
>> hg.netbeans.org/main/nb-javac". I think that's very clear.
>>
>> A related point is that, of course, nb-javac is needed (not by the core of
>> NetBeans, which is the NetBeans Platform but by the optional modules that
>> relate to the Java Editor) both for building and using the Java tooling of
>> NetBeans. For that, we have solutions in mind -- Oracle continues to
>> develop nb-javac, makes it available outside Apache, via build scripts
>> these will be included into the build process, and during installation
>> they'll be accessed from their external location and included in the right
>> location in the installed NetBeans.
>>
>> So, that deals with nb-javac. Aside from that, there's also Graal.js, the
>> ECMAScript 6 parser by Oracle Labs that is not being donated by Oracle,
>> which needs to be explicitly stated as well. Furthermore, Emilian, as
>> mentioned in the thread he's started, has created a shell script for
>> identifying potentially other parts of NetBeans that we need to investigate
>> together in terms of where they stand in terms of the Oracle code donation.
>>
>> These items above I will be adding to the Wiki so that it's documented and
>> I encourage any feedback to the above, as well as encouraging anyone with
>> proposals of any kind to put together a Wiki around that topic.
>>
>> Many thanks,
>>
>> Gj
>>
>
Re: What to include/exclude in code donation to Apache
Posted by Geertjan Wielenga <ge...@googlemail.com>.
Here's research by Jaroslav Tulach on how nb-javac can be distributed:
http://wiki.apidesign.org/wiki/AutoUpdate
Gj
On Thu, Nov 3, 2016 at 10:45 AM, Ralph Benjamin Ruijs <
ralph.benjamin@gmail.com> wrote:
> Hi,
>
>
> 2016-11-03 10:23 GMT+01:00 Emilian Bold <em...@apache.org>:
> > I don't believe we can apply the same approach like we did for Junit.
> >
> > Not everybody uses or needs Junit so we can download that conditionally.
> >
> > But the Java editor will not work without nb-javac and the JavaScript
> > editor won't work without the Graaj.js parser.
>
> But there is a lot that does work, without the nb-javac or graal, like
> cpp, php and python to name only a few.
>
> @Geertjan, can you talk with Dusan and Honza Lahoda if it is even
> possible/reasonable to use openjdk as the base of our nb-javac fork?
> There is years of development put into nb-javac, so I personally think
> it is near impossible, but they can tell us.
>
>
> - Ralph
>
Re: What to include/exclude in code donation to Apache
Posted by Ralph Benjamin Ruijs <ra...@gmail.com>.
Hi,
2016-11-03 10:23 GMT+01:00 Emilian Bold <em...@apache.org>:
> I don't believe we can apply the same approach like we did for Junit.
>
> Not everybody uses or needs Junit so we can download that conditionally.
>
> But the Java editor will not work without nb-javac and the JavaScript
> editor won't work without the Graaj.js parser.
But there is a lot that does work, without the nb-javac or graal, like
cpp, php and python to name only a few.
@Geertjan, can you talk with Dusan and Honza Lahoda if it is even
possible/reasonable to use openjdk as the base of our nb-javac fork?
There is years of development put into nb-javac, so I personally think
it is near impossible, but they can tell us.
- Ralph
Re: What to include/exclude in code donation to Apache
Posted by Emilian Bold <em...@apache.org>.
I don't believe we can apply the same approach like we did for Junit.
Not everybody uses or needs Junit so we can download that conditionally.
But the Java editor will not work without nb-javac and the JavaScript
editor won't work without the Graaj.js parser.
Pe joi, 3 noiembrie 2016, Geertjan Wielenga <
geertjan.wielenga@googlemail.com> a scris:
> They will not be included. That's what I wrote already. They will not be
> included. They will be installed separately during installation.
>
> Gj
>
> On Thursday, November 3, 2016, Emilian Bold <emilian.bold@gmail.com
> <javascript:;>> wrote:
>
> > There are about 4 nb-javac repositories you need to exclude.
> >
> > I don't believe it's sufficient for Oracle to maintain nb-javac and
> provide
> > binaries under GPL v2 w/ CPE because we cannot include GPL binaries in
> > Apache products (category X).
> >
> > This seems like a blocker to me for the Java editor.
> >
> > One solution would be for this to be part of OpenJDK/Oracle JDK proper
> and
> > then we have it at runtime.
> >
> > Same with Graal.js, I don't believe we can use it. Either Graal.js
> becomes
> > part of Nashorn APIs and we have it at runtime in OpenJDK or we switch to
> > something else. We could revive the previous JavaScript editor based on
> > Mozilla Rhino which is MPL.
> >
> > Could any of the mentors / legal confirm my interpretation wrt GPL w/ CPE
> > dependencies?
> >
> >
> > Pe joi, 3 noiembrie 2016, Geertjan Wielenga <
> > geertjan.wielenga@googlemail.com <javascript:;> <javascript:;>> a scris:
> >
> > > Hi all,
> > >
> > > A key discussion going on right now that we should externalize via
> this,
> > > the dev list, is what exactly is included in the code donation by
> Oracle
> > of
> > > NetBeans to Apache.
> > >
> > > In principle, what we'd like to say is that we're donating 'NetBeans'
> to
> > > Apache. But what is 'NetBeans'? The more specifically we define it, the
> > > greater the chance that we'll accidentally exclude something; the more
> > > generically we define it, the greater the chance that we'll end up with
> > > misunderstandings about what exactly the donation consists of.
> > >
> > > So -- on the level of the code (i.e., separate from documentation,
> > > netbeans.org, etc) -- we could say we are donating 'everything at
> > > hg.netbeans.org'. A problem with this is that this is not correct --
> in
> > > particular, Oracle is not donating the 'nb-javac' libraries, i.e., the
> > fork
> > > of the Java compiler, which is licensed GPLv2 with CPE and is part of
> the
> > > JDK and is explicitly not part of the donation to Apache.
> > >
> > > The question is how to formulate that for the code donation, i.e., for
> > the
> > > software grant document.
> > >
> > > Since nb-javac has its own repo where it is developed, i.e.,
> > > http://hg.netbeans.org/main/nb-javac, which results in 2 JAR files
> > > (nb-javac-api.jar and nb-javac-impl) used in Java cluster, we could try
> > > this verbiage: "NetBeans source code at hg.netbeans.org, excluding
> > > hg.netbeans.org/main/nb-javac". I think that's very clear.
> > >
> > > A related point is that, of course, nb-javac is needed (not by the core
> > of
> > > NetBeans, which is the NetBeans Platform but by the optional modules
> that
> > > relate to the Java Editor) both for building and using the Java tooling
> > of
> > > NetBeans. For that, we have solutions in mind -- Oracle continues to
> > > develop nb-javac, makes it available outside Apache, via build scripts
> > > these will be included into the build process, and during installation
> > > they'll be accessed from their external location and included in the
> > right
> > > location in the installed NetBeans.
> > >
> > > So, that deals with nb-javac. Aside from that, there's also Graal.js,
> the
> > > ECMAScript 6 parser by Oracle Labs that is not being donated by Oracle,
> > > which needs to be explicitly stated as well. Furthermore, Emilian, as
> > > mentioned in the thread he's started, has created a shell script for
> > > identifying potentially other parts of NetBeans that we need to
> > investigate
> > > together in terms of where they stand in terms of the Oracle code
> > donation.
> > >
> > > These items above I will be adding to the Wiki so that it's documented
> > and
> > > I encourage any feedback to the above, as well as encouraging anyone
> with
> > > proposals of any kind to put together a Wiki around that topic.
> > >
> > > Many thanks,
> > >
> > > Gj
> > >
> >
> >
> > --
> >
> > --emi
> >
>
--
--emi
Re: What to include/exclude in code donation to Apache
Posted by Geertjan Wielenga <ge...@googlemail.com>.
They will not be included. That's what I wrote already. They will not be
included. They will be installed separately during installation.
Gj
On Thursday, November 3, 2016, Emilian Bold <em...@gmail.com> wrote:
> There are about 4 nb-javac repositories you need to exclude.
>
> I don't believe it's sufficient for Oracle to maintain nb-javac and provide
> binaries under GPL v2 w/ CPE because we cannot include GPL binaries in
> Apache products (category X).
>
> This seems like a blocker to me for the Java editor.
>
> One solution would be for this to be part of OpenJDK/Oracle JDK proper and
> then we have it at runtime.
>
> Same with Graal.js, I don't believe we can use it. Either Graal.js becomes
> part of Nashorn APIs and we have it at runtime in OpenJDK or we switch to
> something else. We could revive the previous JavaScript editor based on
> Mozilla Rhino which is MPL.
>
> Could any of the mentors / legal confirm my interpretation wrt GPL w/ CPE
> dependencies?
>
>
> Pe joi, 3 noiembrie 2016, Geertjan Wielenga <
> geertjan.wielenga@googlemail.com <javascript:;>> a scris:
>
> > Hi all,
> >
> > A key discussion going on right now that we should externalize via this,
> > the dev list, is what exactly is included in the code donation by Oracle
> of
> > NetBeans to Apache.
> >
> > In principle, what we'd like to say is that we're donating 'NetBeans' to
> > Apache. But what is 'NetBeans'? The more specifically we define it, the
> > greater the chance that we'll accidentally exclude something; the more
> > generically we define it, the greater the chance that we'll end up with
> > misunderstandings about what exactly the donation consists of.
> >
> > So -- on the level of the code (i.e., separate from documentation,
> > netbeans.org, etc) -- we could say we are donating 'everything at
> > hg.netbeans.org'. A problem with this is that this is not correct -- in
> > particular, Oracle is not donating the 'nb-javac' libraries, i.e., the
> fork
> > of the Java compiler, which is licensed GPLv2 with CPE and is part of the
> > JDK and is explicitly not part of the donation to Apache.
> >
> > The question is how to formulate that for the code donation, i.e., for
> the
> > software grant document.
> >
> > Since nb-javac has its own repo where it is developed, i.e.,
> > http://hg.netbeans.org/main/nb-javac, which results in 2 JAR files
> > (nb-javac-api.jar and nb-javac-impl) used in Java cluster, we could try
> > this verbiage: "NetBeans source code at hg.netbeans.org, excluding
> > hg.netbeans.org/main/nb-javac". I think that's very clear.
> >
> > A related point is that, of course, nb-javac is needed (not by the core
> of
> > NetBeans, which is the NetBeans Platform but by the optional modules that
> > relate to the Java Editor) both for building and using the Java tooling
> of
> > NetBeans. For that, we have solutions in mind -- Oracle continues to
> > develop nb-javac, makes it available outside Apache, via build scripts
> > these will be included into the build process, and during installation
> > they'll be accessed from their external location and included in the
> right
> > location in the installed NetBeans.
> >
> > So, that deals with nb-javac. Aside from that, there's also Graal.js, the
> > ECMAScript 6 parser by Oracle Labs that is not being donated by Oracle,
> > which needs to be explicitly stated as well. Furthermore, Emilian, as
> > mentioned in the thread he's started, has created a shell script for
> > identifying potentially other parts of NetBeans that we need to
> investigate
> > together in terms of where they stand in terms of the Oracle code
> donation.
> >
> > These items above I will be adding to the Wiki so that it's documented
> and
> > I encourage any feedback to the above, as well as encouraging anyone with
> > proposals of any kind to put together a Wiki around that topic.
> >
> > Many thanks,
> >
> > Gj
> >
>
>
> --
>
> --emi
>
Re: What to include/exclude in code donation to Apache
Posted by Emilian Bold <em...@gmail.com>.
There are about 4 nb-javac repositories you need to exclude.
I don't believe it's sufficient for Oracle to maintain nb-javac and provide
binaries under GPL v2 w/ CPE because we cannot include GPL binaries in
Apache products (category X).
This seems like a blocker to me for the Java editor.
One solution would be for this to be part of OpenJDK/Oracle JDK proper and
then we have it at runtime.
Same with Graal.js, I don't believe we can use it. Either Graal.js becomes
part of Nashorn APIs and we have it at runtime in OpenJDK or we switch to
something else. We could revive the previous JavaScript editor based on
Mozilla Rhino which is MPL.
Could any of the mentors / legal confirm my interpretation wrt GPL w/ CPE
dependencies?
Pe joi, 3 noiembrie 2016, Geertjan Wielenga <
geertjan.wielenga@googlemail.com> a scris:
> Hi all,
>
> A key discussion going on right now that we should externalize via this,
> the dev list, is what exactly is included in the code donation by Oracle of
> NetBeans to Apache.
>
> In principle, what we'd like to say is that we're donating 'NetBeans' to
> Apache. But what is 'NetBeans'? The more specifically we define it, the
> greater the chance that we'll accidentally exclude something; the more
> generically we define it, the greater the chance that we'll end up with
> misunderstandings about what exactly the donation consists of.
>
> So -- on the level of the code (i.e., separate from documentation,
> netbeans.org, etc) -- we could say we are donating 'everything at
> hg.netbeans.org'. A problem with this is that this is not correct -- in
> particular, Oracle is not donating the 'nb-javac' libraries, i.e., the fork
> of the Java compiler, which is licensed GPLv2 with CPE and is part of the
> JDK and is explicitly not part of the donation to Apache.
>
> The question is how to formulate that for the code donation, i.e., for the
> software grant document.
>
> Since nb-javac has its own repo where it is developed, i.e.,
> http://hg.netbeans.org/main/nb-javac, which results in 2 JAR files
> (nb-javac-api.jar and nb-javac-impl) used in Java cluster, we could try
> this verbiage: "NetBeans source code at hg.netbeans.org, excluding
> hg.netbeans.org/main/nb-javac". I think that's very clear.
>
> A related point is that, of course, nb-javac is needed (not by the core of
> NetBeans, which is the NetBeans Platform but by the optional modules that
> relate to the Java Editor) both for building and using the Java tooling of
> NetBeans. For that, we have solutions in mind -- Oracle continues to
> develop nb-javac, makes it available outside Apache, via build scripts
> these will be included into the build process, and during installation
> they'll be accessed from their external location and included in the right
> location in the installed NetBeans.
>
> So, that deals with nb-javac. Aside from that, there's also Graal.js, the
> ECMAScript 6 parser by Oracle Labs that is not being donated by Oracle,
> which needs to be explicitly stated as well. Furthermore, Emilian, as
> mentioned in the thread he's started, has created a shell script for
> identifying potentially other parts of NetBeans that we need to investigate
> together in terms of where they stand in terms of the Oracle code donation.
>
> These items above I will be adding to the Wiki so that it's documented and
> I encourage any feedback to the above, as well as encouraging anyone with
> proposals of any kind to put together a Wiki around that topic.
>
> Many thanks,
>
> Gj
>
--
--emi
Re: What to include/exclude in code donation to Apache
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Thu, Nov 3, 2016 at 8:42 AM, Geertjan Wielenga
<ge...@googlemail.com> wrote:
> ...we could try
> this verbiage: "NetBeans source code at hg.netbeans.org, excluding
> hg.netbeans.org/main/nb-javac". I think that's very clear...
Yes, that would work for me.
From the ASF's point of view my concern is that things must be
sufficiently clear for whoever imports code into our repositories to
objectively decide what to import or not. Statements like the above
one are perfectly fine.
As a contrary example, someone earlier suggested (elsewhere, thanks
for bringing this discussion here now BTW) considering "only files
which are copyright Oracle", that's the kind of qualifier that I find
insufficient as it doesn't say how we can find out about that
copyright. If something like this is needed it should describe a very
clear "filter", like "only files which have an embedded Oracle
copyright header".
-Bertrand
Re: What to include/exclude in code donation to Apache
Posted by Niclas Hedhman <ni...@hedhman.org>.
I feel your pain, and it is really good that you take point on getting this
sorted out.
Now, one thing I think needs to be quite clear; If "Netbeans - the Java
IDE" is donated (or part of a larger donation), then I strongly expect that
the community intends to replace the nb-javac with its own mechanism to
hook into the "System Requirement" of "OpenJDK distribution" (potentially
others), and not depend on this nb-javac component that is running a risk
of being completely orphaned soon enough.
I hope this is what the community has in mind as well, and just wanted to
make it clear.
Cheers
On Thu, Nov 3, 2016 at 3:42 PM, Geertjan Wielenga <
geertjan.wielenga@googlemail.com> wrote:
> Hi all,
>
> A key discussion going on right now that we should externalize via this,
> the dev list, is what exactly is included in the code donation by Oracle of
> NetBeans to Apache.
>
> In principle, what we'd like to say is that we're donating 'NetBeans' to
> Apache. But what is 'NetBeans'? The more specifically we define it, the
> greater the chance that we'll accidentally exclude something; the more
> generically we define it, the greater the chance that we'll end up with
> misunderstandings about what exactly the donation consists of.
>
> So -- on the level of the code (i.e., separate from documentation,
> netbeans.org, etc) -- we could say we are donating 'everything at
> hg.netbeans.org'. A problem with this is that this is not correct -- in
> particular, Oracle is not donating the 'nb-javac' libraries, i.e., the fork
> of the Java compiler, which is licensed GPLv2 with CPE and is part of the
> JDK and is explicitly not part of the donation to Apache.
>
> The question is how to formulate that for the code donation, i.e., for the
> software grant document.
>
> Since nb-javac has its own repo where it is developed, i.e.,
> http://hg.netbeans.org/main/nb-javac, which results in 2 JAR files
> (nb-javac-api.jar and nb-javac-impl) used in Java cluster, we could try
> this verbiage: "NetBeans source code at hg.netbeans.org, excluding
> hg.netbeans.org/main/nb-javac". I think that's very clear.
>
> A related point is that, of course, nb-javac is needed (not by the core of
> NetBeans, which is the NetBeans Platform but by the optional modules that
> relate to the Java Editor) both for building and using the Java tooling of
> NetBeans. For that, we have solutions in mind -- Oracle continues to
> develop nb-javac, makes it available outside Apache, via build scripts
> these will be included into the build process, and during installation
> they'll be accessed from their external location and included in the right
> location in the installed NetBeans.
>
> So, that deals with nb-javac. Aside from that, there's also Graal.js, the
> ECMAScript 6 parser by Oracle Labs that is not being donated by Oracle,
> which needs to be explicitly stated as well. Furthermore, Emilian, as
> mentioned in the thread he's started, has created a shell script for
> identifying potentially other parts of NetBeans that we need to investigate
> together in terms of where they stand in terms of the Oracle code donation.
>
> These items above I will be adding to the Wiki so that it's documented and
> I encourage any feedback to the above, as well as encouraging anyone with
> proposals of any kind to put together a Wiki around that topic.
>
> Many thanks,
>
> Gj
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java