Re: Optional modules with GPL dependencies (was: What to include/exclude in code donation to Apache)

[Emmanuel Lécharny]

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)

[Wade Chandler]

The installer could even setup the directory, and an institution can copy
that. The installer could also build other installers as another option;
for private distribution by end users.

Wade

On Nov 8, 2016 5:11 AM, "Geertjan Wielenga" <
geertjan.wiele...@googlemail.com> wrote:

> Yup. I'm sure we can do a solution like where on the download page we'd
> specify that they can install the requirements for Java tooling during
> installation or via a download package on the same page as where the
> NetBeans installer itself is found.
>
> Gj
>
> On Tue, Nov 8, 2016 at 10:39 AM, Leonardo Loch Zanivan <
> leonardo.zani...@gmail.com> wrote:
>
> > The above is true for companies and educational institutions.
> > Internet access is very restricted and often require a proxy setup.
> >
> > Leonardo
> >
> > On Tue, Nov 8, 2016 at 6:21 AM Julien Enselme 
> wrote:
> >
> > > I generally have no big problems with downloads at install time.
> > > However, some users may download the installer to install NetBeans on a
> > > computer without internet access. What then? Will Java will work in a
> > > degraded mode? Will it be possible for the user to manually install the
> > > JARs?
> > >
> > > IMHO, this shouldn't be a blocker since I don't think it represents
> > > many users but I still think we must not forget them.
> > >
> > > On Mon, 2016-11-07 at 18:31 -0500, Steven Yi wrote:
> > > > +1
> > > >
> > > > I'm all for the single installer with different module download
> > > > options.
> > > >
> > > > On Mon, Nov 7, 2016 at 6:19 PM, John McDonnell  > > > com> wrote:
> > > > >
> > > > >
> > > > > >
> > > > > > On 7 Nov 2016, at 23:13, Geertjan Wielenga  > > > > > glemail.com> wrote:
> > > > > >
> > > > > > I think the above would actually be a big improvement over the
> > > > > > current
> > > > > > situation where there are multiple downloads.
> > > > >
> > > > > +1
> > > > >
> > > > > A single download would definitely be simpler and this
> > > > > languages/technology choice could just be an extension of the
> > > > > current plugin mechanism.
> > > > >
> > > > > Regards
> > > > >
> > > > > John
> > > > >
> > > > > >
> > > > > > On 7 Nov 2016, at 23:13, Geertjan Wielenga  > > > > > glemail.com> wrote:
> > > > > >
> > > > > > Good question and unclear at this point what the solution should
> > > > > > be.
> > > > > > Personally, wouldn't it be simplest to have one single download
> > > > > > (certainly
> > > > > > simpler than the current situation) and then the installer asks
> > > > > > which
> > > > > > languages/technologies you need? If, among others, Java is
> > > > > > selected,
> > > > > > nb-javac (simply two JAR files, by the way, at the end of the
> > > > > > day) would be
> > > > > > downloaded and installed.
> > > > > >
> > > > > > I think the above would actually be a big improvement over the
> > > > > > current
> > > > > > situation where there are multiple downloads.
> > > > > >
> > > > > > Gj
> > > > > >
> > > > > > On Tue, Nov 8, 2016 at 12:05 AM, John McDonnell  > > > > > mail.com>
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > So how do you see this going forward?
> > > > > > >
> > > > > > > Currently we have 6 download packages, will we have multiple
> > > > > > > ones when we
> > > > > > > Apache Netbeans is released?, or will we have 4 downloads
> > > > > > > (HTML+Javascript,
> > > > > > > PHP & C/C++, ALL), but the installer always gives the option to
> > > > > > > install
> > > > > > > Java?  As I think I could get behind that, provided we don’t
> > > > > > > forget to
> > > > > > > advertise that Java is a “first class citizen” in the Netbeans
> > > > > > > Ecosystem.
> > > > > > >
> > > > > > >
> > > > > > > Regards
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > On 7 Nov 2016, at 22:56, Geertjan Wielenga <
> > > > > > > geertjan.wiele...@googlemail.com> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > It would be a smooth process via the installer.
> > > > > > > >
> > > > > > > > Gj
> > > > > > > >
> > > > > > > > On Mon, Nov 7, 2016 at 11:43 PM, John Yeary  > > > > > > > com> wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Hello All,
> > > > > > > > >
> > > > > > > > > I agree with John.
> > > > > > > > >
> > > > > > > > > One of the things that I really find annoying about Eclipse
> > > > > > > > > is that you
> > > > > > > > > have all of these options, and as a new user it is a
> > > > > > > > > daunting task to
> > > > > > > pick
> > > > > > > >
> > > > > > > > >
> > > > > > > > > what you need, or even KNOW what you need.
> > > > > > > > >
> > > > > > > > > If we start asking new users to go download modules to make
> > > > > > > > > it a
> > > > > > > functional
> > > > > > > >
> > > > > > > > >
> > > > > > > > > IDE, it is a non-starter. 

Re: Optional modules with GPL dependencies (was: What to include/exclude in code donation to Apache)

[John McDonnell]

Hi, 

So how do you see this going forward?

Currently we have 6 download packages, will we have multiple ones when we 
Apache Netbeans is released?, or will we have 4 downloads (HTML+Javascript, PHP 
& C/C++, ALL), but the installer always gives the option to install Java?  As I 
think I could get behind that, provided we don’t forget to advertise that Java 
is a “first class citizen” in the Netbeans Ecosystem.


Regards

John



> On 7 Nov 2016, at 22:56, Geertjan Wielenga  
> wrote:
> 
> It would be a smooth process via the installer.
> 
> Gj
> 
> On Mon, Nov 7, 2016 at 11:43 PM, John Yeary  wrote:
> 
>> Hello All,
>> 
>> I agree with John.
>> 
>> One of the things that I really find annoying about Eclipse is that you
>> have all of these options, and as a new user it is a daunting task to pick
>> what you need, or even KNOW what you need.
>> 
>> If we start asking new users to go download modules to make it a functional
>> IDE, it is a non-starter. The ease of use that NetBeans is known for
>> suddenly is no longer.
>> 
>> 
>> 
>> 
>> 
>> John Yeary
>> 
>> *NetBeans Dream Team*
>> 
>> *Founder Greenville Java Users GroupJava Users Groups Community Leader*
>> 
>> 
>>   
>>   
>> 
>> 
>> 
>> 
>> 
>> "Far better it is to dare mighty things, to win glorious triumphs, even
>> though checkered by failure, than to take rank with those poor spirits who
>> neither enjoy much nor suffer much, because they live in the gray twilight
>> that knows not victory nor defeat."
>> -- Theodore Roosevelt
>> 
>> On Mon, Nov 7, 2016 at 5:28 PM, John McDonnell 
>> wrote:
>> 
>>> HI,
>>> 
>>> To me Netbeans has always been first and foremost a Java IDE.  This move
>>> now seems to be making Java an optional extra to Netbeans that means I
>> need
>>> to head off somewhere else to get this nb-javac module.
>>> 
>>> Now I was probably wrong in always thinking that NB is a Java IDE first
>>> and foremost, as when I go to the Downloads[1] page 3 of the 6
>>> download-able packages don’t contain Java.
>>> 
>>> Is it worth getting download numbers for each of the 5 packages and
>> seeing
>>> what % of user base this change would effect currently?
>>> 
>>> Will this additional download drive Java Developers away from Netbeans?
>>> 
>>> Regards
>>> 
>>> John
>>> 
>>> 
>>> [1]: https://netbeans.org/downloads/ 
>>> 
 On 7 Nov 2016, at 15:27, Geertjan Wielenga <
>>> geertjan.wiele...@googlemail.com> wrote:
 
 On Mon, Nov 7, 2016 at 2:58 PM, Shan Curcuru wrote:
 
 
> As a non-regular NetBeans user, I have a clarifying question from a
> *newcomers* perspective that I think will help on the "ASF code means
>> no
> licensing surprises" side.
 
 
 1- Yes. Assuming we resolve other issues that are going to be coming
>> up,
 i.e., nb-javac is the current hurdle we're focusing on, though there
>> are
 smaller ones to follow unrelated to this specific legal issue that
>> we're
 now focused on. [See
 https://cwiki.apache.org/confluence/display/NETBEANS/
>>> Overview%3A+NetBeans+Structure
 to predict upcoming legal discussions.]
 
 2- Yes.
 
 3- Yes.
 
 4- Yes.
 
 Thanks, and I agree, what we're doing is in sync with the "ASF code
>> means
 no licensing surprises" side.
 
 Gj
 
 On Mon, Nov 7, 2016 at 2:58 PM, Shane Curcuru 
>>> wrote:
 
> On 2016-11-06 15:01 (-0500), Geertjan Wielenga
>  wrote: > 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.
> ...snip...
> 
> As a non-regular NetBeans user, I have a clarifying question from a
> *newcomers* perspective that I think will help on the "ASF code means
>> no
> licensing surprises" side.
> 
> 1- If I want a great IDE where I can edit my C, JavaScript, PHP, HTML
> and other non-Java code, and check it in, build it, etc. - can I
> download NetBeans (plus perhaps some other modules) where *all* of the
> source code I'm downloading is under a Category A license?
> 
> 
> 2- If I then want to use NetBeans to edit/build Java code, apparently
> (as a new 

Re: Optional modules with GPL dependencies (was: What to include/exclude in code donation to Apache)

[Geertjan Wielenga]

It would be a smooth process via the installer.

Gj

On Mon, Nov 7, 2016 at 11:43 PM, John Yeary  wrote:

> Hello All,
>
> I agree with John.
>
> One of the things that I really find annoying about Eclipse is that you
> have all of these options, and as a new user it is a daunting task to pick
> what you need, or even KNOW what you need.
>
> If we start asking new users to go download modules to make it a functional
> IDE, it is a non-starter. The ease of use that NetBeans is known for
> suddenly is no longer.
>
>
>
> 
>
> John Yeary
> 
> *NetBeans Dream Team*
>
> *Founder Greenville Java Users GroupJava Users Groups Community Leader*
> 
>
>   
>   
> 
> 
> 
> 
>
> "Far better it is to dare mighty things, to win glorious triumphs, even
> though checkered by failure, than to take rank with those poor spirits who
> neither enjoy much nor suffer much, because they live in the gray twilight
> that knows not victory nor defeat."
> -- Theodore Roosevelt
>
> On Mon, Nov 7, 2016 at 5:28 PM, John McDonnell 
> wrote:
>
> > HI,
> >
> > To me Netbeans has always been first and foremost a Java IDE.  This move
> > now seems to be making Java an optional extra to Netbeans that means I
> need
> > to head off somewhere else to get this nb-javac module.
> >
> > Now I was probably wrong in always thinking that NB is a Java IDE first
> > and foremost, as when I go to the Downloads[1] page 3 of the 6
> > download-able packages don’t contain Java.
> >
> > Is it worth getting download numbers for each of the 5 packages and
> seeing
> > what % of user base this change would effect currently?
> >
> > Will this additional download drive Java Developers away from Netbeans?
> >
> > Regards
> >
> > John
> >
> >
> > [1]: https://netbeans.org/downloads/ 
> >
> > > On 7 Nov 2016, at 15:27, Geertjan Wielenga <
> > geertjan.wiele...@googlemail.com> wrote:
> > >
> > > On Mon, Nov 7, 2016 at 2:58 PM, Shan Curcuru wrote:
> > >
> > >
> > >> As a non-regular NetBeans user, I have a clarifying question from a
> > >> *newcomers* perspective that I think will help on the "ASF code means
> no
> > >> licensing surprises" side.
> > >
> > >
> > > 1- Yes. Assuming we resolve other issues that are going to be coming
> up,
> > > i.e., nb-javac is the current hurdle we're focusing on, though there
> are
> > > smaller ones to follow unrelated to this specific legal issue that
> we're
> > > now focused on. [See
> > > https://cwiki.apache.org/confluence/display/NETBEANS/
> > Overview%3A+NetBeans+Structure
> > > to predict upcoming legal discussions.]
> > >
> > > 2- Yes.
> > >
> > > 3- Yes.
> > >
> > > 4- Yes.
> > >
> > > Thanks, and I agree, what we're doing is in sync with the "ASF code
> means
> > > no licensing surprises" side.
> > >
> > > Gj
> > >
> > > On Mon, Nov 7, 2016 at 2:58 PM, Shane Curcuru 
> > wrote:
> > >
> > >> On 2016-11-06 15:01 (-0500), Geertjan Wielenga
> > >>  wrote: > 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.
> > >> ...snip...
> > >>
> > >> As a non-regular NetBeans user, I have a clarifying question from a
> > >> *newcomers* perspective that I think will help on the "ASF code means
> no
> > >> licensing surprises" side.
> > >>
> > >> 1- If I want a great IDE where I can edit my C, JavaScript, PHP, HTML
> > >> and other non-Java code, and check it in, build it, etc. - can I
> > >> download NetBeans (plus perhaps some other modules) where *all* of the
> > >> source code I'm downloading is under a Category A license?
> > >>
> > >>
> > >> 2- If I then want to use NetBeans to edit/build Java code, apparently
> > >> (as a new user) I need this nb-javac module from somewhere else which
> > >> lets NetBeans the product do "useful stuff" with Oracle's current
> Java,
> > >> correct?
> > >>
> > >> Java developers today would understand that Oracle's Java platform -
> > >> which is widely known and used - has GPL related code in it, so they
> > >> should not be surprised when they have to go download nb-javac from
> > >> Oracle, nor should they be surprised when the sources for nb-javac are
> > >> also licensed under the GPL.  Does that make sense?
> > >>
> > >>
> > >> 3- Java developers who want 

Re: Optional modules with GPL dependencies (was: What to include/exclude in code donation to Apache)

[John McDonnell]

HI,

To me Netbeans has always been first and foremost a Java IDE.  This move now 
seems to be making Java an optional extra to Netbeans that means I need to head 
off somewhere else to get this nb-javac module.

Now I was probably wrong in always thinking that NB is a Java IDE first and 
foremost, as when I go to the Downloads[1] page 3 of the 6 download-able 
packages don’t contain Java.

Is it worth getting download numbers for each of the 5 packages and seeing what 
% of user base this change would effect currently?

Will this additional download drive Java Developers away from Netbeans?  

Regards

John


[1]: https://netbeans.org/downloads/ 

> On 7 Nov 2016, at 15:27, Geertjan Wielenga  
> wrote:
> 
> On Mon, Nov 7, 2016 at 2:58 PM, Shan Curcuru wrote:
> 
> 
>> As a non-regular NetBeans user, I have a clarifying question from a
>> *newcomers* perspective that I think will help on the "ASF code means no
>> licensing surprises" side.
> 
> 
> 1- Yes. Assuming we resolve other issues that are going to be coming up,
> i.e., nb-javac is the current hurdle we're focusing on, though there are
> smaller ones to follow unrelated to this specific legal issue that we're
> now focused on. [See
> https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+NetBeans+Structure
> to predict upcoming legal discussions.]
> 
> 2- Yes.
> 
> 3- Yes.
> 
> 4- Yes.
> 
> Thanks, and I agree, what we're doing is in sync with the "ASF code means
> no licensing surprises" side.
> 
> Gj
> 
> On Mon, Nov 7, 2016 at 2:58 PM, Shane Curcuru  wrote:
> 
>> On 2016-11-06 15:01 (-0500), Geertjan Wielenga
>>  wrote: > 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.
>> ...snip...
>> 
>> As a non-regular NetBeans user, I have a clarifying question from a
>> *newcomers* perspective that I think will help on the "ASF code means no
>> licensing surprises" side.
>> 
>> 1- If I want a great IDE where I can edit my C, JavaScript, PHP, HTML
>> and other non-Java code, and check it in, build it, etc. - can I
>> download NetBeans (plus perhaps some other modules) where *all* of the
>> source code I'm downloading is under a Category A license?
>> 
>> 
>> 2- If I then want to use NetBeans to edit/build Java code, apparently
>> (as a new user) I need this nb-javac module from somewhere else which
>> lets NetBeans the product do "useful stuff" with Oracle's current Java,
>> correct?
>> 
>> Java developers today would understand that Oracle's Java platform -
>> which is widely known and used - has GPL related code in it, so they
>> should not be surprised when they have to go download nb-javac from
>> Oracle, nor should they be surprised when the sources for nb-javac are
>> also licensed under the GPL.  Does that make sense?
>> 
>> 
>> 3- Java developers who want to use NetBeans + nb-javac to build their
>> own Apache-licensed Java programs for redistribution would never need to
>> worry about the GPL, because it would be clear as a Java programmer and
>> regular IDE user that the license of the IDE I'm using to write/build my
>> code doesn't affect the license I can use on the code I'm writing in
>> that IDE.  Correct?
>> 
>> 
>> If all three of those are "Yes", then I'm +1 for this solution and +1
>> for LEGAL-279.  The separation between Apache licensed Netbeans as an
>> IDE and the underlying tooling integration with the Java compiler
>> tooling using GPL seems clear, and given any experienced Java developer,
>> they would not be surprised to see the licensing difference.
>> 
>> 
>> 4- If I want to extend the editing features in NetBeans for Java code
>> (which I think you call "Java cluster"?), can I use the Apache license
>> for patches and redistribution of the NetBeans editor code that displays
>> the UI, syntax coloring, etc. elements?  I.e. is the editor portion
>> going to be all Apache, and it's just the compiler (when tooling
>> integration sends code off to do bytecode) that is under GPL?
>> 
>> - Shane
>> 

Re: Optional modules with GPL dependencies (was: What to include/exclude in code donation to Apache)

[Geertjan Wielenga]

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  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 

Re: Optional modules with GPL dependencies (was: What to include/exclude in code donation to Apache)

[Ate Douma]

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  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 

Re: Optional modules with GPL dependencies (was: What to include/exclude in code donation to Apache)

[Wade Chandler]

On Nov 6, 2016 5:31 AM, "Neil C Smith" 
wrote:
>
> On 6 November 2016 at 02:16, Niclas Hedhman  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)

[Wade Chandler]

On Nov 6, 2016 5:26 AM, "Neil C Smith" 
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)

[Wade Chandler]

On Nov 6, 2016 3:59 AM, "Niclas Hedhman"  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)

[Wade Chandler]

On Nov 6, 2016 5:26 AM, "Neil C Smith" 
wrote:
>
> Hi,
>
> On 5 November 2016 at 19:20, Wade Chandler 
wrote:
> > On Nov 5, 2016 2:00 PM, "Neil C Smith" 
> > 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)

[Sven Reimers]

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  wrote:

> Hi,
>
> On 5 November 2016 at 19:20, Wade Chandler 
> wrote:
> > On Nov 5, 2016 2:00 PM, "Neil C Smith" 
> > 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)

[Neil C Smith]

On 6 November 2016 at 02:16, Niclas Hedhman  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)

[Neil C Smith]

Hi,

On 5 November 2016 at 19:20, Wade Chandler  wrote:
> On Nov 5, 2016 2:00 PM, "Neil C Smith" 
> 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)

[Wade Chandler]

On Nov 5, 2016 2:00 PM, "Neil C Smith" 
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 
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)

[Emilian Bold]

> 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 
wrote:

> Hi,
>
> Is top-posting or inline replying the norm here?  Anyway, replies below :-)
>
> >> On Nov 5, 2016, at 12:22, Wade Chandler 
> 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 
> 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)

[Wade Chandler]

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  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)

[Wade Chandler]

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

Re: Optional modules with GPL dependencies (was: What to include/exclude in code donation to Apache)

[Wade Chandler]

On Nov 5, 2016 1:53 AM, "Niclas Hedhman"  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)

[Wade Chandler]

On Nov 4, 2016 11:27 AM, "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.
>
> 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

Re: Optional modules with GPL dependencies (was: What to include/exclude in code donation to Apache)

[Geertjan Wielenga]

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)

[Niclas Hedhman]

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.wiele...@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 <
> bdelacre...@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  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)

[Jan Lahoda]

On Fri, Nov 4, 2016 at 4:59 PM, Geertjan Wielenga <
geertjan.wiele...@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 <
> bdelacre...@apache.org>
> wrote:
>
> > On Fri, Nov 4, 2016 at 4:41 PM, Geertjan Wielenga
> >  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)

[Geertjan Wielenga]

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 
wrote:

> On Fri, Nov 4, 2016 at 4:41 PM, Geertjan Wielenga
>  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)

[Bertrand Delacretaz]

On Fri, Nov 4, 2016 at 4:41 PM, Geertjan Wielenga
 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)

[Geertjan Wielenga]

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 
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  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
>