netbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: Optional modules with GPL dependencies (was: What to include/exclude in code donation to Apache)
Date Sun, 06 Nov 2016 15:59:01 GMT
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 <wadechandler@apache.org> wrote:
>> I totally see your point here, but yes, separate from the license
>> discussion. I still think NB has this problem now, so nothing changes
>> there, so what would you do different, right now, even if NB were not going
>> to Apache? This is why I say we have to iterate. It can't all be done at
>> once.
>
> Agreed, this would still be an issue, although less of one while both
> projects have connections within the same company.  And I'm really not
> suggesting that this all be done at once.
>
> But, I really think this relates to the question of licensing, or how
> to handle something that can't be donated to Apache because of code
> licensing.  In particular, Niclas' comments that "This
> is Open SOURCE, not OLB (openly licensed binaries) software.", and
> that ASF would like to see dependency on a regular OpenJDK system.
> nb-javac has similarities to a binary blob, in that its functionality
> can never be entirely maintained on the NetBeans community side -
> there is a similar lack of control.
>
> So, what I would want to see if I was on the Apache side, and I think
> would be good for the NetBeans community, is some commitments from
> Oracle, OpenJDK and ASF / NB on a direction of travel to remove this
> dependency as part of the code donation.  That would include a
> commitment from Oracle / OpenJDK to not break any required internal
> interfaces, provide fixes / updates, even maintain it, as and until
> it's possible to remove nb-javac.  I presume removing it is going to
> require the OpenJDK and NetBeans projects to agree what can be added
> to core javac and what has to be reworked on the NetBeans side.
>
> That all of course relies on the initial dependency / licensing being
> accepted for a least an interim period!
>
> That's pretty much the sum of what's in my head - IMO solving the
> licensing question and the clarification of how to handle the
> resulting technical / development needs cannot be handled usefully in
> isolation - particularly with regards to the realities of this
> particular code.  The agreed solution has to suit both.  I'll shut up
> on that now! :-)
>
> Best wishes,
>
> Neil
>


Mime
View raw message