2002-10-06 12:34:46

by Manfred Spraul

[permalink] [raw]
Subject: Re: BK MetaData License Problem?

> By transmitting the Metadata
> to an Open Logging server, You hereby grant BitMover,
> or any other operator of an Open Logging server, per-
> mission to republish the Metadata sent by the Bit-
> Keeper Software to the Open Logging server.
>

Where is the problem? This asks for a permission, not for exclusive rights.


> By transmitting the MetaData to an Open Logging server, You
> hereby also agree to license the MetaData under the same license
> you license the data it describes.
>
> (or something to that extent - i'm not a lawyer.)
>

That's a problem for Linux, not for Larry.

If you send a patch to Linus this means you distribute a modification to
GPLed source, which means it's automatically placed under the GPL.

What's missing is a comment in the BK-usage document that informs the
submitter that he must give the permission to republish the commit info.
i.e. asking Linus to pull from an url is not a private message to Linus,
it's the equivalent of sending a mail to a public, moderated mailing list.

--
Manfred


2002-10-06 12:56:46

by Ingo Molnar

[permalink] [raw]
Subject: Re: BK MetaData License Problem?


On Sun, 6 Oct 2002, Manfred Spraul wrote:

> Where is the problem? This asks for a permission, not for exclusive
> rights.

yes, but what i say is that BK *creates* a problem, (just like CVS would
create similar problems) and the license clearly shows that BM is aware of
and tries to handle part of this legal problem. (And given that the BK
metadata is richer than eg. CVS, i suspect it will be a magnified problem
later on.)

i surely would find it to be a problem if BitMover would be the only
entity that has clean legal permissions to host the whole Linux kernel
repository. Even if Larry does not intend this to be the case. (which
assumption i grant blindly.)

what we had so far, at least according to my understanding, is that people
sent patches to a public and well-archived list, and that the GPL-ing of
the patch did not happen because the mailing shows their intent [i sure
never mention that the patch is GPL-ed], but because by the act of mailing
to the public list and to Linus they *distributed* the derived work, and
thus the GPL's provisions wrt. redistribution trigger - and Linus is fair
to pick the patch up.

the commit message on the other hand is the same as eg. SuSE's PR
announcement of SuSE Linux 20.9, it's metadata connected to their
publishing of a GPL-ed piece of code, but it's otherwise copyright and
owned by SuSE. The pure fact that a commit message about a GPL-ed work is
distributed publicly does not necessarily trigger any licensing of the
commit message itself.

> What's missing is a comment in the BK-usage document that informs the
> submitter that he must give the permission to republish the commit info.
> i.e. asking Linus to pull from an url is not a private message to Linus,
> it's the equivalent of sending a mail to a public, moderated mailing
> list.

well, republishing permission is not enough i guess to keep the Linux
kernel tree as one entity i suspect. Plus even if a commit message is sent
to a public list, it does not necessarily mean it's put into the public
domain or something equivalent to that.

perhaps the best solution would be to make this part of BKL.txt - to give
protection to *both* BM and the Linux community. After all the commit is
performed by the owner of the commit message, so a good point for legal
stuff to trigger is in BKL.txt.

Ingo

2002-10-06 15:42:41

by Marek Habersack

[permalink] [raw]
Subject: Re: BK MetaData License Problem?

On Sun, Oct 06, 2002 at 03:13:24PM +0200, Ingo Molnar scribbled:
>
> On Sun, 6 Oct 2002, Manfred Spraul wrote:
>
> > Where is the problem? This asks for a permission, not for exclusive
> > rights.
>
[snip]
> the commit message on the other hand is the same as eg. SuSE's PR
> announcement of SuSE Linux 20.9, it's metadata connected to their
> publishing of a GPL-ed piece of code, but it's otherwise copyright and
> owned by SuSE. The pure fact that a commit message about a GPL-ed work is
> distributed publicly does not necessarily trigger any licensing of the
> commit message itself.
Perhaps I am being silly at the moment, but wouldn't it suffice in this case
to put a statement in your commit message (I believe it can be automated)
stating that this message and the comitted data are licensed under the GPL?
As much as it would be an annoyance on the long run, it would effectively
protect every message from being abused by BitMover (or anyone else, for
that matter)*?

regards,

marek

* Note that I'm not implying BitMover or anyone else would claim ownership
of the mentioned message - I'm just following your thread of thinking.


Attachments:
(No filename) (1.12 kB)
(No filename) (189.00 B)
Download all attachments

2002-10-06 16:15:23

by Alan Cox

[permalink] [raw]
Subject: Re: BK MetaData License Problem?

On Sun, 2002-10-06 at 14:13, Ingo Molnar wrote:
> yes, but what i say is that BK *creates* a problem, (just like CVS would
> create similar problems) and the license clearly shows that BM is aware of
> and tries to handle part of this legal problem. (And given that the BK
> metadata is richer than eg. CVS, i suspect it will be a magnified problem
> later on.)

The onyl real problem BK creates here IMHO is its not possible to use BK
to maintain the true master tree of a piece of software, because like
everyone else Linux people get security reports/fixes which are set to
go out on specific dates by people like CERT. The BK rules prevent
anyone from checking a change into their BK tree until the embargo date,
which can be a pain in the butt.

Fortunately its not a problem to me because I don't use it 8)