Craig Southeren wrote:
>
> On Monday, 8 February 1999 19:46, Lutz Behnke [SMTP:[EMAIL PROTECTED]] wrote:
>
> > > As much as the existing configuration system is a pain, please realise
> > > that not everyone uses Unix and Perl, and that not everyone likes the
> > > restrictions of the GPL.
> >
> > (sorry to hear that B-( )
> > >
> > > IMHO, the a large part of the success of OpenSSL lies in the fact that
> > > is *can* be used in commercial products in lieu of proprietary solutions.
> > >
> > > Please don't compromise this.
> >
> > I do not see any problem with this by using the GNU tools to work this.
> > GPL specificly does _not_ apply to 'documents' created with them.
> > That is why you can create proprietary products using the gcc.
>
> In a general sense, the GPL can apply to anything. Obviously gcc does not
>automatically apply the GPL to code that is compiled using itself.
>
> But there is no reason why it couldn't - in fact it has always suprised my that
>Stallman didn't apply that restriction to gcc.
For the same reason that he put the glibc and some other libraries under
the Lesser GPL: exposure.
The newly developed GNU system could only compete with the UNIX variants
of the time if it was better
in performance and stability. The full statement by him is on the web
site and was in a recent
article on gnu.announce
>
> In any case, if all of the files produced by autoconf are GPL-free then there isn't
>a problem as far as the license is concerned.
quoting from the Automake manual:
21 Distributing `Makefile.in's
Automake places no restrictions on the distribution of the
resulting `Makefile.in's.
We still encourage software authors to distribute their work
under terms like
those of the GPL, but doing so is not required to use Automake.
Some of the files that can be automatically installed via the
--add-missing switch
do fall under the GPL; examine each file to see.
>
> > Due to the underlying license from Eric and Tim we cannot change the
> > license. But we can use Autoconf and Libtool all we want without
> > restricting the license of the library. It those tools that you cannot
> > include in your proprietary software. That is why the distribution
> > needs to include the 'configure' and not just configure.in and autoconf.
> >
> > But all you have to do is install the needed tools, that in no shape
> > or form limit you use with proprietary software, with one small
> > exception:
> > you cannot link or otherwise _include_ GPLed stuff in you program.
>
> Note that the GPL can just as easily apply to perl scripts or shell scripts as well
>as C code.
Umm, yes. And the point is? since the library is explicitly exlcuded
from being put under the GPL
all derivative works may not be put under GPL either. And even I would
like to do so, I would
advise agains making things even more complex by putting new parts under
license differing from
the old stuff.
>
> And does autoconf run under Windows yet? Does anybody know?
As far as I understood from the mozilla build that is exactly what they
are working on, since
the mozilla team has the exact same problem as we have and a somewhat
bigger code base.
They decided that those who want to build mozilla may be asked to
install the cygwin tools
and use the bash/automake/autoconf suite. The nessecary m4 macros for VC
support are being written.
<philosophy/political>
IMHO may those that want to use a piece of open source be asked to adopt
the build strategy of
the community that produced it. All those that are _able_ to make use of
uncompiled library source
should be able to install cygwin32.
This is advantage for all, since the 'sufficient eyes make problems
trivial' approach only works in
large numbers. So we should use the same basic configure/make mechanism
as mozilla and an endless
list of GNU tools.
</philosophy/political>
(Why should you listen to this? What merit do I have with regards to
OpenSSL? none yet!)
mfg lutz
--
*******************************************************************
Lutz Behnke Tel.: 040 / 766 29 1423
TC TrustCenter for Security Fax.: 040 / 766 29 577
in Data Networks GmbH email: [EMAIL PROTECTED]
Am Werder 1
21073 Hamburg, Germany
S/MIME Cryptographic Signature
