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
next prev 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