Raul Miller wrote:
On Sep 9, 2004, at 23:36, Glenn Maynard wrote:
The GPL requires that all derived works be entirely available under the
terms of the GPL.
On Fri, Sep 10, 2004 at 08:35:59AM -0400, Anthony DeRobertis wrote:
Yes, but OpenSSL wouldn't be a derived work of the GPL program
Raul Miller wrote:
On Tue, Sep 21, 2004 at 04:32:17PM -0400, Nathanael Nerode wrote:
Well, then the question is, is that combined program a derived work of
the GPLed program?
If it consists of two pieces: the GPLed program and the OpenSSL library
-- and each exists and is fully functional
On Tue, Sep 21, 2004 at 05:13:47PM -0400, Nathanael Nerode wrote:
Consider bash + script X + glibc -- this is mere aggregation.
This doesn't seem to be an interesting example.
Most scripts are so trivial, that [at least in the u.s.] they fall under
fair use.
I've never seen a bash-specific
On Tue, Sep 21, 2004 at 04:32:17PM -0400, Nathanael Nerode wrote:
Well, then the question is, is that combined program a derived work of the
GPLed program?
If it consists of two pieces: the GPLed program and the OpenSSL library --
and each exists and is fully functional without the other --
Raul Miller [EMAIL PROTECTED] schrieb/wrote:
Raul Miller [EMAIL PROTECTED] schrieb/wrote:
Ok, you're right -- while copyright law makes no specific provisions
about how the copy arrives,...
On Sun, Sep 12, 2004 at 02:27:00PM +0200, Claus Färber wrote:
That's plain wrong. Copyright law
On Sep 10, 2004, at 22:25, Raul Miller wrote:
On Fri, Sep 10, 2004 at 08:36:23PM -0400, Anthony DeRobertis wrote:
Please read the start of this subthread; the point was about
distributing as _source_ and compiling on the user's machine. The
program in source form does not include OpenSSL.
On Sep 11, 2004, at 00:29, Raul Miller wrote:
In that context, there are cases where Debian is distributing a program
where some of the source is GPL licensed, and some of the source has
more restrictive terms.
Let me repeat my more Debian-relevant point, that was somehow glossed
over.
On Sun, Sep 12, 2004 at 03:06:55AM -0400, Anthony DeRobertis wrote:
Not really. A having Depends: B doesn't always imply that B is a module
contained in A. Only an examination of the actual relationship between
the GPL-licensed programs in A and the contents of B prove that
relation.
I
Raul Miller [EMAIL PROTECTED] schrieb/wrote:
Ok, you're right -- while copyright law makes no specific provisions
about how the copy arrives,...
That's plain wrong. Copyright law restricts actions related to a
copyrighted work, not results.
the copyright license can [and often does] make such
Glenn Maynard [EMAIL PROTECTED] schrieb/wrote:
On Sun, Sep 05, 2004 at 08:56:00PM +0200, Claus Färber wrote:
Well, if you have different choices even on a single operating
system, this is an *indication* that it's not a part of the software
distributed but a component of the execution
Raul Miller [EMAIL PROTECTED] schrieb/wrote:
Ok, you're right -- while copyright law makes no specific provisions
about how the copy arrives,...
On Sun, Sep 12, 2004 at 02:27:00PM +0200, Claus Färber wrote:
That's plain wrong. Copyright law restricts actions related to a
copyrighted work,
If more than one person is involved in making those copies the individuals
who contributed towards making those copies can still be nailed for
contributory infringement.
On Fri, Sep 10, 2004 at 08:37:11PM -0700, Ken Arromdee wrote:
In order to have contributory infringement, there must be
On Sep 9, 2004, at 23:36, Glenn Maynard wrote:
First off, I made up this example quickly to try and illustrate that
looking at the end result is not enough; that we need to examine the
steps that got us there.
Hopefully, -legal will consider and respond to the other point made in
my
On Fri, Sep 10, 2004 at 09:08:47AM -0400, Raul Miller wrote:
One piece of the resulting binary--OpenSSL--is not.
This seems to clearly violate the spirit of the GPL.
It might, but the GPL does have the normal components of an OS
exception, for example. And only GPL (3), not (1) or
On Fri, Sep 10, 2004 at 04:38:04PM -0400, Glenn Maynard wrote:
So, you don't need an extreme example. It's perfectly valid for one to
take Emacs, link it against OpenSSL, and distribute binaries, as long as
OpenSSL doesn't accompany it.
In the U.S., at least, linking it against OpenSSL
On Fri, Sep 10, 2004 at 05:15:04PM -0400, Raul Miller wrote:
On Fri, Sep 10, 2004 at 04:38:04PM -0400, Glenn Maynard wrote:
So, you don't need an extreme example. It's perfectly valid for one to
take Emacs, link it against OpenSSL, and distribute binaries, as long as
OpenSSL doesn't
On Fri, Sep 10, 2004 at 05:15:04PM -0400, Raul Miller wrote:
On Fri, Sep 10, 2004 at 04:38:04PM -0400, Glenn Maynard wrote:
So, you don't need an extreme example. It's perfectly valid for one to
take Emacs, link it against OpenSSL, and distribute binaries, as long as
OpenSSL doesn't
On Fri, Sep 10, 2004 at 02:46:52PM -0700, Steve Langasek wrote:
Why? The plain-English meaning of the phrase accompanies the
executable would imply no such thing, and would in fact appear to be
contrary to the intent of this part of the license.
Under copyright law, the precise details of how
On Fri, Sep 10, 2004 at 05:40:00PM -0400, Glenn Maynard wrote:
Huh? Are you claiming that the OS exception doesn't allow linking against
GPL-incompatible system libraries?
It's meaningless to ask that question without specifying who is doing
the linking and who provided those libraries. The
On Fri, Sep 10, 2004 at 06:13:53PM -0400, Raul Miller wrote:
On Fri, Sep 10, 2004 at 02:46:52PM -0700, Steve Langasek wrote:
Why? The plain-English meaning of the phrase accompanies the
executable would imply no such thing, and would in fact appear to be
contrary to the intent of this part
On Fri, Sep 10, 2004 at 03:38:19PM -0700, Steve Langasek wrote:
Huh? There is no copyright infringement here because *the GPL
explicitly allows this form of distribution*.
I was talking about the relationship of copyright law to some distribution
mechanics.
The GPL allows distribution under
On Fri, Sep 10, 2004 at 06:50:28PM -0400, Raul Miller wrote:
On Fri, Sep 10, 2004 at 03:38:19PM -0700, Steve Langasek wrote:
Huh? There is no copyright infringement here because *the GPL
explicitly allows this form of distribution*.
I was talking about the relationship of copyright law to
I certainly don't see the GPL talking about the issue of shipping some
bits of a program on one day through distributor A and other bits of the
program on another day through distributor B.
On Fri, Sep 10, 2004 at 03:58:16PM -0700, Steve Langasek wrote:
If distributor A is distributing an
On Fri, Sep 10, 2004 at 06:16:51PM -0400, Raul Miller wrote:
On Fri, Sep 10, 2004 at 05:40:00PM -0400, Glenn Maynard wrote:
Huh? Are you claiming that the OS exception doesn't allow linking against
GPL-incompatible system libraries?
It's meaningless to ask that question without specifying
On Fri, Sep 10, 2004 at 05:40:00PM -0400, Glenn Maynard wrote:
Huh? Are you claiming that the OS exception doesn't allow linking against
GPL-incompatible system libraries?
On Fri, Sep 10, 2004 at 06:16:51PM -0400, Raul Miller wrote:
It's meaningless to ask that question without
I need to revist this response.
On Fri, Sep 10, 2004 at 04:38:04PM -0400, Glenn Maynard wrote:
So, you don't need an extreme example. It's perfectly valid for one to
take Emacs, link it against OpenSSL, and distribute binaries, as long as
OpenSSL doesn't accompany it.
On Fri, Sep 10,
On Fri, Sep 10, 2004 at 07:31:13PM -0400, Raul Miller wrote:
On Fri, Sep 10, 2004 at 06:53:49PM -0400, Glenn Maynard wrote:
Microsoft creates a system library, MSVCRT (Microsoft Visual C runtime),
which is used by almost all binaries which run on Windows. It's GPL-
incompatible.[1]
This
This case is largely irrelevant unless we'll distribute a version of
emacs with MSVCRT in its depend tree.
On Fri, Sep 10, 2004 at 08:11:29PM -0400, Glenn Maynard wrote:
If you build in Windows, you link against MSVCRT; it's libc. This is
very relevant to what users do with the software.
On Sep 10, 2004, at 09:08, Raul Miller wrote:
On Sep 9, 2004, at 23:36, Glenn Maynard wrote:
The GPL requires that all derived works be entirely available under
the
terms of the GPL.
On Fri, Sep 10, 2004 at 08:35:59AM -0400, Anthony DeRobertis wrote:
Yes, but OpenSSL wouldn't be a derived
On Sep 10, 2004, at 17:15, Raul Miller wrote:
On Fri, Sep 10, 2004 at 04:38:04PM -0400, Glenn Maynard wrote:
So, you don't need an extreme example. It's perfectly valid for one
to
take Emacs, link it against OpenSSL, and distribute binaries, as long
as
OpenSSL doesn't accompany it.
In the
On Sep 10, 2004, at 18:13, Raul Miller wrote:
On Fri, Sep 10, 2004 at 02:46:52PM -0700, Steve Langasek wrote:
Why? The plain-English meaning of the phrase accompanies the
executable would imply no such thing, and would in fact appear to be
contrary to the intent of this part of the license.
On Fri, Sep 10, 2004 at 07:31:13PM -0400, I wrote:
In the context of that exception, a distinction has already been drawn
to distinguish between stuff that comes with the system and the rest of
the program.
It's a mistake to claim that the exception applies to the rest of the
license just
On Fri, Sep 10, 2004 at 08:36:23PM -0400, Anthony DeRobertis wrote:
Please read the start of this subthread; the point was about
distributing as _source_ and compiling on the user's machine. The
program in source form does not include OpenSSL.
In which case there would be no mention of
On Sep 10, 2004, at 18:13, Raul Miller wrote:
Under copyright law, the precise details of how the copy arrives
doesn't matter.
On Fri, Sep 10, 2004 at 08:48:54PM -0400, Anthony DeRobertis wrote:
Yes it does. Consider the difference between a copy of Windows arriving
by being downloaded
On Fri, 10 Sep 2004, Raul Miller wrote:
Under copyright law, the precise details of how the copy arrives doesn't
matter. What matters is that the copy arrives.
Under many circumstances it doesn't matter. However, if the license prohibits
one method of arrival but not another method of
On Thu, Sep 09, 2004 at 10:55:38PM -0400, Anthony DeRobertis wrote:
(b) The method is what must be analyzed, not the end result. As a
trivial example, take the end result of having Microsoft Windows
installed on a PC. A legal contraption to do that would be to go to
your local
On Sun, Sep 05, 2004 at 01:05:27PM +0100, Andrew Suffield wrote:
On Sat, Sep 04, 2004 at 10:03:31PM -0700, Ken Arromdee wrote:
and of course that any document
written in Microsoft Word is derived from Word.
I can use a word document without a copy of word, these days. There
are at least
On Tue, Sep 07, 2004 at 05:34:29PM +, Joel Baker wrote:
On Sun, Sep 05, 2004 at 01:05:27PM +0100, Andrew Suffield wrote:
On Sat, Sep 04, 2004 at 10:03:31PM -0700, Ken Arromdee wrote:
and of course that any document
written in Microsoft Word is derived from Word.
I can use a
On Tue, Sep 07, 2004 at 07:57:06PM +0100, Andrew Suffield wrote:
On Tue, Sep 07, 2004 at 05:34:29PM +, Joel Baker wrote:
On Sun, Sep 05, 2004 at 01:05:27PM +0100, Andrew Suffield wrote:
On Sat, Sep 04, 2004 at 10:03:31PM -0700, Ken Arromdee wrote:
and of course that any document
On 2004-09-06 02:24:58 +0100 Joseph Lorenzo Hall [EMAIL PROTECTED]
wrote:
There are definitely implicit copyright licenses in (US) copyright
case law.
In general, that only concerns us if US law is the one being applied.
I don't think either GPL (for libcurl) or OpenSSL specify US law. If
* Raul Miller:
On Sun, Sep 05, 2004 at 09:07:00PM +0200, Claus Färber wrote:
They did. Solaris 9 reportedly comes with GNU tools (I can't check it
myself because I don't have a machine running Solaris).
You can get gnu tools for solaris from http://www.sunfreeware.com
To my knowledge, gnu
On Mon, 06 Sep 2004 09:53:35 +0100, MJ Ray [EMAIL PROTECTED] wrote:
On 2004-09-06 02:24:58 +0100 Joseph Lorenzo Hall [EMAIL PROTECTED]
wrote:
There are definitely implicit copyright licenses in (US) copyright
case law.
In general, that only concerns us if US law is the one being
It's not about derivative works at all. It's about source. You need
libc and a bunch of header files to build a C program; thus, to
distribute, you have to pack all those along too. Unless they're part
of the OS... unless you distribute them too.
It's not about copyright law's definition of
On Sep 4, 2004, at 07:55, Florian Weimer wrote:
That sounds quite like plac[ing] restrictions on other software that
is distributed along with the licensed software.
If curl-ssl is linked to GPLed programs by default, it's not mere
aggregation.
But it's not linked to the programs. The
On Mon, Sep 06, 2004 at 01:27:56PM -0400, Anthony DeRobertis wrote:
On Sep 4, 2004, at 18:24, Andrew Suffield wrote:
Can I take these two packages on the same CD and split them apart
again, such that they are no longer aggregated, and still use them?
For example, you can't (or at least
Anthony DeRobertis [EMAIL PROTECTED] writes:
On Sep 4, 2004, at 07:55, Florian Weimer wrote:
That sounds quite like plac[ing] restrictions on other software that
is distributed along with the licensed software.
If curl-ssl is linked to GPLed programs by default, it's not mere
aggregation.
On Sat, 4 Sep 2004, Andrew Suffield wrote:
I find a decent smoke test for aggregation to be:
Can I take these two packages on the same CD and split them apart
again, such that they are no longer aggregated, and still use them?
This definition suggests that all Emacs macros are derived from
On Sat, Sep 04, 2004 at 10:03:31PM -0700, Ken Arromdee wrote:
On Sat, 4 Sep 2004, Andrew Suffield wrote:
I find a decent smoke test for aggregation to be:
Can I take these two packages on the same CD and split them apart
again, such that they are no longer aggregated, and still use them?
Ken Arromdee [EMAIL PROTECTED] writes:
On Sat, 4 Sep 2004, Andrew Suffield wrote:
I find a decent smoke test for aggregation to be:
Can I take these two packages on the same CD and split them apart
again, such that they are no longer aggregated, and still use them?
This definition
Brian Thomas Sniffen [EMAIL PROTECTED] schrieb/wrote:
If we follow this interpretation, this means that you can't distribute
an closed source OS with GPL tools. IMO, this was not the intention of
the GPL authors. If you have to distribute the component with the GPL
software, this is a sign
David Schleef [EMAIL PROTECTED] schrieb/wrote:
For one thing, it's absolutely not possible to run the binary in
such a way that openssl is not part of the process image.
You can use an alternative implementation (of libcurl *or* OpenSSL) that
offers the same ABI without pulling in OpenSSL.
Claus Färber wrote:
the author put it under the GPL because he *didn't* want it shipped
with software with restrictions like OpenSSL's.
I see: Someone releasing a program written in curl under the GPL does
not want it to be distributed along with an operating system that
includes the curl
On Sun, Sep 05, 2004 at 09:07:00PM +0200, Claus Färber wrote:
They did. Solaris 9 reportedly comes with GNU tools (I can't check it
myself because I don't have a machine running Solaris).
You can get gnu tools for solaris from http://www.sunfreeware.com
To my knowledge, gnu tools are not
On Sun, Sep 05, 2004 at 08:56:00PM +0200, Claus Färber wrote:
Glenn Maynard [EMAIL PROTECTED] schrieb/wrote:
Huh? Whether such a library is normally distributed with the major
components of the operating system isn't related to the existance of
emulation libraries.
Well, if you have
Glenn Maynard [EMAIL PROTECTED] schrieb/wrote:
On Sun, Sep 05, 2004 at 09:07:00PM +0200, Claus Färber wrote:
Brian Thomas Sniffen [EMAIL PROTECTED] schrieb/wrote:
If we follow this interpretation, this means that you can't distribute
an closed source OS with GPL tools. IMO, this was not the
Andrew Suffield [EMAIL PROTECTED] schrieb/wrote:
On Sun, Sep 05, 2004 at 09:07:00PM +0200, Claus F?rber wrote:
Of course, in such simple cases, they can be thought of having given
implicit permission to link against OpenSSL.
There is no such thing as implicit permission in copyright law (or
On 06 Sep 2004 02:54:00 +0200, Claus Färber [EMAIL PROTECTED] wrote:
Andrew Suffield [EMAIL PROTECTED] schrieb/wrote:
On Sun, Sep 05, 2004 at 09:07:00PM +0200, Claus F?rber wrote:
Of course, in such simple cases, they can be thought of having given
implicit permission to link against
On Mon, Sep 06, 2004 at 02:16:00AM +0200, Claus Färber wrote:
Again, it is more complicated. What if you have both a free and binary-
compatible proprietory version of the os? E.g., is a Windows program
linked against the Windows DLLs if users can run it with wine? What
about Linux
Glenn Maynard [EMAIL PROTECTED] schrieb/wrote:
This is all irrelevant. The issue is that you can't distribute GPL
binaries *linked against* GPL-incompatible libraries.
On Mon, Sep 06, 2004 at 02:16:00AM +0200, Claus Färber wrote:
It's more complicated than that when dynamic linking is
On Mon, Sep 06, 2004 at 02:16:00AM +0200, Claus F?rber wrote:
It ultimatly does not make sense if you can choose one of several
libraries (with different licenses) that can be dynamically linked
against a program without recompiling it.
For example, you distribute a program linked
* Anthony DeRobertis:
Probably distribution. If you distribute just the OpenSSL of curl
version, it's rather clear that you intent that all applications
linking against curl also link against OpenSSL.
So, if we were to compile it against a curl-nossl, that'd be fine. But
if we then
* Andrew Suffield:
Probably distribution. If you distribute just the OpenSSL of curl
version, it's rather clear that you intent that all applications
linking against curl also link against OpenSSL.
And if you distribute both?
If the OpenSSL version is not marked as the default one
Brian Thomas Sniffen [EMAIL PROTECTED] schrieb/wrote:
What's in a normal Debian install doesn't matter, because it all gets
distributed together on mirrors and in cd-packs. There's a very
specific phrase used to keep MS and Sun from shipping Emacs with their
proprietary libc: unless that
[EMAIL PROTECTED] (Claus Färber) writes:
Brian Thomas Sniffen [EMAIL PROTECTED] schrieb/wrote:
What's in a normal Debian install doesn't matter, because it all gets
distributed together on mirrors and in cd-packs. There's a very
specific phrase used to keep MS and Sun from shipping Emacs
On Sat, Sep 04, 2004 at 04:42:00PM +0200, Claus Färber wrote:
curl-ssl might even be GPL-free if distributed with GnuTLS' OpenSSL-
emulation.
IMO, this is a clear sign that an OpenSSL-compatible library should be
considered part of the operating system.
Huh? Whether such a library is
On Sat, Sep 04, 2004 at 04:56:00PM +0200, Claus Färber wrote:
Brian Thomas Sniffen [EMAIL PROTECTED] schrieb/wrote:
What's in a normal Debian install doesn't matter, because it all gets
distributed together on mirrors and in cd-packs. There's a very
specific phrase used to keep MS and Sun
Greetings Debian-legal, (I've just started subscribing to this list.)
On Sat, 4 Sep 2004 13:42:21 -0700, Steve Langasek [EMAIL PROTECTED] wrote:
On Sat, Sep 04, 2004 at 04:56:00PM +0200, Claus Färber wrote:
If we follow this interpretation, this means that you can't distribute
an closed
On Sat, Sep 04, 2004 at 01:55:33PM -0700, Joseph Lorenzo Hall wrote:
Greetings Debian-legal, (I've just started subscribing to this list.)
On Sat, 4 Sep 2004 13:42:21 -0700, Steve Langasek [EMAIL PROTECTED] wrote:
On Sat, Sep 04, 2004 at 04:56:00PM +0200, Claus Färber wrote:
If we follow
On 2004-09-04 15:42:00 +0100 Claus Färber [EMAIL PROTECTED] wrote:
IMO, this is a clear sign that an OpenSSL-compatible library should be
considered part of the operating system.
Any new reasoning for that, or just restating in the hope it will become true?
--
MJR/slefMy Opinion Only
On Aug 19, 2004, at 20:27, Florian Weimer wrote:
* Andrew Suffield:
Here's the snarly bit:
Take a copy of curl, not built with ssl support. Build your GPLed
application, linking it to this curl. There should unarguably be no
problems here - everything involved is GPL-compatible.
Now, go and
On Thu, 19 Aug 2004, David Schleef wrote:
For one thing, it's absolutely not possible to run the binary in
such a way that openssl is not part of the process image.
Since when is Debian distributing linked process images?
I have a lot of difficulty dicerning a legal difference between
On Fri, Aug 20, 2004 at 02:27:55AM +0200, Florian Weimer wrote:
* Andrew Suffield:
Here's the snarly bit:
Take a copy of curl, not built with ssl support. Build your GPLed
application, linking it to this curl. There should unarguably be no
problems here - everything involved is
On Thu, Aug 12, 2004 at 04:17:22PM -0700, Steve Langasek wrote:
On Thu, Aug 12, 2004 at 03:22:34PM +0200, Daniel Stenberg wrote:
Please forgive a new subscriber if this subject already has been debated to
death. In that case, just let me know and I'll quietly crawl away again.
Ok, here's
On Thu, Aug 19, 2004 at 10:02:06AM +0200, Francesco P. Lovergine wrote:
On Thu, Aug 12, 2004 at 04:17:22PM -0700, Steve Langasek wrote:
I'm not a Debian guru, but I scanned through the list of apps depending
on
curl to see what licenses they use, and I stopped when I had collected
Steve Langasek [EMAIL PROTECTED] writes:
If your understanding of the license exception requirements were
correct, it would be a very easy loophole for people to exploit, using
GPL-compatible library layers to sanitize the licenses of library
dependencies.
But in fact, the GPL's definition
On Thu, Aug 19, 2004 at 11:09:11AM +0200, Måns Rullgård wrote:
Steve Langasek [EMAIL PROTECTED] writes:
If your understanding of the license exception requirements were
correct, it would be a very easy loophole for people to exploit, using
GPL-compatible library layers to sanitize the
Steve Langasek [EMAIL PROTECTED] writes:
On Thu, Aug 19, 2004 at 11:09:11AM +0200, Måns Rullgård wrote:
Steve Langasek [EMAIL PROTECTED] writes:
If your understanding of the license exception requirements were
correct, it would be a very easy loophole for people to exploit, using
On Thu, Aug 19, 2004 at 11:09:11AM +0200, Måns Rullgård wrote:
When using dynamic linking that is not necessarily the case. Most
dynamic linkers use lazy loading of libraries, such that the openssl
libraries would not actually be mapped in to the process address space
until one of its
Here's the snarly bit:
Take a copy of curl, not built with ssl support. Build your GPLed
application, linking it to this curl. There should unarguably be no
problems here - everything involved is GPL-compatible.
Now, go and build a copy of curl that is linked to openssl. Install
that one
On Thu, Aug 19, 2004 at 08:59:44PM +0200, Måns Rullgård wrote:
I didn't say anything about derived works. Neither does the GPL when
talking about source code.
The GPL also doesn't define source code to include all modules it
uses, it defines it to include all modules it contains.
David Schleef [EMAIL PROTECTED] writes:
On Thu, Aug 19, 2004 at 08:59:44PM +0200, Måns Rullgård wrote:
I didn't say anything about derived works. Neither does the GPL when
talking about source code.
The GPL also doesn't define source code to include all modules it
uses, it defines it
On Fri, Aug 20, 2004 at 12:26:43AM +0200, Måns Rullgård wrote:
David Schleef [EMAIL PROTECTED] writes:
For one thing, it's absolutely not possible to run the binary in
such a way that openssl is not part of the process image.
Since when is Debian distributing linked process images?
I have
David Schleef [EMAIL PROTECTED] writes:
On Thu, Aug 19, 2004 at 11:09:11AM +0200, Måns Rullgård wrote:
When using dynamic linking that is not necessarily the case. Most
dynamic linkers use lazy loading of libraries, such that the openssl
libraries would not actually be mapped in to the
Måns Rullgård wrote:
David Schleef [EMAIL PROTECTED] writes:
Symbol references are not necessarily resolved at that time, unless
you define LD_BIND_NOW or are using prelinking. There's really no
method of doing lazy linking as you suggest with C, since it would
either fail (such as with
* Andrew Suffield:
Here's the snarly bit:
Take a copy of curl, not built with ssl support. Build your GPLed
application, linking it to this curl. There should unarguably be no
problems here - everything involved is GPL-compatible.
Now, go and build a copy of curl that is linked to openssl.
Hey
Please forgive a new subscriber if this subject already has been debated to
death. In that case, just let me know and I'll quietly crawl away again.
Ok, here's my explanation of the problem:
There this package in recent Debian named 'curl' (using a MIT-like license).
It is built with
On Thu, 12 Aug 2004, Daniel Stenberg wrote:
If this a hge can of worms or am I just plain wrong?
Ok, don't hit me.
I did another google and I've found enough references on the topic openssl is
PART of the OS etc so no need to say anything else.
Sorry for the noise.
--
-=-
On 2004-08-12 14:22:34 +0100 Daniel Stenberg [EMAIL PROTECTED] wrote:
Of course getting curl to link with an SSL library that isn't GPL
incompatible would also be a fix for this particular case, but I
consider
that a pretty big job that won't happen this year (by me).
I think this might be
On 2004-08-12 14:31:19 +0100 Daniel Stenberg [EMAIL PROTECTED] wrote:
I did another google and I've found enough references on the topic
openssl
is PART of the OS etc so no need to say anything else.
That doesn't work. OpenSSL is not an required part of the debian
operating system at
MJ Ray [EMAIL PROTECTED] writes:
On 2004-08-12 14:31:19 +0100 Daniel Stenberg [EMAIL PROTECTED] wrote:
I did another google and I've found enough references on the topic
openssl is PART of the OS etc so no need to say anything else.
That doesn't work. OpenSSL is not an required part of the
* Daniel Stenberg:
On Thu, 12 Aug 2004, Daniel Stenberg wrote:
If this a hge can of worms or am I just plain wrong?
Ok, don't hit me.
I did another google and I've found enough references on the topic
openssl is PART of the OS etc so no need to say anything else.
I thought that for
On Thu, Aug 12, 2004 at 03:31:19PM +0200, Daniel Stenberg wrote:
On Thu, 12 Aug 2004, Daniel Stenberg wrote:
If this a hge can of worms or am I just plain wrong?
Ok, don't hit me.
I did another google and I've found enough references on the topic openssl
is PART of the OS etc so no
On Thu, Aug 12, 2004 at 03:22:34PM +0200, Daniel Stenberg wrote:
There this package in recent Debian named 'curl' (using a MIT-like
license). It is built with OpenSSL (you all know the OpenSSL license).
With curl there comes two (that we care about here) debian packages
nowadays named
Given the fact that this topic seems to come up relatively often, would it
be a good idea to put a few things into a FAQ for people to refer to?
I am willing to put down a draft of questions. I have proposed this as a
side note in a private mail, and was pointed that this not a Debian-specific
On 2004-08-12 23:59:00 +0100 Freek Dijkstra
[EMAIL PROTECTED] wrote:
Given the fact that this topic seems to come up relatively often,
would it
be a good idea to put a few things into a FAQ for people to refer to?
Yes, and that's why people started work on one already. Please add to
On Thu, Aug 12, 2004 at 03:22:34PM +0200, Daniel Stenberg wrote:
Please forgive a new subscriber if this subject already has been debated to
death. In that case, just let me know and I'll quietly crawl away again.
Ok, here's my explanation of the problem:
There this package in recent Debian
On Fri, Aug 13, 2004 at 12:59:00AM +0200, Freek Dijkstra wrote:
Given the fact that this topic seems to come up relatively often, would it
be a good idea to put a few things into a FAQ for people to refer to?
In my opinion, it should be added to, or referred from either or both:
97 matches
Mail list logo
