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 <a...@douma.nu> wrote: > I'm top posting on just the last response in this thread, as I think > the discussion is drifting too much and not adding much value nor new > insights. > And it seems to be building up unnecessary irritations as result. > > Instead I will try to recap and summarize the current state to break out of > the re-re-re-re-... iterations loop :-) > > The main question to be answered is, as I already proposed before: > > Will the Apache NetBeans project be allowed to develop and release > a (or more) optional module, the Java Editor module in casu, under the > ASL 2.0 license at the ASF, which depends on external 3rd party module > nb-javac which is available under the GPL v2 w/ CPE (Category X). > End users willing to use the optional module will be required to provide > the nb-javac module themselves during installation. > > Relevant in this context is what the Apache Legal Policy *guidelines* [1] > says > about the meaning of the word "Optional": > > Optional means that the component is not required for standard use of the > product or for the product to achieve a desirable level of quality. > The question to ask yourself in this situation is: > > "Will the majority of users want to use my product without adding the > optional components?" > > Geertjan and others already clarified and are documenting the modularity of > NetBeans [2], with the core NetBeans platform being the only required part. > All other modules (or clusters) being optional. > So many users might not need the NetBeans Java cluster. > > However is this actually true for a majority of NetBeans users? > Although I'm not a NetBeans user myself, I honestly think a majority > actually > do want and need to use the Java cluster in NetBeans, for development or > education purposes (the latter also often pointed out as a major usage). > > So while formally the Java cluster is optionally I don't think anyone > can claim only a minority will want/need to use it. > IMO this means that the common guideline as described at [1] is *not* > sufficient to answer the above question with yes... > > Hence, we need to get an explicit answer from Apache Legal Affairs > Committee. > > And if *they* decide the answer is no, a different solution will be needed. > > One of the alternatives then might be asking Oracle for a compatible > dual-license of nb-javac. > Or else we need to decide how and where to proceed with the NetBeans Java > cluster development, *outside* the ASF... > > Or maybe the nb-javac fork might be brought back into OpenJDK. > I have no clue how feasible or realistic that would be. > But that, and only that, would change the current dependency on nb-javac > into > a 'platform' dependency, which we can allow by the ASF Legal Policy. > > In the current state, discussing about nb-javac as possible platform or OS > dependency, or even comparing it with the OpenJDK, is useless. > > A platform dependency like Java or even OpenJDK is in general OK because > users > will already have an upfront requirement on such dependencies anyway. > But the nb-javac jar AFAICT is *only* useful/needed *when* users want to > use NetBeans. And serves no other purpose than to enable the usage of > NetBeans. > > I will raise the question as described above by creating a LEGAL issue [3] > for > it later today. And I'll forward the link to that issue here. > This might also lead to follow up discussion in the legal-discuss@ list > [4], so > anyone interested might want to monitor that list or even subscribe it. > > And to keep the current thread relevant and meaningful, I kindly request > others > to start a new thread for additional discussions not specifically > addressing the > above. > > Kind regards, > Ate > > [1] http://www.apache.org/legal/resolved.html#optional > [2] https://cwiki.apache.org/confluence/display/NETBEANS/Overvie > w%3A+NetBeans+Structure > [3] https://issues.apache.org/jira/browse/LEGAL > [4] http://www.apache.org/foundation/mailinglists.html#foundation-legal > > > > On 2016-11-06 16:49, Neil C Smith wrote: > >> On 6 November 2016 at 14:32, Wade Chandler <wadechand...@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 >> >> >
