lkml.org 
[lkml]   [2004]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: BK kernel workflow
Hi,

On Wed, 27 Oct 2004, Linus Torvalds wrote:

> The alternative to me using BitKeeper would be patches and tar-balls.
> Which you already have. So why are you complaining? BK isn't taking
> anything away from you..

Linus, what happened to the early promises, that the data wouldn't be
locked into bk? Is the massively reduced data set in the cvs repository
really all we ever get out of it again?

> Since you seem to be blind to the problem, let's try it one more time.
>
> The BK license is _exactly_ the same issue as with the GPL. In the GPL,
> the rule is "tit for tat" - you get to play with the sources, but in
> exchange you have to give out your modifications. Some people complain
> about that, and I call them worthless whiners.
>
> In the BK license, it's "tit for tat". You get to use Larry's program, in
> exchange for not competing with him. Some people complain about that, and
> I call them worthless whiners.
>
> See the pattern? In both cases, the answer is: if you don't like it, don't
> use it. And in both cases, if you don't use it, you are no worse off than
> if it didn't exists, so it's not like the existence of GPL'd programs or
> BK is making your life any worse.

You can play this game with every license, if a licence had no conditions
it wouldn't be a license anymore. If you want to get anywhere with this,
why don't you look at the purpose of the license?
The only purpose of the bk license is to protect the business case of its
owner with all its consequences, which you are trying very hard to avoid
to discuss.
One of these consequences is that you cannot convert that repository on
your harddisk into a different format, no matter behind how many firewalls
you hide it. This makes your question for alternatives rather pointless,
you couldn't use them anyway, even if they existed, unless you want to
throw away the current history.
Why are you avoiding to discuss these consequences? Your actions as kernel
maintainer don't happen in isolation, they have an effect on other people,
positive as negative. Concentrating only on the positive and doing
personal attacks can't hide the reality forever. Call me whatever you
want if it makes you feel better, but I'll continue to look on both sides
of the story.

I make a last attempt to make this more clear. I don't care what tools you
use, I don't care if I can't use them, but why is it acceptable for you to
cut off _any_ possibility for me to archive the same result in some other
way? I don't want to drink away your beer and I don't want to control what
you watch on your TV. We are talking about the kernel repository here,
which is a shared resource a lot of people helped to create, but why is it
acceptable for you, that some of them can't benefit from it like the rest.
Linus, this is not some random project, this is a public project with
higher moral standards, why is acceptable to have different moral
standards during its development? A goal of Linux is it to preserve the
freedom of its users, making them independent of a single vendor, why is
it acceptable to make it a condition that developers have to commit
themselves to a single vendor in order to get full access to the kernel
repository?

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.134 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site