You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Art Cannon <kl...@embarqmail.com> on 2010/02/03 20:11:01 UTC
apr-util - "missing" file is GPL licensed
Please forgive me if I've reached the wrong list. I apologize. Feel free to point me in the proper direction.
I'm curious. There is a GPL licensed file in apr-util.
Why is xml/expat/conftools/missing present? It's licensed under the GPL. Does that cause apr-util to be licensed under the GPL?
Art Cannon
klx3h@embarqmail.com
Re: apr-util - "missing" file is GPL licensed
Posted by Rainer Jung <ra...@kippdata.de>.
On 05.02.2010 02:15, Graham Leggett wrote:
> On 04 Feb 2010, at 6:27 PM, Nick Kew wrote:
>
>> Since noone else has replied yet, I'll Cc: this to legal.
>>
>> This appears to be part of expat, which APR merely bundles.
>> Your primary port of call should presumably be the expat
>> developers. Having said that, it is indeed included in
>> APR distributions from Apache, so it looks like an issue
>> for us. I don't know if it comes under any of the FSF's
>> exceptions for the core toolchain (as in, compiling with
>> gcc and linking glibc doesn't bring you under GPL).
>>
>> From an APR point of view, I've long argued that we should
>> stop bundling third-party libraries that would be better
>> treated as dependencies. We may now have yet another reason
>> to do so!
>>
>> FWIW, it should also be straightforward to remove the file
>> and (at worst) substitute stubs for anything that's required.
>> The worst it'll do is make the build less robust against
>> an incomplete toolchain.
>
> Isn't "missing" part of automake?
>
> I suspect "missing" is subject to the license exceptions that allow
> automake to be used on non-GPL code. This might be a bug in automake
> itself (incorrect license conditions being embedded in files).
The version contained in apr-util expat is old and doesn't contain the
exception. Recent versions of the file "missing", e.g. the one
distributes with automake-1.10.2 does contain the addition
# 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.
in the file header.
Regards,
Rainer
Re: apr-util - "missing" file is GPL licensed
Posted by Graham Leggett <mi...@sharp.fm>.
On 04 Feb 2010, at 6:27 PM, Nick Kew wrote:
> Since noone else has replied yet, I'll Cc: this to legal.
>
> This appears to be part of expat, which APR merely bundles.
> Your primary port of call should presumably be the expat
> developers. Having said that, it is indeed included in
> APR distributions from Apache, so it looks like an issue
> for us. I don't know if it comes under any of the FSF's
> exceptions for the core toolchain (as in, compiling with
> gcc and linking glibc doesn't bring you under GPL).
>
> From an APR point of view, I've long argued that we should
> stop bundling third-party libraries that would be better
> treated as dependencies. We may now have yet another reason
> to do so!
>
> FWIW, it should also be straightforward to remove the file
> and (at worst) substitute stubs for anything that's required.
> The worst it'll do is make the build less robust against
> an incomplete toolchain.
Isn't "missing" part of automake?
I suspect "missing" is subject to the license exceptions that allow
automake to be used on non-GPL code. This might be a bug in automake
itself (incorrect license conditions being embedded in files).
Regards,
Graham
--
Re: apr-util - "missing" file is GPL licensed
Posted by "C. Bergström" <co...@osunix.org>.
William A. Rowe Jr. wrote:
> On 2/4/2010 5:58 PM, Nick Kew wrote:
>
>> On 4 Feb 2010, at 21:03, Tollef Fog Heen wrote:
>>
>>
>>> ]] Nick Kew
>>>
>>> | I don't know if it comes under any of the FSF's exceptions for the
>>> | core toolchain (as in, compiling with gcc and linking glibc doesn't
>>> | bring you under GPL).
>>>
>>> It's a shell script. It's hardly linked into expat or apr-util and
>>> there's no way it can make the generated binaries fall under the GPL.
>>>
>> Yes, I know it's a shell script.
>>
>> The point is, we *are* distributing it!
>>
>
> We aren't disagreeing; that is the point of the RAT tool, to catch things
> like this which we weren't paying attention to, once they had been checked
> out of subversion *and then* packaged for release. It would be great for
> that tool to be more widely used by existing projects, not simply the
> incubating ones :)
>
> And yes, it makes a great argument against autocrap at the ASF;
lol.. +1
The problem I see with this though is that GNU Make tends to be an easy
defacto standard to depend on when creating a portable replacement for
auto*. Which imho really more or less defeats the purpose of caring at
all. (I'm not saying don't care, but to keep it in perspective..)
./C
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: apr-util - "missing" file is GPL licensed
Posted by "C. Bergström" <co...@osunix.org>.
William A. Rowe Jr. wrote:
> On 2/4/2010 5:58 PM, Nick Kew wrote:
>
>> On 4 Feb 2010, at 21:03, Tollef Fog Heen wrote:
>>
>>
>>> ]] Nick Kew
>>>
>>> | I don't know if it comes under any of the FSF's exceptions for the
>>> | core toolchain (as in, compiling with gcc and linking glibc doesn't
>>> | bring you under GPL).
>>>
>>> It's a shell script. It's hardly linked into expat or apr-util and
>>> there's no way it can make the generated binaries fall under the GPL.
>>>
>> Yes, I know it's a shell script.
>>
>> The point is, we *are* distributing it!
>>
>
> We aren't disagreeing; that is the point of the RAT tool, to catch things
> like this which we weren't paying attention to, once they had been checked
> out of subversion *and then* packaged for release. It would be great for
> that tool to be more widely used by existing projects, not simply the
> incubating ones :)
>
> And yes, it makes a great argument against autocrap at the ASF;
lol.. +1
The problem I see with this though is that GNU Make tends to be an easy
defacto standard to depend on when creating a portable replacement for
auto*. Which imho really more or less defeats the purpose of caring at
all. (I'm not saying don't care, but to keep it in perspective..)
./C
Re: apr-util - "missing" file is GPL licensed
Posted by "William A. Rowe Jr." <wr...@apache.org>.
On 2/4/2010 5:58 PM, Nick Kew wrote:
>
> On 4 Feb 2010, at 21:03, Tollef Fog Heen wrote:
>
>> ]] Nick Kew
>>
>> | I don't know if it comes under any of the FSF's exceptions for the
>> | core toolchain (as in, compiling with gcc and linking glibc doesn't
>> | bring you under GPL).
>>
>> It's a shell script. It's hardly linked into expat or apr-util and
>> there's no way it can make the generated binaries fall under the GPL.
>
> Yes, I know it's a shell script.
>
> The point is, we *are* distributing it!
We aren't disagreeing; that is the point of the RAT tool, to catch things
like this which we weren't paying attention to, once they had been checked
out of subversion *and then* packaged for release. It would be great for
that tool to be more widely used by existing projects, not simply the
incubating ones :)
And yes, it makes a great argument against autocrap at the ASF; it's a
shell script, not compiled 'into' anything else, it did not benefit from
its GPL 'protection' and yet causes nausea for any non-copyleftist who is
still diligent about following all licenses, whether they agree with them
or not.
In this particular case, it was actually checked in a long, long time ago;
http://svn.apache.org/viewvc?view=revision&revision=58140
and should have been averted then, but unfortunately was not. That said,
neither the ASF nor any downstream packager can reasonably be shown to
violate the license of that specific file. If you can come up with such
a scenario, feel free to share it with legal-internal@ for review, and in
the meantime please don't use public forums to raise existing licensing
concerns, but only to discuss the future concerns or provide the list
with the final conclusion of the legal committee's determination.
I fail to see that this is a firedrill, and as was already pointed out,
this entire component will no longer be distributed with the package as
of the next minor version of releases. Lesson learned.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: apr-util - "missing" file is GPL licensed
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Fri, Feb 5, 2010 at 4:45 AM, Sam Ruby <ru...@intertwingly.net> wrote:
> source for any reason" is not likely to fly. So, is the plan to
> remove this file, or is anybody going to propose a palatable (and
> ideally *very* narrow) exception for us to consider?
The file isn't in APR's trunk and hasn't been for a while (as we
removed the expat bundling when we merged APR and APR-util), so this
is largely an artifact of older releases and branches.
However, as Graham speculated, the latest "missing" files distributed
by automake do indeed have the following exception:
# 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.
http://git.savannah.gnu.org/cgit/automake.git/tree/lib/missing?id=v1.11.1
So, at the very least, we can update the "missing" file and be done
with it. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: apr-util - "missing" file is GPL licensed
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Feb 5, 2010 at 6:50 AM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> On 2/4/2010 5:58 PM, Nick Kew wrote:
>>
>> On 4 Feb 2010, at 21:03, Tollef Fog Heen wrote:
>>
>>> ]] Nick Kew
>>>
>>> | I don't know if it comes under any of the FSF's exceptions for the
>>> | core toolchain (as in, compiling with gcc and linking glibc doesn't
>>> | bring you under GPL).
>>>
>>> It's a shell script. It's hardly linked into expat or apr-util and
>>> there's no way it can make the generated binaries fall under the GPL.
>>
>> Yes, I know it's a shell script.
>>
>> The point is, we *are* distributing it!
>
> From what I can see; needlessly so. It's configuration is out-of-sorts
> with the modern autoconf and libtool packages, and since this is for apr,
> we should be able to scope out libtool entirely (apr provides that magic).
> Which leaves a bunch of autoconf work to be done to bring it up to modern
> standards, but would eliminate this artifact in the very next releases.
>
> Working on it, in the meantime I still don't believe there is cause to
> actually panic :)
Yes, there is an exclamation point in Nick's note, but that doesn't
quite meet my personal standard for "panic". Yes, there is a bug that
needs to be fixed.
I'm trying to figure out what the question here is.
Yes, it is legal for us (or anybody) to distribute GPL licensed
artifacts. No, it is not our policy to do so. So either we need to
cease distributing this file, or we need to adjust our policy. An
adjustment to the effect of "any ASF product can distribute any GPL
source for any reason" is not likely to fly. So, is the plan to
remove this file, or is anybody going to propose a palatable (and
ideally *very* narrow) exception for us to consider?
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: apr-util - "missing" file is GPL licensed
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 2/4/2010 5:58 PM, Nick Kew wrote:
>
> On 4 Feb 2010, at 21:03, Tollef Fog Heen wrote:
>
>> ]] Nick Kew
>>
>> | I don't know if it comes under any of the FSF's exceptions for the
>> | core toolchain (as in, compiling with gcc and linking glibc doesn't
>> | bring you under GPL).
>>
>> It's a shell script. It's hardly linked into expat or apr-util and
>> there's no way it can make the generated binaries fall under the GPL.
>
> Yes, I know it's a shell script.
>
> The point is, we *are* distributing it!
>From what I can see; needlessly so. It's configuration is out-of-sorts
with the modern autoconf and libtool packages, and since this is for apr,
we should be able to scope out libtool entirely (apr provides that magic).
Which leaves a bunch of autoconf work to be done to bring it up to modern
standards, but would eliminate this artifact in the very next releases.
Working on it, in the meantime I still don't believe there is cause to
actually panic :)
Re: apr-util - "missing" file is GPL licensed
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 2/4/2010 5:58 PM, Nick Kew wrote:
>
> On 4 Feb 2010, at 21:03, Tollef Fog Heen wrote:
>
>> ]] Nick Kew
>>
>> | I don't know if it comes under any of the FSF's exceptions for the
>> | core toolchain (as in, compiling with gcc and linking glibc doesn't
>> | bring you under GPL).
>>
>> It's a shell script. It's hardly linked into expat or apr-util and
>> there's no way it can make the generated binaries fall under the GPL.
>
> Yes, I know it's a shell script.
>
> The point is, we *are* distributing it!
>From what I can see; needlessly so. It's configuration is out-of-sorts
with the modern autoconf and libtool packages, and since this is for apr,
we should be able to scope out libtool entirely (apr provides that magic).
Which leaves a bunch of autoconf work to be done to bring it up to modern
standards, but would eliminate this artifact in the very next releases.
Working on it, in the meantime I still don't believe there is cause to
actually panic :)
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: apr-util - "missing" file is GPL licensed
Posted by "William A. Rowe Jr." <wr...@apache.org>.
On 2/4/2010 5:58 PM, Nick Kew wrote:
>
> On 4 Feb 2010, at 21:03, Tollef Fog Heen wrote:
>
>> ]] Nick Kew
>>
>> | I don't know if it comes under any of the FSF's exceptions for the
>> | core toolchain (as in, compiling with gcc and linking glibc doesn't
>> | bring you under GPL).
>>
>> It's a shell script. It's hardly linked into expat or apr-util and
>> there's no way it can make the generated binaries fall under the GPL.
>
> Yes, I know it's a shell script.
>
> The point is, we *are* distributing it!
We aren't disagreeing; that is the point of the RAT tool, to catch things
like this which we weren't paying attention to, once they had been checked
out of subversion *and then* packaged for release. It would be great for
that tool to be more widely used by existing projects, not simply the
incubating ones :)
And yes, it makes a great argument against autocrap at the ASF; it's a
shell script, not compiled 'into' anything else, it did not benefit from
its GPL 'protection' and yet causes nausea for any non-copyleftist who is
still diligent about following all licenses, whether they agree with them
or not.
In this particular case, it was actually checked in a long, long time ago;
http://svn.apache.org/viewvc?view=revision&revision=58140
and should have been averted then, but unfortunately was not. That said,
neither the ASF nor any downstream packager can reasonably be shown to
violate the license of that specific file. If you can come up with such
a scenario, feel free to share it with legal-internal@ for review, and in
the meantime please don't use public forums to raise existing licensing
concerns, but only to discuss the future concerns or provide the list
with the final conclusion of the legal committee's determination.
I fail to see that this is a firedrill, and as was already pointed out,
this entire component will no longer be distributed with the package as
of the next minor version of releases. Lesson learned.
Bill
Re: apr-util - "missing" file is GPL licensed
Posted by Nick Kew <ni...@webthing.com>.
On 4 Feb 2010, at 21:03, Tollef Fog Heen wrote:
> ]] Nick Kew
>
> | I don't know if it comes under any of the FSF's exceptions for the
> | core toolchain (as in, compiling with gcc and linking glibc doesn't
> | bring you under GPL).
>
> It's a shell script. It's hardly linked into expat or apr-util and
> there's no way it can make the generated binaries fall under the GPL.
Yes, I know it's a shell script.
The point is, we *are* distributing it!
--
Nick Kew
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: apr-util - "missing" file is GPL licensed
Posted by Nick Kew <ni...@webthing.com>.
On 4 Feb 2010, at 21:03, Tollef Fog Heen wrote:
> ]] Nick Kew
>
> | I don't know if it comes under any of the FSF's exceptions for the
> | core toolchain (as in, compiling with gcc and linking glibc doesn't
> | bring you under GPL).
>
> It's a shell script. It's hardly linked into expat or apr-util and
> there's no way it can make the generated binaries fall under the GPL.
Yes, I know it's a shell script.
The point is, we *are* distributing it!
--
Nick Kew
Re: apr-util - "missing" file is GPL licensed
Posted by Tollef Fog Heen <tf...@err.no>.
]] Nick Kew
| I don't know if it comes under any of the FSF's exceptions for the
| core toolchain (as in, compiling with gcc and linking glibc doesn't
| bring you under GPL).
It's a shell script. It's hardly linked into expat or apr-util and
there's no way it can make the generated binaries fall under the GPL.
Its purpose is:
Handle \`PROGRAM [ARGUMENT]...' for when PROGRAM is missing, or return
an error status if there is no known handling for PROGRAM.
it does this for:
Supported PROGRAM values:
aclocal touch file \`aclocal.m4'
autoconf touch file \`configure'
autoheader touch file \`config.h.in'
automake touch all \`Makefile.in' files
bison create \`y.tab.[ch]', if possible, from existing .[ch]
flex create \`lex.yy.c', if possible, from existing .c
lex create \`lex.yy.c', if possible, from existing .c
makeinfo touch the output file
yacc create \`y.tab.[ch]', if possible, from existing .[ch]
It's part of the suite of scripts automake installs in the source
directory.
| From an APR point of view, I've long argued that we should
| stop bundling third-party libraries that would be better
| treated as dependencies. We may now have yet another reason
| to do so!
This is something I can agree with, but not for licencing reasons.
| FWIW, it should also be straightforward to remove the file
| and (at worst) substitute stubs for anything that's required.
| The worst it'll do is make the build less robust against
| an incomplete toolchain.
Indeed.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: apr-util - "missing" file is GPL licensed
Posted by Nick Kew <ni...@apache.org>.
On Wed, 3 Feb 2010 14:11:01 -0500 (EST)
Art Cannon <kl...@embarqmail.com> wrote:
> Please forgive me if I've reached the wrong list. I apologize. Feel free to point me in the proper direction.
>
> I'm curious. There is a GPL licensed file in apr-util.
>
> Why is xml/expat/conftools/missing present? It's licensed under the GPL. Does that cause apr-util to be licensed under the GPL?
Since noone else has replied yet, I'll Cc: this to legal.
This appears to be part of expat, which APR merely bundles.
Your primary port of call should presumably be the expat
developers. Having said that, it is indeed included in
APR distributions from Apache, so it looks like an issue
for us. I don't know if it comes under any of the FSF's
exceptions for the core toolchain (as in, compiling with
gcc and linking glibc doesn't bring you under GPL).
From an APR point of view, I've long argued that we should
stop bundling third-party libraries that would be better
treated as dependencies. We may now have yet another reason
to do so!
FWIW, it should also be straightforward to remove the file
and (at worst) substitute stubs for anything that's required.
The worst it'll do is make the build less robust against
an incomplete toolchain.
--
Nick Kew