Hi everyone, RMS and I have been looking at some of the GNU programs that are still on old licenses with exceptions, and figuring out whether and how they should be updated. We had some unique ideas about some of the support scripts that a lot of GNU packages use, and we wanted to check with you to see if there's some "gotcha" that we're missing.
First, the scripts we're talking about are: * compile * depcomp * elisp-comp * mdate-sh * missing * py-compile * symlink-tree * ylwrap All these programs currently have an exception to the effect of: # As a special exception to the GNU General Public License, if you # distribute this file as part of a program that contains a # configuration script generated by Autoconf, you may include it under # the same distribution terms that you use for the rest of that program. After reviewing the intended uses of these scripts, and their licensing history, we believe that an exception is not really necessary to allow proprietary software developers to use the scripts in the ways we expect them to. Thus, to keep our licensing as simple as possible, we think that the best thing to do for these scripts would be to remove their exceptions entirely -- and then upgrade them to GPLv3 while we're at it. We understand that in the past, some proprietary software developers have had concerns that they would not be able to use these scripts in the usual way as part of their compilation processes without some kind of exception. We believe these developers are mistaken, but we don't want to cause them any undue concern. So while we'd still like to remove the exception, we think it would be appropriate to provide documentation explaining our position that even without it, proprietary software developers can still use these scripts. If we can keep it short enough, that statement might even appear in the headers, in place of the exception. That would still be better for us because we wouldn't have to worry quite *as* much about making sure the language was legally precise, etc. We think that this plan would simplify the licensing of these scripts without creating major policy changes in how they're used, or worrying proprietary software developers who are inclined to believe they need some sort of special permission to use the scripts in their intended way. But if you think we're wrong about that, definitely let us know -- if we've overlooked or misunderstood something, we'd like to hear about it so we can change course accordingly. I look forward to hearing from you on this. Thanks, -- Brett Smith License Compliance Engineer, Free Software Foundation Support the FSF by becoming an Associate Member: http://fsf.org/jf
