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

While I respect your position that anything not GPL is evil, without
agreeing with it, that does not in any way extend to anything which
violates our license.

If there is some information that you need as a kernel developer which
BK is hiding from you of course we would provide that information.
To the best of my knowledge there is absolutely nothing that we are
hiding from you in that context. If there is, let us know. Our belief
is at least in part based on the lack of queries from anyone else.

On the other hand, if there is information that is not interesting to
a kernel developer but is interesting to someone trying to rip off our
software, no, we must respectfully decline to offer that.

Thanks,

--lm

On Wed, Oct 27, 2004 at 04:30:37AM +0200, Roman Zippel wrote:
> Hi,
>
> On Mon, 25 Oct 2004, Larry McVoy wrote:
>
> > You are mistakenly assuming that the way BK stores the data, or does
> > merges, or synchronizes is what we think is worth protecting, and you
> > are pretty much wrong.
>
> Does that mean you don't mind if someones export the changeset information
> in an useful way? All I need is pretty much the information that already
> comes via the commit list (actually in the format used until May, where
> it still contained information about renames) plus some useful identifiers
> to identify the predecessors of a changeset.
>
> bye, Roman

--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
-
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.349 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site