public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Helge Hafting <helge.hafting@aitel.hist.no>
To: Emmanuel Fleury <fleury@cs.aau.dk>
Cc: Linux Kernel ML <linux-kernel@vger.kernel.org>
Subject: Re: freebox possible GPL violation
Date: Thu, 06 Oct 2005 13:39:17 +0200	[thread overview]
Message-ID: <43450CE5.50302@aitel.hist.no> (raw)
In-Reply-To: <4344F39B.10806@cs.aau.dk>

Emmanuel Fleury wrote:

>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.
>  
>
Well, but there still is a kernel in the box that was downloaded before
they bought it?  Or does the box become unuseable when they buy it?

>  
>
>>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).
>  
>
Licencing rules applies when copying stuff for internal use.
Consider what would happen, if the company used windows
instead of linux on their boxes:
Everytime they copy windows onto a box they have to pay ms for another
licence.  Big companies can't jsut buy a single windows licence and
copy it to all their desktops.  BSA has definitely clarified that in court.
Now, the ms licence specifies payments to ms.  The GPL is just another 
licence,
with slightly different terms.  Instead of a payment, it specifies source
availability as the "price". 

There is clearly court precedent that companies have to comply with 
software
licences when making copies for _internal_ use.  GNUs licence or ms licence
shouldn't matter.

>"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.
>  
>
If "when do we invoke the GPL" is hard to see, try considering
"when do we have to pay" if using ordinary proprietary pay-per-instance
software.  You will then find that the cases are similiar.

If the company makes and distributes an internal copy of windows, then 
they pay ms.
If the company makes and distributes an internal copy of linux, then 
they have to
provide an internal copy of the source as well.

If I make a business out of lending windows boxes, then I have to pay 
licences
on each box.  If I lend customers linux boxes, I should lend them the 
source too if they
requests it.  Remember, even if the average customer doesn't know what 
software
is in the box, they still have the right to make a copy of the linux 
kernel, because you
cannot take away that right.

>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.
>  
>
This is fine.  Similiar to how I can run a linux-based webserver, without
having to provide people with linux source.  This because I don't give
them the server that contains linux.  But if you _sell_ one of those
network nodes, then you have to provide linux source along with it.

>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.
>  
>
Interesting argument indeed.  But consider: what would happen
if the phones (or freebox) were to run windows?  The distributing
company would have to pay licencing fees, right? 

>Has been any previous similar cases in the past which went in court ?
>
>  
>
There have at least been cases where companies were selling
linux-powered products, and were told that they had to
provide the sources.  I don't know if any of them bothered
going to court, simply making the source available (on a cd
or webserver) is so much cheaper than that.

>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).
>  
>
An interesting thing about the GPL is that it talks about
"distributing copies", not about "selling or otherwise changing ownership".

"Distributing" a linux kernel embedded in a product owned by the
company doesn't change that.  Where the binary kernel go, the
source should go too (if requested).

Fortunately, this licencing term is so easy to satisfy that it'd be silly
to try to fight it. Stick the source on a webserver somewhere.  Provide
the URL in the accompagnying paper (or a README file if appropriate.)
If distributing cd's, consider sticking a tarball there.

Helge Hafting

  parent reply	other threads:[~2005-10-06 11:37 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
2005-10-06  9:53                       ` Emmanuel Fleury
2005-10-06 11:39                       ` Helge Hafting [this message]
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=43450CE5.50302@aitel.hist.no \
    --to=helge.hafting@aitel.hist.no \
    --cc=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