public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Emmanuel Fleury <fleury@cs.aau.dk>
To: Linux Kernel ML <linux-kernel@vger.kernel.org>
Subject: Re: freebox possible GPL violation
Date: Thu, 06 Oct 2005 11:51:23 +0200	[thread overview]
Message-ID: <4344F39B.10806@cs.aau.dk> (raw)
In-Reply-To: <4344EC64.2010400@aitel.hist.no>

Helge Hafting wrote:
> 
> Interesting argument, but it breaks for at least two reasons: 1. You
> can buy that box instead of just hiring it. That moves kernels 
> "outside the company", for money even.

I might have misunderstood but I think that if you buy the hardware you
cannot connect it to the DSLAM network anymore. So that only the boxes
they own are connected to the DSLAM.

> 2. It doesn't matter if they only move kernels withing their own 
> companys equipment. If they lend a customer equipment containing a
> linux kernel, then they're lending them a linux kernel.  Lending is
> distribution!

Are you sure this point has been clarified in court in the past ?
If not, I would bet on it (for the specific case of settop boxes).

> The argument might be fine, if they were moving linux kernels into 
> company equipment used by company personell only.  (I.e.
> linux-powered desktops/servers/gadgets for their employees.) And it
> might not. Maybe they actually have to distribute source to 
> employees too, if they request it.  The GPL only mentions recipients,
> no exceptions for "internal company use".  A company may perhaps
> demand that the employees never request the source, though. Or
> perhaps "internal use" is covered by the company being a "legal
> unit".

"internal use" is kind of a buzz word here and should probably be
clarified for this kind of cases.

For now, I really don't see the flaw in Free's argument.

I mentioned in another mail the case of a mobile phone network
infrastructure where the network nodes to which mobile phones are
connecting are running Linux. It seems to be an "internal use" (as it
never leak out of the company network) and yet providing a service to
customers.

The only difference in the Freeboxes case is that the node is at the
customer place (you can compare the customer's mobile phone to the
customer's computer plugged on the Freebox). But the fact that you don't
share your node with others and that you have it at home doesn't change
the fact that the company own it.

Has been any previous similar cases in the past which went in court ?

Maybe the best attack angle would be to say that if a GPL system is
interacting directly with a customer, then the source code should be
distributed. But I don't see if this requirement need changes in the GPL
(I'm ain't no expert).

Regards
-- 
Emmanuel Fleury

Always program as if the person who will be maintaining your program
is a violent psychopath that knows where you live.
  -- Unknown

  reply	other threads:[~2005-10-06  9:53 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-05 11:13 freebox possible GPL violation Pierre Michon
2005-10-05 11:22 ` Emmanuel Fleury
2005-10-05 11:27   ` Arjan van de Ven
2005-10-05 11:37     ` Emmanuel Fleury
2005-10-05 11:59       ` Arjan van de Ven
2005-10-05 12:02         ` Emmanuel Fleury
2005-10-05 12:07           ` Arjan van de Ven
2005-10-05 12:29             ` Emmanuel Fleury
2005-10-05 12:45               ` Michael Poole
2005-10-05 17:11               ` Alexandre Oliva
2005-10-06  0:07               ` Helge Hafting
2005-10-06  0:49                 ` David Lang
2005-10-06  1:12                   ` Stefan Smietanowski
2005-10-06  2:25                     ` David Lang
2005-10-06  9:20                   ` Helge Hafting
2005-10-06  9:51                     ` Emmanuel Fleury [this message]
2005-10-06  9:53                       ` Emmanuel Fleury
2005-10-06 11:39                       ` Helge Hafting
2005-10-06 13:05                         ` Emmanuel Fleury
2005-10-06 13:42                           ` Michael Poole
2005-10-06 14:19                           ` Helge Hafting
2005-10-06 20:15                       ` Stefan Smietanowski
2005-10-11  2:27             ` David Schwartz
2005-10-11 10:48               ` Graham Murray
2005-10-05 12:15           ` Vincent Hanquez
2005-10-05 11:45     ` linux-os (Dick Johnson)
2005-10-05 11:59       ` Arjan van de Ven
2005-10-05 11:50 ` Emmanuel Fleury
  -- strict thread matches above, loose matches on Subject: below --
2005-10-06 23:26 Pierre Michon
2005-10-06 12:01 Pierre Michon
2005-10-06 13:06 ` Emmanuel Fleury
2005-10-06 13:40   ` Michael Poole
2005-10-06 14:48     ` Matan Peled
2005-10-05 17:57 Pierre Michon
2005-10-05 16:06 Pierre Michon
2005-10-05 16:47 ` Emmanuel Fleury
2005-10-05 15:18 Pierre Michon
2005-10-05 15:49 ` Vincent Hanquez
2005-10-05 15:12 Pierre Michon
2005-10-05 15:08 Pierre Michon
2005-10-05 10:08 Pierre Michon
2005-10-05 10:18 ` Emmanuel Fleury
2005-10-05  8:47 Pierre Michon
2005-10-05  9:42 ` Helge Hafting
2005-10-15  9:40 ` Loic Dachary
2005-10-19 17:58   ` Pierre Michon
2005-10-20 15:29     ` Loic Dachary

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=4344F39B.10806@cs.aau.dk \
    --to=fleury@cs.aau.dk \
    --cc=linux-kernel@vger.kernel.org \
    /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