public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Brian Gough <bjg@network-theory.co.uk>
To: gsl-discuss@sources.redhat.com
Subject: Re: [smartquant] Re: GPL license violation? [GNU Scientific Library]
Date: Mon, 12 Nov 2001 02:00:00 -0000	[thread overview]
Message-ID: <15349.9339.250310.952036@debian> (raw)
Message-ID: <20011112020000.bumkqOw6v1I8OWFXZ74yvlsRTuFlvaBa32kLqupUpzA@z> (raw)
In-Reply-To: <3BF40B74.ACDE5714@jpl.nasa.gov>

Edwin Robert Tisdale writes:
 > Anton may distribute his software without the GSL
 > so that customers would be obliged to obtain the GSL
 > (or another library using the same API) separately
 > and link them together themselves.

I don't think any lawyer is going to recommend that as a business
model..  attempting to circumvent a license is illegal too.


Newsgroups: gnu.misc.discuss
From: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Can Technical Tricks Circumvent the GPL?
Message-ID: <9301130018.AA28371@mole.gnu.ai.mit.edu>
Sender: daemon@cis.ohio-state.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 12 Jan 1993 14:18:55 GMT
Lines: 45

               Can Technical Tricks Circumvent the GPL?

People often speculate about technical procedures that might
circumvent the GPL in some way.  For example, they may suggest a
modified version could be cut artificially into two pieces, one free
and one proprietary, that are called two independent programs.

This kind of scheme is based on the premise that the legal system
operates in the fashion of a stupid computer program, and that
superficial manipulations of the way files are grouped and labeled
would fool it.  While the legal system often does seem stupid and
easily fooled in comparison with common sense, the FSF's lawyer told
us that it would not be stupid about this.

The lawyer said that such a scheme would fail because a judge would
regard it as a subterfuge.  The judge would conclude that the two
parts are really one program in disguise, and go on from there.

Our lawyer also said that a judge would tend to be harsh toward anyone
perceived to be trying a subterfuge.

As hackers, we tend to become absorbed in the technical details of the
proposed schemes, and not pay enough attention to the wider context.
The possibility of a loophole in the GPL might be interesting
abstractly in its own right, but its main importance is in connection
with whether the GPL does what it is supposed to do: ensure that
modified versions of a program are free.

Hackers also tend to model the GPL based on concepts used for security
systems, assuming that any puncture makes it collapse like a soap
bubble.  But business doesn't move like a gas; more like molasses.  If
a real, legally sustainable loophole were found, its effect would be
diminished by the inconvenience of using it.  This is likely to be
significant, and would dissuade most companies from trying.  Thus, the
GPL would still retain most of its effect.

Experience shows that companies are not eager to try to circumvent the
GPL.  If they think their plans might conflict with the GPL, they
generally contact the FSF to make sure there is no conflict.

The most fundamental point--the "bottom line"--is that as a practical
matter the GPL does achieve its goal.  Improvements to our software
are actually made free, and no amount of speculation can override this
fact.  Apparently, any loopholes are sufficiently inconvenient that
they are not much of a factor.

  parent reply	other threads:[~2001-11-16 15:00 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-19 13:20 Edwin Robert Tisdale
2001-11-11  7:20 ` Edwin Robert Tisdale
2001-12-19 13:20 ` Brian Gough [this message]
2001-11-12  2:00   ` Brian Gough
2001-12-19 13:20 Edwin Robert Tisdale
2001-11-14  3:33 ` Edwin Robert Tisdale
     [not found] <200111132351.PAA25299@eskimo.com>
2001-12-19 13:20 ` Ferdinando Ametrano
2001-12-19 13:20   ` Anton Fokin
2001-12-19 13:20     ` Brian Gough
2001-12-19 13:20       ` Brian Gough
2001-12-19 13:20         ` [smartquant] " Anton Fokin
2001-11-09  6:07           ` Anton Fokin
2001-12-19 13:20           ` Brian Gough
2001-11-09  9:19             ` Brian Gough
2001-12-19 13:20             ` Anton Fokin
2001-11-10  2:37               ` Anton Fokin
2001-12-19 13:20 Edwin Robert Tisdale
2001-11-13  8:44 ` Edwin Robert Tisdale
2001-12-19 13:20 ` José Miguel Buenaposada
2001-11-13  9:24   ` José Miguel Buenaposada
2001-12-19 13:20   ` José Miguel Buenaposada
2001-12-19 13:20 ` Ferdinando Ametrano
2001-11-14  2:36   ` Ferdinando Ametrano
2001-12-19 13:20   ` Ferdinando Ametrano
2001-12-19 13:20 Kenneth Geisshirt
2001-12-19 13:20 ` [smartquant] " Anton Fokin
2001-11-08  6:56   ` Anton Fokin
2001-12-19 13:20 Edwin Robert Tisdale
2001-11-14  2:37 ` Edwin Robert Tisdale
2001-12-19 13:20 ` Ferdinando Ametrano
2001-11-14  3:04   ` Ferdinando Ametrano
2001-12-19 13:20   ` Dirk Eddelbuettel
2001-11-14  3:21     ` Dirk Eddelbuettel
2001-12-19 13:20     ` Dirk Eddelbuettel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=15349.9339.250310.952036@debian \
    --to=bjg@network-theory.co.uk \
    --cc=gsl-discuss@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).