public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Larry McVoy <lm@bitmover.com>
To: linux-kernel@vger.kernel.org
Subject: Re: [OFF TOPIC] BK license change
Date: Mon, 22 Apr 2002 14:35:27 -0700	[thread overview]
Message-ID: <20020422143527.K18800@work.bitmover.com> (raw)
In-Reply-To: <20020421095715.A10525@work.bitmover.com>

On Sun, Apr 21, 2002 at 09:57:15AM -0700, Larry McVoy wrote:
> I'm considering a change to the BKL which says that N days after a
> changeset is made, that changeset (and its ancestory) must be available
> on a public bk server.  In other words, put a hard limit on how long
> you may hide.

OK, people have been replying in private to this raising various objections
and making good points:

    David Mosberger was worried that I was suggesting that not
    providing access to changes to GPLed code immediately (or ever,
    if you don't redistribute) is a GPL violation.  To clarify: people
    can make changes to GPLed software and are only required to make
    those changes available if they redistribute.  That's the rule.
    The point I was trying to make is that I wanted BK to be used for
    free on work which is done out in the open, not behind closed doors.

    Greg KH raised the point that not everyone can have a public
    BK server, their IT department may not allow that.  He said that
    bkbits.net may need beefing up if we force people out into the open
    (it needs beefing up anyway, but point is well taken).

    Itai Nahshon raised several points about encrypted software, illegal
    under the DMCA software, etc.

    Jonathan Corbet raised the point of exposing software that isn't
    done yet, which may have security holes, and/or other problems.

There were others, but this gives you a feel.  In general, I'm getting 
the message that forcing everything out into the open isn't always going
to be a good thing.

Yet I still have the problem of people abusing the system (not to mention
the "spirit" of free software).  What I'd like is a way to qualify that
"abuse" and put that in the license, and what I'm hearing is that any
blanket statement may be a net negative for someone who should not be
adversely affected.

So that leaves a more selective approach.  We can add a clause that says
we reserve the right to insist you either

    a) maintain your changes in public within 90 days of making them, or
    b) buy closed use seats, or
    c) cease to use the product.

and then apply it to the abusers of the system.  I understand this is 
still a scary thing in that there is no guarentee that we won't knock 
on your door, but the reality is that people always find ways to 
avoid the intent of licenses and we need some recourse.  At least this
way doesn't force this upon everyone, you have to exhibit some bad
behaviour in order for us to notice.

If you have a better idea on how to shut down the abusers without scaring
the legit users, I'm all ears.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

  parent reply	other threads:[~2002-04-22 21:35 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-21 16:57 [OFF TOPIC] BK license change Larry McVoy
2002-04-21 12:12 ` Daniel Phillips
2002-04-21 16:29 ` Greg KH
2002-04-22  7:33 ` Simon Fowler
2002-04-22 21:35 ` Larry McVoy [this message]
2002-04-21 22:14   ` Daniel Phillips
2002-04-22 22:29     ` Andreas Dilger
2002-04-21 22:52       ` Daniel Phillips
2002-04-22 23:12         ` Doug Ledford
2002-04-21 23:34           ` Daniel Phillips
2002-04-22 22:22   ` Jeff Garzik
2002-04-22 22:52     ` Larry McVoy
2002-04-25 15:01   ` Pavel Machek
2002-04-27  9:30     ` Florian Weimer
2002-04-27 13:45       ` Mr. James W. Laferriere
2002-04-27 20:34       ` Larry McVoy
2002-04-26  4:22         ` Pavel Machek
2002-04-29 19:34           ` Rik van Riel
2002-04-29 19:45             ` Larry McVoy
2002-04-30  5:36               ` Pavel Janík
  -- strict thread matches above, loose matches on Subject: below --
2002-04-27 18:13 Christoph Lameter
2002-04-27 18:25 ` Russell King
2002-04-27 18:30 ` Alexander Viro
2002-04-27 21:50   ` Martin Dalecki
2002-04-28 16:55     ` Richard Gooch

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=20020422143527.K18800@work.bitmover.com \
    --to=lm@bitmover.com \
    --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