This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Created attachment 109869 [details] The license text I was being asked to agree to (I hope "installer" is the right product. I couldn't find one for "updater". If not correct, please reassign.) The handling of license agreements when updating Netbeans must be vastly improved. It is completely unreasonable now. I'm running Netbeans 7.0, and was just presented with a huge boat load of updates to install. It looks like pretty much every plugin is being updated. Presumably I'm being upgraded to 7.0.1 or 7.1 or something like that. At the point in the process where I was being asked to agree to the terms of the licenses of these plugins, I was presented with a chunk of verbiage 83000 lines long. EIGHTY THREE THOUSAND LINES!!! 83124, to be precise. I will attach the text. This is completely ridiculous. We must do better! The text has 615567 words. That would take approximately 34 hours to read. *If* you read constantly and without pausing, and ignoring the fact that very quickly you would not be able comprehend or take in any of it any more. It is obvious that this is utterly and completely unreasonable. It leaves me with only two choices: * Don't read the text. I would probably still be bound by the terms, and since I have no idea what they are this is an extremely bad idea. By the way, I wonder whether a judge might not decide that this case is *so* unreasonable that I would not be bound by the terms after all, putting Netbeans in a potentially dangerous position. * Don't install the updates. Neither of which is desirable, and it is too bad that Netbeans puts *everyone* updating from 7.0 in this position. I know that in practice everyone just clicks the checkbox without reading anything, but I hope everyone agrees that that is not desirable or a good reason to keep the status quo. There might be a clause in there saying that I have signed over my house to Larry Ellison. If people have to be made to accept these licenses, then they should be presented to them in a reasonable manner. This needs to be much, much improved. I propose the following: * Each plugin indicates which license it uses from a list of standard licenses (including variations, such as the GPL 2 + classpath exception). I guess there should be a "custom" option too, for plugins wanting to use a non-standard license, but no plugin provided by Netbeans should ever have to use the "custom" option. * The updater should inventory the standard licenses used by all the plugins to be installed, and group the plugins together by license. * The updater should display the list of licenses, each license being in some way expandable to show the plugins that use it, for instance in a tree view. * The user should be able to agree on three levels: per plugin, per license (which would select all plugins using that license) or all plugins. This way it would be much easier to get a quick overview of which licenses you are being asked to agree to, and since you probably already know most if not all of the licences, and you know the plugin is using the standard license text, you will be able to agree to them much more quickly, without having to read the text (although that should still be an option), and without having to do it plugin by plugin.
For an example of my proposal, take a look at Eclipse, which handles it exactly in the manner I describe.
First, this RFE makes sense for me, however there is a big problem too many plugins uses own clone of similar license and it avoids to display all of them in any readable shape. Thu current PM groups all licenses by its text thus one license will display only once but the problem is a little differences between similar licenses, again. It's need to make a clean up in plugins licenses at first. On PM side I see a one of possible enhancements, to do not ask for confirm a license which has been accepted before (e.g. in IDE installer). PM will check if license in update differs in any matter. If so, ask for confirmation, or skip it otherwise.
> On PM side I see a one of possible enhancements, to do not ask for confirm a > license which has been accepted before (e.g. in IDE installer). I don't think you can do that. You have to agree per module; the fact that you have agreed to a license for one module does not mean you necessarily agree to using that license for *all* modules. In other words, you are not agreeing with licenses per se, you are agreeing with the installation of a particular module under the terms of a particular license.
(In reply to comment #0) > This is completely ridiculous. We must do better! The text has 615567 words. > That would take approximately 34 hours to read. *If* you read constantly and > without pausing, and ignoring the fact that very quickly you would not be able > comprehend or take in any of it any more. Btw. an user who install IDE via installer has to read&accept a license with 12505 words.
When the patch from issue 202848 was applied it's much better I could close this as solved. Any objections?
@Jiri: I assume you mean the patch from bug 172599? Bug 202848 is closed as "works for me" and has no patches attached. No, that patch does not resolve the issue at all. The total amount of text you would have to read through does not change, it is just displayed one plugin at a time instead of for all plugins at once. You could even argue it is now slightly more work to read everything, since you have to select each plugin one by one. I think you missed the point of this RFE. The problem is not that it is hard to tell where the license for one plugin ends and the next one begins. The point is that you have to read *all* the text for *every* plugin, which is an unreasonably large amount of text when a lot of plugins are being installed or updated. To solve that problem you have to: a) Indicate when a plugin is using the standard text of a well known license (e.g. "GPL 2" or "BSD" or "GPL 3 with classpath exception"), so that you don't have to read the full text if you already know that the terms of that license are acceptable to you (although you should still have that option of course). b) Group plugins that use the same license together so that you have the option of agreeing to all of them at once, instead of having to inspect each plugin separately to see which license it uses. This patch does neither and does not improve the situation noticeably. If I were encountering the situation I describe at the top again, I would still have to read just as much text, and I would have to do slightly more work to do it.
I realise that it would be a lot of work to clean up (at least) all the standard plugins distributed by Oracle to use standard licenses, but IMHO it's the only reasonable course of action. I can't imagine that it is really the official stance of Oracle that it is reasonable to require me to spend almost a full working week reading license texts when I want to upgrade Netbeans!
Created attachment 116175 [details] Example from Eclipse I have attached a screenshot of how Eclipse actually does it nowadays. The patch from bug 172599 implies to do it the same way that Eclipse does it, but that is no longer true. The Eclipse screenshot on that bug is old and obsolete. As you can see from the screenshot, Eclipse now uses a tree view, not a list or table, and at the top level of the tree are the *licenses*, not the plugins. The plugins are grouped together underneath each license. I didn't expand the top node in the screenshot because it has a huge list of plugins underneath it. This is in fact exactly what I am proposing. It accomplishes both goals: you don't have to read the full license text if you're already familiar with a license, and you don't have to inspect every individual plugin to see which license it uses.
In fact most plugins _do_ use one of a few standard licenses. [1] lists all third-party libraries known to be in the IDE distribution or stable update center (plus some others), with their named license. (NetBeans sources themselves are CDDL-GPL-2-CP.) (In reply to comment #2) > too many plugins uses own clone of similar license This is solved in the generated license summary by permitting the source license (e.g. html.validation/external/jing-license.txt) to include minor variants (e.g. "Neither the name of the Thai Open Source Software Center Ltd nor") while naming a well-known license (here nbbuild/licenses/BSD) which includes placeholders (here __COPYRIGHT_OWNER__); the validation [2] checks for deviations from the official text other than at the explicitly permitted points. Unfortunately the metadata visible to PM (org-netbeans-modules-html-validation.nbm!/Info/info.xml) loses most of these distinctions, and the DTDs in fact have no room for expressing details. Ideally you could generate something like <module ...> <license name="CDDL-GPL-2-CP" files="config/Modules/org-netbeans-modules-html-validation.xml,modules/org-netbeans-modules-html-validation.jar"> COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version 1.0 1. Definitions. .... </license> <license name="BSD" files="modules/ext/iri.jar,modules/ext/jing.jar"> Copyright (c) __YEAR__, __OWNER__ Redistribution and use in source and binary forms, with or without .... </license> .... </module> A cruder option would be to leave info.xml in its current format, but in PM to parse out its sections ("Additional license (jing-license.txt) associated with the following files:") and match the bodies against a set of well-known license templates, which would then need to be packaged in the IDE. This is more fragile and less modular however. It would be nice if someone else dealt with this mess - CC REL [3], OSI [4], Maven [5] - but there is no system used by the authors of our third-party libs consistently enough to be useful. [1] http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/lastStableBuild/artifact/nbbuild/build/generated/external-libraries.txt [2] http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/lastStableBuild/artifact/nbbuild/build/verifylibsandlicenses.xml [3] http://wiki.creativecommons.org/CC_REL [4] http://opensource.org/licenses/alphabetical [5] http://maven.apache.org/pom.html#Licenses
By the way DevFaqExternalLibraries [6] may be of interest. [6] http://wiki.netbeans.org/DevFaqExternalLibraries