Re: License of m4/ltoptions.m4
Paul Eggert wrote: Gary V. Vaughan [EMAIL PROTECTED] writes: Now for the note to the FSF that explains why we need it... here is a first cut to get the ball rolling: That looks fine to me. Thanks. Okay, there have been no corrections or objections in the last 24 hours... Where do we send it? Direct to rms? Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: License of m4/ltoptions.m4
Hello, On Fri, Nov 12, 2004 at 10:25:32AM +, Gary V. Vaughan wrote: Where do we send it? Direct to rms? I'd say assign or copyright-clerk are better (at gnu.org, of course). Stepan
Re: License of m4/ltoptions.m4
Now for the note to the FSF that explains why we need it... here is a first cut to get the ball rolling: Autoconf, Automake and Libtool have long distributed m4 macro files that are needed to generate the familiar configure script. In the spirit of giving our users all the same rights that we developers have, our intention has always been to allow our users to distribute these m4 macros with their packages so that *their* users can regenerate the configure script if, say, they want to make a patch to get things to work on a platform that the package maintainer didn't have access to. For this purpose, all 3 autotools have historically had an exception to the GPL in those source files containing m4 macros used to generate a package configuration script, but unfortunately we have used different wordings and in a few cases forgotten to add the exception clause to a macro source file. We would jointly like to standardise on the wording of the exception clause, and add it into the few files that are currently missing it. As the copyright holder of these tools, our questions to you are: i) Is it okay for us to change the wording of the licenses in our m4 macro source files, and in some cases add in the missing exception clause, to clarify the spirit in which they have been distributed all along? ii) Is the following wording sufficiently clear from a legal point of view? Alexandre Duret-Lutz wrote: Paul == Paul Eggert [EMAIL PROTECTED] writes: [...] Paul As a special exception to the GNU General Public License, Paul if you distribute this file as part of a package that Paul automatically derives from this file a configuration Paul script (and perhaps some associated intermediate files), Paul then you may distribute this file and the derived files Paul for that purpose, under the same terms that you use for Paul the rest of the package. [...] President Eggert, you have my vote! Seconded :-) Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: License of m4/ltoptions.m4
On Wed, 2004-11-10 at 14:57 -0800, Paul Eggert wrote: As a special exception to the GNU General Public License, if you distribute this file as part of a package that automatically derives from this file a configuration script (and perhaps some associated intermediate files), then you may distribute this file and the derived files for that purpose, under the same terms that you use for the rest of the package. Has my vote. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: License of m4/ltoptions.m4
Scott James Remnant wrote: On Wed, 2004-11-10 at 14:57 -0800, Paul Eggert wrote: As a special exception to the GNU General Public License, if you distribute this file as part of a package that automatically derives from this file a configuration script (and perhaps some associated intermediate files), then you may distribute this file and the derived files for that purpose, under the same terms that you use for the rest of the package. Has my vote. My public domain comment notwithstanding, anything approximately close to the desired verbiage is close enough. I'd guess that no matter what you start with, it will change after lawyers have their say. Therefore, this is a reasonable enough approximation. :)
Re: License of m4/ltoptions.m4
Paul == Paul Eggert [EMAIL PROTECTED] writes: [...] Paul Would you use the exact same wording in #2 that you Paul already uses in the aux scripts? Does that wording still Paul apply? I think so. Another idea would be to use a bison-like exception just to match the license of aclocal.m4: As a special exception to the GNU General Public License, when this file is copied by aclocal into an aclocal output file, you may use that output file without restriction. However this seems quite restrictive too me, as it wouldn't work if the file were m4_included (we don't do that for Automake macros anyway, but is that a reason to disallow it?) -- Alexandre Duret-Lutz
Re: License of m4/ltoptions.m4
Alexandre Duret-Lutz wrote: Paul == Paul Eggert [EMAIL PROTECTED] writes: [...] Paul Would you use the exact same wording in #2 that you Paul already uses in the aux scripts? Does that wording still Paul apply? I think so. Another idea would be to use a bison-like exception just to match the license of aclocal.m4: As a special exception to the GNU General Public License, when this file is copied by aclocal into an aclocal output file, you may use that output file without restriction. However this seems quite restrictive too me, as it wouldn't work if the file were m4_included (we don't do that for Automake macros anyway, but is that a reason to disallow it?) Maybe: As a special exception to the GNU General Public License, when this file is used as input for parts of GNU Autoconf, GNU Automake or GNU Libtool, then you may use the resulting output file without restriction. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: License of m4/ltoptions.m4
On second thoughts, why not take this opportunity to unify the license exception between libtool and automake so we can share code more easily? Gary V. Vaughan wrote: Alexandre Duret-Lutz wrote: Paul == Paul Eggert [EMAIL PROTECTED] writes: [...] Paul Would you use the exact same wording in #2 that you Paul already uses in the aux scripts? Does that wording still Paul apply? I think so. Another idea would be to use a bison-like exception just to match the license of aclocal.m4: As a special exception to the GNU General Public License, when this file is copied by aclocal into an aclocal output file, you may use that output file without restriction. However this seems quite restrictive too me, as it wouldn't work if the file were m4_included (we don't do that for Automake macros anyway, but is that a reason to disallow it?) Maybe: As a special exception to the GNU General Public License, when this file is used as input for parts of GNU Autoconf, GNU Automake or GNU Libtool, then you may use the resulting output file without restriction. Instead: As a special exception to the GNU General Public License, if you distribute this file as part of a package that uses it as input for parts of GNU Autoconf, GNU Automake or GNU Libtool, then you may include it under the same distribution terms that you use for the rest of that package. However, even though our intentions are good, and we are merely clarifying the existing spirit of the exception clauses we have used all along, is it okay to just edit the license of existing files without explicit permission from the authors? Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: License of m4/ltoptions.m4
Paul Eggert wrote: Gary V. Vaughan [EMAIL PROTECTED] writes: However, even though our intentions are good, and we are merely clarifying the existing spirit of the exception clauses we have used all along, is it okay to just edit the license of existing files without explicit permission from the authors? It's a tricky enough situation that we should probably take it up with the FSF itself. It owns the copyright. Agreed. Why don't we work up a clause that we all like, and draft a note explaining why we need the exception, and then we can forward it to the FSF for consideration... Was anybody unhappy with the exception wording in my last post in the thread? If not we can start from there. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: License of m4/ltoptions.m4
Paul Eggert wrote: Gary V. Vaughan [EMAIL PROTECTED] writes: Was anybody unhappy with the exception wording in my last post in the thread? If not we can start from there. I worry that it's too generous, because it means that if the package uses the .m4 file as input to autoconf, then the package can also use the .m4 file for other, proprietary reasons. Good point. How about this wording instead? As a special exception to the GNU General Public License, if you distribute this file as part of a package that uses the file as input to GNU Autoconf, GNU Automake, or GNU Libtool, then you may distribute the resulting output files under the same terms that you use for the rest of the package. That limits non-GPL licensed packages to an aclocal.m4 based distribution method, rather than shipping the files and m4_including them with automake-1.8 and higher :-( Also, I'm not sure whether `input to GNU Automake' is good legalese for `feed it to aclocal'? Here's another: As a special exception to the GNU General Public License, if you distribute this file as part of a package that uses the file as input to programs that are shipped as part of GNU Autoconf, GNU Automake, or GNU Libtool, then you may distribute this file for that purpose under the same terms that you use for the rest of the package. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: License of m4/ltoptions.m4
Gary V. Vaughan wrote: Here's another: And another: ``The following specific files are hereby deemed public domain and you may use them any way you see fit.'' After all, these things are only useful with the Auto* tools and I do not believe that any of them are state secrets, so why spend a lot of effort guarding against something that isn't very likely to happen and wouldn't really matter if it did happen. Yes? :-)
Re: License of m4/ltoptions.m4
Paul == Paul Eggert [EMAIL PROTECTED] writes: [...] Paul As a special exception to the GNU General Public License, if you Paul distribute this file as part of a package that uses the file as input Paul to GNU Autoconf, GNU Automake, or GNU Libtool, then you may distribute Paul the resulting output files under the same terms that you use for the Paul rest of the package. I don't understand the intent of as input to GNU Autoconf, GNU Automake, or GNU Libtool. AFAICT Libtool does not input m4 files, only the Autoconf tools and aclocal do. I assume input to GNU Automake means read by aclocal to produce aclocal.m4. If so this text seems to imply that you can distribute aclocal.m4 (with an embedded copy of python.m4) under your licensing term only if you also distribute python.m4 (which is under GPL). But there is another case which I'd like to support: the case where python.m4 is distributed aside to aclocal.m4, and aclocal.m4 simply does m4_include([m4/python.m4]). Then python.m4 is not a resulting output file of aclocal. And still we'd like to relax the GPL. As a special exception to the GNU General Public License, if you distribute this file as part of a package that uses the file (or any derived output) as input to generate its configuration script with Autoconf, then you may distribute the file and resulting output files under the same terms that you use for the rest of the package. configuration script generated by Autoconf is what the aux scripts already use. or any derived output is a lame attempt to allow tools such as aclocal (without singling out aclocal) to preprocess the file, as long as the intent is to build a configure script. -- Alexandre Duret-Lutz
Re: License of m4/ltoptions.m4
Alexandre Duret-Lutz wrote: Paul == Paul Eggert [EMAIL PROTECTED] writes: [...] Paul As a special exception to the GNU General Public License, if you Paul distribute this file as part of a package that uses the file as input Paul to GNU Autoconf, GNU Automake, or GNU Libtool, then you may distribute Paul the resulting output files under the same terms that you use for the Paul rest of the package. I don't understand the intent of as input to GNU Autoconf, GNU Automake, or GNU Libtool. AFAICT Libtool does not input m4 files, only the Autoconf tools and aclocal do. Just trying to cover all bases to avoid more pain for future autotools versions. Note that libtoolize does actually read through aclocal.m4 and any files it m4_includes to find a few directory paths and decide whether to copy particular files. We might extend that functionality in future. The use of GNU Autoconf is to prevent someone creating their own tool and calling that Autoconf to circumvent the license. [[...]] As a special exception to the GNU General Public License, if you distribute this file as part of a package that uses the file (or any derived output) as input to generate its configuration script with Autoconf, then you may distribute the file and resulting output files under the same terms that you use for the rest of the package. configuration script generated by Autoconf is what the aux scripts already use. or any derived output is a lame attempt to allow tools such as aclocal (without singling out aclocal) to preprocess the file, as long as the intent is to build a configure script. I prefer my wording :-) Bruce's would be kinda cool too. But frankly, I'd be flabbergasted is the FSF bought that :-( Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: License of m4/ltoptions.m4
Gary == Gary V Vaughan [EMAIL PROTECTED] writes: Gary Alexandre Duret-Lutz wrote: [...] I don't understand the intent of as input to GNU Autoconf, GNU Automake, or GNU Libtool. AFAICT Libtool does not input m4 files, only the Autoconf tools and aclocal do. Gary Just trying to cover all bases to avoid more pain for future autotools Gary versions. Note that libtoolize does actually read through aclocal.m4 Gary and any files it m4_includes to find a few directory paths and decide Gary whether to copy particular files. But none of the path you are looking for are specified in user files, not those we are considering. Also that argument would apply to Gettext as well, and maybe several other tools. We cannot list all of them and should not discriminate some of them. Gary The use of GNU Autoconf is to prevent someone creating their Gary own tool and calling that Autoconf to circumvent the license. I don't have a problem with GNU Autoconf, only GNU Libtool :) (And to some extent with GNU Automake too, but I can understand it in some way.) -- Alexandre Duret-Lutz
Re: License of m4/ltoptions.m4
Paul == Paul Eggert [EMAIL PROTECTED] writes: [...] Paul As a special exception to the GNU General Public License, Paul if you distribute this file as part of a package that Paul automatically derives from this file a configuration Paul script (and perhaps some associated intermediate files), Paul then you may distribute this file and the derived files Paul for that purpose, under the same terms that you use for Paul the rest of the package. [...] President Eggert, you have my vote! -- Alexandre Duret-Lutz
Re: License of m4/ltoptions.m4
Gary V. Vaughan [EMAIL PROTECTED] writes: However, even though our intentions are good, and we are merely clarifying the existing spirit of the exception clauses we have used all along, is it okay to just edit the license of existing files without explicit permission from the authors? It's a tricky enough situation that we should probably take it up with the FSF itself. It owns the copyright.
Re: License of m4/ltoptions.m4
Gary V. Vaughan [EMAIL PROTECTED] writes: Was anybody unhappy with the exception wording in my last post in the thread? If not we can start from there. I worry that it's too generous, because it means that if the package uses the .m4 file as input to autoconf, then the package can also use the .m4 file for other, proprietary reasons. How about this wording instead? As a special exception to the GNU General Public License, if you distribute this file as part of a package that uses the file as input to GNU Autoconf, GNU Automake, or GNU Libtool, then you may distribute the resulting output files under the same terms that you use for the rest of the package.
Re: License of m4/ltoptions.m4
Alexandre Duret-Lutz [EMAIL PROTECTED] writes: or any derived output is a lame attempt to allow tools such as aclocal (without singling out aclocal) to preprocess the file, as long as the intent is to build a configure script. I like the idea, but how about if we generalize it to allow any configuration-file generator? That simplifies it somewhat. Something like the following, perhaps? It also attempts to incorporate Gary's suggestions. As a special exception to the GNU General Public License, if you distribute this file as part of a package that automatically derives from this file a configuration script (and perhaps some associated intermediate files), then you may distribute this file and the derived files for that purpose, under the same terms that you use for the rest of the package.
Re: License of m4/ltoptions.m4
Hi Ralf, Ralf Wildenhues wrote: Hi Peter, * Peter Ekberg wrote on Tue, Nov 09, 2004 at 01:33:29PM CET: Hello! There is no exception from the GPL in m4/ltoptions.m4, like there is in the other lt*.m4 files in that directory. Is that an oversight or is this file only needed for backwards compatibility or something like that? I based this file on m4/options.m4 in automake and copied the license from there :-( The lack of exception is troubling, maybe the author of the Automake version of the file is willing to let us relicense our fork? If not, we need to reimplement the parts I cribbed from Automake, so that we can license it consistently. Not only this file: also missing the exception are m4/argz.m4 m4/ltversion.m4 (is this short enough so it doesn't need any license?) m4/ltversion.in, and I believe the license is necessary. libltdl/Makefile.am libltdl/configure.ac libltdl/loaders/Makefile.am I wrote all of those, so the missing exception is just an oversight on my part. Please feel free to insert the missing clause. Otherwise I will do so when I have some time. Arguably libltdl/Makefile.am has ancestry from before I joined libtool, but the clause was already present in the libtool license when libltdl was added, so there is no problem in adding the clause back in. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: License of m4/ltoptions.m4
Gary == Gary V Vaughan [EMAIL PROTECTED] writes: Gary Hi Ralf, Gary Ralf Wildenhues wrote: Hi Peter, * Peter Ekberg wrote on Tue, Nov 09, 2004 at 01:33:29PM CET: Hello! There is no exception from the GPL in m4/ltoptions.m4, like there is in the other lt*.m4 files in that directory. Is that an oversight or is this file only needed for backwards compatibility or something like that? Gary I based this file on m4/options.m4 in automake and copied the Gary license from there :-( The lack of exception is troubling, The copyright notices of Automake's m4/*.m4 files were added by Paul on 2001-09-22 (that was after the 1.5 release). It looks like the missing exception to the GPL is an omission nobody noticed so far. Before this change there was no boilerplate, and when the files were concatenated to form aclocal.m4, it was prepended with: | # aclocal.m4 generated automatically by aclocal 1.5 | | # Copyright 1996, 1997, 1998, 1999, 2000, 2001 | # Free Software Foundation, Inc. | # This file is free software; the Free Software Foundation | # gives unlimited permission to copy and/or distribute it, | # with or without modifications, as long as this notice is preserved. | | # This program is distributed in the hope that it will be useful, | # but WITHOUT ANY WARRANTY, to the extent permitted by law; without | # even the implied warranty of MERCHANTABILITY or FITNESS FOR A | # PARTICULAR PURPOSE. Today this copyright notice is still output in aclocal.m4, but it is followed by the copyright notices of all the files included. This sounds confusing since the top says unlimited permission to copy and distribute with or without modifications while the concatenated parts also include each a notice that state GPL. (*) I don't really know what to think about this. Some ideas: 1. prefix all the m4/*.m4 licenses with `##' so aclocal omit them from aclocal.m4 (leaving only the unlimited permission to ... license added by aclocal) 2. add an exception to all the m4/*.m4 files similar to that used in the aux scripts 3. both Now you may also consider what happens when third-party m4 macros (with custom licensing) are intermixed into aclocal.m4. (Seems another good reason to prefer setups with m4_include). (*) Amusingly, Automake's own aclocal.m4 is probably the only aclocal.m4 where there is no such confusion. -- Alexandre Duret-Lutz
Re: License of m4/ltoptions.m4
Alexandre Duret-Lutz [EMAIL PROTECTED] writes: Some ideas: 1. prefix all the m4/*.m4 licenses with `##' so aclocal omit them from aclocal.m4 (leaving only the unlimited permission to ... license added by aclocal) 2. add an exception to all the m4/*.m4 files similar to that used in the aux scripts 3. both #1 and #2 are incompatible, since #2 requires preservation of copyright notices, and #1 discards the copyright notices. So #3 isn't logical. #2 sounds better to me than #1, since it makes the licensing terms clearer. Would you use the exact same wording in #2 that you already uses in the aux scripts? Does that wording still apply?
Re: License of m4/ltoptions.m4
I never paid attention to the wording before (they did make sense in ltdl.c) but the wording of the special exception is not as wonderful as it should be: # 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. The reason why it is not as wonderful as it should be is that it mentions being part of a 'program'. While some components (e.g. libltdl) may become part of a 'program', most are periphery to it and will never become part of a 'program'. Scripts like 'depcomp' are programs in and of themselves but they are human readable so their very existence satisfies GPL. As we know, GPL is designed to place distribution limits on a derived 'program' but not on the source code itself. GPL goes to considerable effort to define the meaning of 'program' and ordinary text files do not fit that definition. Text files and scripts are clearly source code and will remain as source code. This makes the wording of the special exception very confusing when applied to source code. To me 'package' makes much more sense than 'program' for this usage. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
