Re: BK MetaData License Problem?

Re: BK MetaData License Problem?

[Manfred Spraul]

>                              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

Re: BK MetaData License Problem?

[Ingo Molnar]

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

Re: BK MetaData License Problem?

[Marek Habersack]

[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: BK MetaData License Problem?

[Manfred Spraul]

Russel King wrote:
 >
 > Therefore, I'd stronlg advise people in the EU not to use BK's
 > BK_USER/BK_HOST feature when importing patches.
 >
I think the user info is not critical: according to the GPL, you must 
tag your changes with date+name. By making a patch, you have agreed to 
the GPL terms, which means you have agreed that your name will be used 
together with the change.
I think the copyright laws require that, too.

But the GPL doesn't mandate a changelog...


Marek Habersack wrote:
> 
> 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?
 >

For example.
Or a sentence in the Licensing file, or whatever.("If you want to 
contribute to the development at www.kernel.org, then you must agree to 
the following conditions: You name will be used, your commit text will 
be used, your mail address will be published etc." No GPL conflict, you
are free to fork)

I agree with Ingo that there is the danger that without anything, it 
might happen that we'd have to throw away the changelogs [or that 
express permission for all existing entries will be needed, which is 
more or less equivalent]

--
	Manfred

Re: BK MetaData License Problem?

[Marek Habersack]

[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]

On Sun, Oct 06, 2002 at 06:26:18PM +0200, Manfred Spraul scribbled:
[snip] 
> Marek Habersack wrote:
> >
> >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?
> >
> 
> For example.
> Or a sentence in the Licensing file, or whatever.("If you want to 
> contribute to the development at www.kernel.org, then you must agree to 
> the following conditions: You name will be used, your commit text will 
> be used, your mail address will be published etc." No GPL conflict, you
> are free to fork)
I don't think that would suffice in this case. The problem is not in your or
anybody else's consent to the terms of GPL, but that the BK license doesn't
make it clear (as I understand) as to what is the legal status of the
metadata - i.e. what's the license that pertains to it. Also, this is not
BitMover's problem actually - thus the user, developer, would have to take
care to make a clear statement as to what the changelog license is. Or,
perhaps, BitMover could add to the license that the any software (i.e.
source code, documentation, log messages etc.) are accepted under the same
license as the, say, whole repository for the software unless otherwise
stated. Then only one file in the repository would suffice to make the
situation clear - it might be even done in a way that the bk tools display
the contents of this file (let's call it a "banner") once per "session" (by
default, of course) - to ascertain that anybody using the repository will
(or may) see the contents of the file. Maybe I'm rambling :), but that looks
like a sane solution to me (not being the BK user and not even liking it, I
don't know whether such a "motd" file is possible).

regards,

marek

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: BK MetaData License Problem?

[Alan Cox]

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)

Re: BK MetaData License Problem?

[Larry McVoy]

On Sun, Oct 06, 2002 at 05:29:07PM +0100, Alan Cox wrote:
> 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.

We could easily fix this at our end.  We already have mechanisms to not
publish openlogging trees, that's how we handle the research/edu waivers,
we could figure out some way to do the same for individual changesets.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

RE: BK MetaData License Problem?

[Hell.Surfers]

[-- Attachment #1: Type: text/plain, Size: 309 bytes --]

The file must be available for free, seperately if its not poss to include it, the source must say its a GPL, thats about it.

Cheers, Dean McEwan. Currently hacking KGI, which I don't understand, oh and ask me about OpenModemTalk...

On 	Sun, 6 Oct 2002 15:23:38 +0100 (BST) 	jbradford@dial.pipex.com wrote:

[-- Attachment #2: Type: message/rfc822, Size: 2183 bytes --]

From: jbradford@dial.pipex.com
To: mingo@elte.hu
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org
Subject: Re: BK MetaData License Problem?
Date: Sun, 6 Oct 2002 15:23:38 +0100 (BST)
Message-ID: <200210061423.g96ENcH3003097@darkstar.example.net>

> 
> until now the Linux kernel tree was distributed in a tarball that had a
> nice COPYING file in a very prominent spot. With BK the situation is
> different - and like i said in previous mails it's not BK's "fault", but
> BK's "effect" - and it's a situation that needs to be remedied, right?

Strictly speaking, isn't it a violation of the GPL for somebody to distribute a single file of any GPLed project, without attaching the COPYING file to it?

E.G. say somebody makes a CVS tree available via the web - you can download foobar.c without ever seeing the COPYING file.

John.
-
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/

Re: New BK License Problem?

[David S. Miller]

   From: Ingo Molnar <mingo@elte.hu>
   Date: Sun, 6 Oct 2002 13:04:39 +0200 (CEST)
   
   i'm also a bit worried about the legal status of commit messages posted
   via bkbits. Are they GPL-ed automatically, can we just take them and put
   them into a free-BK type server? We already have one precedent of a
   business entity abusing a free OS project and then suing it (and winning
   the suit), hindering the free OS's development for years.

Larry has stated many times over that he doesn't own our bits.

That is why once you extract content from the repository into some
other form (a patch with the change logs prepended, for example) he
doesn't care what you do with it.

He even said this twice today.

BK MetaData License Problem?

[Ingo Molnar]

On Sun, 6 Oct 2002, David S. Miller wrote:

>    i'm also a bit worried about the legal status of commit messages posted
>    via bkbits. Are they GPL-ed automatically, can we just take them and put
>    them into a free-BK type server? We already have one precedent of a
>    business entity abusing a free OS project and then suing it (and winning
>    the suit), hindering the free OS's development for years.
> 
> Larry has stated many times over that he doesn't own our bits.
> 
> That is why once you extract content from the repository into some other
> form (a patch with the change logs prepended, for example) he doesn't
> care what you do with it.

for years people sent emails to Linus that described patches and this was
not a big issue - Linus has kept 99% of the metadata in the source code.
But today the 'Linux kernel' is not the source code anymore, it's the
source code plus the BK metadata, which are separate bits, and this
creates a new situation.

the BKL.txt license currently says:

                             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.

what i'm worried about is the following issue: by default the data and the
MetaData is owned by whoever created it. You, me, other kernel developers.
We GPL the code, but the metadata is not automatically GPL-ed, just like
writing a book about the Linux kernel is is not necesserily GPL-ed.

It's not a big problem today because if you ask me then i'll tell you that
it's GPL-ed - but what will be the situation be in years? Couldnt
'BitMover or any other operator of an Open Logging server' argue that the
MetaData is owned by whoever created them, and is not covered by the GPL -
and only 'BitMover or any other operator of an Open Logging server' has
'permission to republish the Metadata'.

there are a number of legal cases in the US that involve around exactly
such issues (republishing of newpaper articles on the internet written by
independent journalists, republishing of the CD info database created by
anonymous users, etc.), and i'm sure we do not want the Linux kernel tree
to become another legal precedent.

it would be better if the license also said:

	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.)

this ensures that metadata attached to GPL-ed code is also licensed under
the GPL, and creates a clearly GPL-ed repository, both data and metadata.  
I'm 100% sure that the Linux commit messages are already valuable today,
and they will become a few orders more valuable in a few years.

btw., this is also the case with the emails Linus puts into BK commit info
- the email someone sends to Linus is _not_ GPL-ed by default.

(perhaps the solution is simple - i'd be really happy if it was.)

	Ingo

Re: BK MetaData License Problem?

[David S. Miller]

   From: Ingo Molnar <mingo@elte.hu>
   Date: Sun, 6 Oct 2002 14:04:42 +0200 (CEST)
   
   It's not a big problem today because if you ask me then i'll tell you that
   it's GPL-ed - but what will be the situation be in years? Couldnt
   'BitMover or any other operator of an Open Logging server' argue that the
   MetaData is owned by whoever created them, and is not covered by the GPL -
   and only 'BitMover or any other operator of an Open Logging server' has
   'permission to republish the Metadata'.
   
Anything you write is automatically copyrighted by you, even if you
don't specifically state it as such.

That is my basic understanding of copyright law.

BitMover et al. can't take your copyright powers away from you.

Re: BK MetaData License Problem?

[jbradford]

>    From: Ingo Molnar <mingo@elte.hu>
>    Date: Sun, 6 Oct 2002 14:04:42 +0200 (CEST)
>    
>    It's not a big problem today because if you ask me then i'll tell you that
>    it's GPL-ed - but what will be the situation be in years? Couldnt
>    'BitMover or any other operator of an Open Logging server' argue that the
>    MetaData is owned by whoever created them, and is not covered by the GPL -
>    and only 'BitMover or any other operator of an Open Logging server' has
>    'permission to republish the Metadata'.
>    
> Anything you write is automatically copyrighted by you, even if you
> don't specifically state it as such.

In most countries nowadays, this is correct.

> That is my basic understanding of copyright law.
> 
> BitMover et al. can't take your copyright powers away from you.

No, but since you own the copyright, you can give rights to the material to the operator of the Open Logging server.

Why don't we have a system whereby we automatically assign copyright to one person, (I.E. Linus), who can then assign us GPL rights in return, so that by submitting material to any server, we are not able to assign anything other than GPL rights to it's owner.

This is, I believe, although I could be wrong, the reason that the Free Software Foundation allows you to assign copyrights to them.

John.

Re: BK MetaData License Problem?

[jw schultz]

Please learn how to use the carriage return.

On Sun, Oct 06, 2002 at 01:18:10PM +0100, jbradford@dial.pipex.com wrote:
> > BitMover et al. can't take your copyright powers away
> > from you.
> 
> No, but since you own the copyright, you can give rights
> to the material to the operator of the Open Logging
> server.
> 
> Why don't we have a system whereby we automatically assign
> copyright to one person, (I.E. Linus), who can then assign
> us GPL rights in return, so that by submitting material to
> any server, we are not able to assign anything other than
> GPL rights to it's owner.

For good or ill by having the copyrights not held by one
person but instead held by so many is that no-one can
arbitrarily change the license or relicense under other
terms without the permission of all of the copyright
holders.  However much you might trust Linus, do you want to
trust his grandchildren?  Or the foundation after corporate
interests have subverted it?

> This is, I believe, although I could be wrong, the reason
> that the Free Software Foundation allows you to assign
> copyrights to them.

The reason to assign your copyright to the FSF is to give
them standing in court to defend the copyright.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: BK MetaData License Problem?

[Ingo Molnar]

On Sun, 6 Oct 2002, David S. Miller wrote:

> Anything you write is automatically copyrighted by you, even if you
> don't specifically state it as such.
>
> That is my basic understanding of copyright law.
> 
> BitMover et al. can't take your copyright powers away from you.

yes, this is my understanding as well, but the BK license can require you
to license your bits in exchange for allowing you to use the BK product.  
It already does require 'republishing rights' for the metadata bits in
fact. (which is a perfectly fair requirement - Larry needs this assurance
to be able to host bkbits in a legally safe way.)

the issue is that in the BK repository data and metadata is distinctly
separate. The Linux kernel is fully functional without any of the
metadata, and the GPL only covers the Linux kernel.

And i'd like note it that this situation is not "BK's fault" in any way,
it's simply the thing that copyright law says about not explicitly
licensed bits. But it's a situation created by BK, and it could be
eliminated by the BK license requiring the metadata to be licensed under
the same conditions the data itself is licensed. Or we could put this into
the Linux kernel license. (which OTOH might violate the GPL.)

i'm sure this issue was raised before - eg. what is the legal standing of
the commit messages of the BSD kernels?

	Ingo

Re: BK MetaData License Problem?

[Daniel Berlin]

On Sun, 6 Oct 2002, David S. Miller wrote:

>    From: Ingo Molnar <mingo@elte.hu>
>    Date: Sun, 6 Oct 2002 14:04:42 +0200 (CEST)
>    
>    It's not a big problem today because if you ask me then i'll tell you that
>    it's GPL-ed - but what will be the situation be in years? Couldnt
>    'BitMover or any other operator of an Open Logging server' argue that the
>    MetaData is owned by whoever created them, and is not covered by the GPL -
>    and only 'BitMover or any other operator of an Open Logging server' has
>    'permission to republish the Metadata'.
>    
> Anything you write is automatically copyrighted by you, even if you
> don't specifically state it as such.
> 
> That is my basic understanding of copyright law.
Correct.

Registration, for the most part, only affects remedies.

There are, as one would expect, weird corner cases and whatnot (bad 
engineering :P).

But the short of it is that registration gives you the ability 
to get statutory damages and attorneys fees. Without registering, you can 
only get actual damages.
--Dan

Re: BK MetaData License Problem?

[Russell King]

On Sun, Oct 06, 2002 at 02:04:42PM +0200, Ingo Molnar wrote:
> the BKL.txt license currently says:
> 
>                              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.

IANAL, but this is just to protect BitMover against _you_ suing them for
publishing your log entries.  Completely sensible.  They're not claiming
copyright over the metadata.  They're not claiming any license over the
metadata.

> what i'm worried about is the following issue: by default the data and the
> MetaData is owned by whoever created it. You, me, other kernel developers.
> We GPL the code, but the metadata is not automatically GPL-ed, just like
> writing a book about the Linux kernel is is not necesserily GPL-ed.

It doesn't say "you transfer all your IP and soul to bitmover."

> it would be better if the license also said:
> 
> 	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 doesn't explicitly allow bitmover to put the metadata up in public
view, which would mean the openlogging stuff will leave bitmover wide
open for legal action.

> btw., this is also the case with the emails Linus puts into BK commit info
> - the email someone sends to Linus is _not_ GPL-ed by default.
> 
> (perhaps the solution is simple - i'd be really happy if it was.)

The exact same problem applies to pre-BK Linus and Alan, and whoever
else produces a change log that contains information produced by a
third party.

Does Linus and Alan have an implicit right to republish the documentation
that was sent to them with the patch?  Does Red Hat have the right to
republish comments placed into the bugzilla database by external users
of that service?  Does Debian have a right to reproduce emails on their
website which have been sent to foo@bugs.debian.org (or whatever the
address is?)

There is a _big_ question about reproducing peoples personal information
in the EU (eg, email addresses) on web sites, even archives of public
mailing lists.  The exim mailing lists were recently threatened with
legal action over this very point, and there was talk at one point about
having to shut down the whole exim.org site because of this.  The end
result of this debarcle was various posts were deleted from the list
archive.

So, this isn't a BK problem.  Its a community problem.

Please don't shovel shit into other peoples back yards.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: BK MetaData License Problem?

[Ingo Molnar]

On Sun, 6 Oct 2002, Russell King wrote:

> > it would be better if the license also said:
> > 
> > 	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.
> 
> That doesn't explicitly allow bitmover to put the metadata up in public
> view, which would mean the openlogging stuff will leave bitmover wide
> open for legal action.

(this is why i said 'also' in the above sentence. It would be in addition
to the existing (and sensible) requirement for BM to be able to republish
the commit logs.)

> > btw., this is also the case with the emails Linus puts into BK commit info
> > - the email someone sends to Linus is _not_ GPL-ed by default.
> > 
> > (perhaps the solution is simple - i'd be really happy if it was.)
> 
> The exact same problem applies to pre-BK Linus and Alan, and whoever
> else produces a change log that contains information produced by a third
> party.

with the difference that the changelog was a few orders of magnitude less
of an infrastructure element. Plus if you read those changelogs you'll see
that it's 100% written by Alan or Linus - in 99% of the cases it just
describes what the patch does, and in the remaining 1% it quotes a few key
sentences that can be considered fair use. Ie. the ChangeLog was owned by
Alan and Linus. [it would be a bit more robust if the ChangeLogs would be
part of the kernel repository, that would make them covered by the GPL.]

> Does Linus and Alan have an implicit right to republish the
> documentation that was sent to them with the patch? [...]

yes, as long as the documentation comes with the patch and is part of the
kernel tree, which the patch derives, and which kernel tree has a certain
'COPYING' file in the top directory. Patches *are* actively monitored for
conflicting licenses in individual files, and occasionally we had to
remove files.

> [...] The exim mailing lists were recently threatened with legal action
> over this very point, and there was talk at one point about having to
> shut down the whole exim.org site because of this. [...]

> So, this isn't a BK problem.  Its a community problem.

it *is* a BK problem caused by BK becase now this whole can of worms got
silently exported to the kernel tree, and while BM itself is safe via its
license, the kernel tree 'as a whole' is exposed.

until now the Linux kernel tree was distributed in a tarball that had a
nice COPYING file in a very prominent spot. With BK the situation is
different - and like i said in previous mails it's not BK's "fault", but
BK's "effect" - and it's a situation that needs to be remedied, right?

	Ingo

Re: BK MetaData License Problem?

[Russell King]

On Sun, Oct 06, 2002 at 04:10:46PM +0200, Ingo Molnar wrote:
> it *is* a BK problem caused by BK becase now this whole can of worms got
> silently exported to the kernel tree, and while BM itself is safe via its
> license, the kernel tree 'as a whole' is exposed.

Actually, the more I think about it, the more you are correct.

The way BK openlogging works, it exports personal information out of the
EU.  This is explicitly prohibited under EU law, unless the owner of that
personal information has explicitly granted that it may be used in that
manner.

Therefore, I'd stronlg advise people in the EU not to use BK's BK_USER/
BK_HOST feature when importing patches.

The following question remains though: peoples names are "personal
information."  Personal information falls under the UK data protection
act, which is one implementation of the EU law.  This means that unless
Alan has an explicit agreement with every person who has sent him a patch,
he has no right to publish the list of names in his change log, especially
when that information travels leaves the EU.

This is certainly an interesting problem.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: BK MetaData License Problem?

[Alan Cox]

On Sun, 2002-10-06 at 15:08, Russell King wrote:
> The way BK openlogging works, it exports personal information out of the
> EU.  This is explicitly prohibited under EU law, unless the owner of that
> personal information has explicitly granted that it may be used in that
> manner.

You can give anyone you like your -own- personal info. That is your
problem. What you can't do is do that with someone elses.


If it bothers you start a project in some free country that is about
cracking DRM schemes, use bitkeeper, document profusely in commit
messages and wait ;)

Re: BK MetaData License Problem?

[jbradford]

> 
> On Sun, 2002-10-06 at 15:08, Russell King wrote:
> > The way BK openlogging works, it exports personal information out of the
> > EU.  This is explicitly prohibited under EU law, unless the owner of that
> > personal information has explicitly granted that it may be used in that
> > manner.
> 
> You can give anyone you like your -own- personal info. That is your
> problem. What you can't do is do that with someone elses.

That's not the issue he is raising.  What he is saying is that say I make a patch and E-Mail it to you, with a change log entry that says, "John Bradford did this 1337 patch", and then you pass it on to somebody outside the EU, then you've violated the EU regulation.

John.

Re: BK MetaData License Problem?

[Marek Habersack]

[-- Attachment #1: Type: text/plain, Size: 686 bytes --]

On Sun, Oct 06, 2002 at 05:58:26PM +0100, Alan Cox scribbled:
> On Sun, 2002-10-06 at 15:08, Russell King wrote:
> > The way BK openlogging works, it exports personal information out of the
> > EU.  This is explicitly prohibited under EU law, unless the owner of that
> > personal information has explicitly granted that it may be used in that
> > manner.
> 
> You can give anyone you like your -own- personal info. That is your
> problem. What you can't do is do that with someone elses.
Yes, but giving that info to anyone doesn't grant them the permission to
redistribute the information. I think that might be the problem Russel is
concerned about.

regards,

marek

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: BK MetaData License Problem?

[jbradford]

> 
> until now the Linux kernel tree was distributed in a tarball that had a
> nice COPYING file in a very prominent spot. With BK the situation is
> different - and like i said in previous mails it's not BK's "fault", but
> BK's "effect" - and it's a situation that needs to be remedied, right?

Strictly speaking, isn't it a violation of the GPL for somebody to distribute a single file of any GPLed project, without attaching the COPYING file to it?

E.G. say somebody makes a CVS tree available via the web - you can download foobar.c without ever seeing the COPYING file.

John.

Re: BK MetaData License Problem?

[Linus Torvalds]

[ Different issue, and slightly off-topic ]

On Sun, 6 Oct 2002, Ingo Molnar wrote:
> 
> until now the Linux kernel tree was distributed in a tarball that had a
> nice COPYING file in a very prominent spot. With BK the situation is
> different - and like i said in previous mails it's not BK's "fault", but
> BK's "effect" - and it's a situation that needs to be remedied, right?

If this is a concern, it actually appears that BK has the capability to
"enforce" a license, in that I coul dmake BK aware of the GPL and that
would cause BK to pop up a window saying "Do you agree to this license"  
before the first check-in by a person (the same way it asked you whether 
you wanted to allow openlogging).

Do people feel that would be a good idea? I actually dismissed it when 
Larry talked about it, because I felt people might take it as another "too 
much BK in your face", even though the license would be the _Linux_ 
license, not the BK one.

		Linus

Re: BK MetaData License Problem?

[Ingo Molnar]

On Sun, 6 Oct 2002, Linus Torvalds wrote:

> If this is a concern, it actually appears that BK has the capability to
> "enforce" a license, in that I coul dmake BK aware of the GPL and that
> would cause BK to pop up a window saying "Do you agree to this license"  
> before the first check-in by a person (the same way it asked you whether
> you wanted to allow openlogging).

sounds interesting - is it difficult to enabled it, just to see how much
impact it has on daily work?

> Do people feel that would be a good idea? I actually dismissed it when
> Larry talked about it, because I felt people might take it as another
> "too much BK in your face", even though the license would be the _Linux_
> license, not the BK one.

well, if it can be made a one-time thing, ie. something like: 'from now on
if you commit in the repository and distribute the changes then all those
changes and related BK metadata are licensed under the GPL', that would be
less intrusive i guess?

	Ingo

Re: BK MetaData License Problem?

[Larry McVoy]

On Sun, Oct 06, 2002 at 12:39:48PM -0700, Linus Torvalds wrote:
> 
> [ Different issue, and slightly off-topic ]
> 
> On Sun, 6 Oct 2002, Ingo Molnar wrote:
> > 
> > until now the Linux kernel tree was distributed in a tarball that had a
> > nice COPYING file in a very prominent spot. With BK the situation is
> > different - and like i said in previous mails it's not BK's "fault", but
> > BK's "effect" - and it's a situation that needs to be remedied, right?
> 
> If this is a concern, it actually appears that BK has the capability to
> "enforce" a license, in that I coul dmake BK aware of the GPL and that
> would cause BK to pop up a window saying "Do you agree to this license"  
> before the first check-in by a person (the same way it asked you whether 
> you wanted to allow openlogging).

Yes, but you'd want to make sure that you stated that your license
extended to the BK metadata.  In our opinion, only you as the creator
of the repository gets to make that rule but you certainly can, that's
one of the reasons we put that clause in there.

By the way, the way this code works in bk-3.0 is that it saves a md5sum or
some sort of strong hash of the license in question and it will ask you
only once, assuming you are using the same home directory.  It will ask
you again if the license changes, that's what the hash is for.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BK MetaData License Problem?

[Ingo Molnar]

On Sun, 6 Oct 2002, Larry McVoy wrote:

> Yes, but you'd want to make sure that you stated that your license
> extended to the BK metadata.  In our opinion, only you as the creator of
> the repository gets to make that rule but you certainly can, that's one
> of the reasons we put that clause in there.

so in theory it's perfectly possible to 'link' the data's and metadata's
license via BKL.txt - after all you already added licensing rules for the
metadata into the BK license, for the purposes of OpenLogging.

It would also perhaps make your position slightly more robust - besides
you already having the right to 'republish' metadata [which is a term not
directly defined in the license], you'd also have all the rights that come
through the license of the data it describes - whatever that is worth.

There are some problems like the fact that metadata might describe
multiple pieces of data that might have different licenses, the solution
would be to license metadata under every license that data is licensed
under - if there's any. This would be in addition to the already existing
republishing rights for OpenLogging.

> By the way, the way this code works in bk-3.0 is that it saves a md5sum
> or some sort of strong hash of the license in question and it will ask
> you only once, assuming you are using the same home directory.  It will
> ask you again if the license changes, that's what the hash is for.

this sounds really nice and unintrusive, how does one enable it? Is this
BK_FORCE, or something else? I cannot find any reference to this in 'bk
helptool'.

	Ingo

Re: BK MetaData License Problem?

[Larry McVoy]

> so in theory it's perfectly possible to 'link' the data's and metadata's
> license via BKL.txt - after all you already added licensing rules for the
> metadata into the BK license, for the purposes of OpenLogging.

It is our position and we believe that it is supported by the BKL license
that it is the right and authority of the original creator of the project
to enforce any license they so wish.  If Linus wants to make it clear
that if you make changesets using BK that the checkin comments are also
GPLed, that's his right.  That's our intent and that's what we believe
the license says.  See clause 3(b).

> > By the way, the way this code works in bk-3.0 is that it saves a md5sum
> > or some sort of strong hash of the license in question and it will ask
> > you only once, assuming you are using the same home directory.  It will
> > ask you again if the license changes, that's what the hash is for.
> 
> this sounds really nice and unintrusive, how does one enable it? Is this
> BK_FORCE, or something else? I cannot find any reference to this in 'bk
> helptool'.

That's because we haven't shipped bk-3.0 yet, we expect to do so this
week.  The license clause has been there for a long time, these rules are
part of the BKL.  However, we only recently added the "click to accept"
stuff for the extra license and the lawyers tell us that is required to
be enforceable.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BK MetaData License Problem?

[Jes Sorensen]

>>>>> "Russell" == Russell King <rmk@arm.linux.org.uk> writes:

[snip]

Russell> There is a _big_ question about reproducing peoples personal
Russell> information in the EU (eg, email addresses) on web sites,
Russell> even archives of public mailing lists.  The exim mailing
Russell> lists were recently threatened with legal action over this
Russell> very point, and there was talk at one point about having to
Russell> shut down the whole exim.org site because of this.  The end
Russell> result of this debarcle was various posts were deleted from
Russell> the list archive.

This whole metadata discussion leads me to another question which has
been bothering me about BK's 'Open' Logging and hosted trees for a
while. What is happening to all the infomation that BitMover is (or
could gather) from people accessing the Open Logging site as well as
the hosted repositories? There could be a lot of marketing value in
this if BM decided to abuse it. Ie. some marketing manager could
decide to run advertisement campaigns listing names of known
individuals using the software.

I just checked http://www.bitkeeper.com/Sales.Licensing.Free.html and
the word 'privacy' does not occur on that page at all.

While I understand BK need for a license to publish the metadata, then
I'd be a lot more comfortable with a written guarantee restricting the
use to the logging site or similar.

Jes

Re: BK MetaData License Problem?

[Larry McVoy]

> I just checked http://www.bitkeeper.com/Sales.Licensing.Free.html and
> the word 'privacy' does not occur on that page at all.
> 
> While I understand BK need for a license to publish the metadata, then
> I'd be a lot more comfortable with a written guarantee restricting the
> use to the logging site or similar.

We're happy to say we won't sell or publish the material in any way 
*other* than the openlogging web pages.  I'm not sure what good that
does, the cat is out of the bag on the web pages so I can't imagine 
a market for the data which is freely available, but if you are worried, 
propose some language, we'll shove it in the above web page if the
language is reasonable (i.e., doesn't preclude openlogging itself).
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BK MetaData License Problem?

[Alan Cox]

On Sun, 2002-10-06 at 18:17, Jes Sorensen wrote:
> This whole metadata discussion leads me to another question which has
> been bothering me about BK's 'Open' Logging and hosted trees for a
> while. What is happening to all the infomation that BitMover is (or
> could gather) from people accessing the Open Logging site as well as
> the hosted repositories? There could be a lot of marketing value in
> this if BM decided to abuse it. Ie. some marketing manager could
> decide to run advertisement campaigns listing names of known
> individuals using the software.

They can do that anyway. The metadata is public. Nobody even needs to
bother Larry about it, any more than folks who trawl it for spam email
targets do

Re: BK MetaData License Problem?

[Jes Sorensen]

>>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

Alan> On Sun, 2002-10-06 at 18:17, Jes Sorensen wrote:
>> This whole metadata discussion leads me to another question which
>> has been bothering me about BK's 'Open' Logging and hosted trees
>> for a while. What is happening to all the infomation that BitMover
>> is (or could gather) from people accessing the Open Logging site as
>> well as the hosted repositories? There could be a lot of marketing
>> value in this if BM decided to abuse it. Ie. some marketing manager
>> could decide to run advertisement campaigns listing names of known
>> individuals using the software.

Alan> They can do that anyway. The metadata is public. Nobody even
Alan> needs to bother Larry about it, any more than folks who trawl it
Alan> for spam email targets do

Whether or not it's legal to post it is something else, that doesn't
make it right. Besides, in many countries you can't put someone's name
up on a billboard unless they have agreed to it, or if they are
considered a 'public person' or something to that extend. Of course
with the totally broken privacy system in the US, and Canada for that
safe ;-(, I am sure you can publish whatever you want.

I have no issue with a company like BM or anyone else using anonymous
statistics for advertisement, but I'd be royally pissed if I had my
name on someone's leaflet without having given my written permission
first. Hence the suggestion for a privacy clause in the license.

Cheers,
Jes

Re: BK MetaData License Problem?

[Larry McVoy]

On Sun, Oct 06, 2002 at 01:45:04PM -0400, Jes Sorensen wrote:
> I have no issue with a company like BM or anyone else using anonymous
> statistics for advertisement, but I'd be royally pissed if I had my
> name on someone's leaflet without having given my written permission
> first. Hence the suggestion for a privacy clause in the license.

OK, so find some legal language that does what you want and send it to me.
If it doesn't prevent the openlogging web pages or the bkbits.net web pages
and bkd ports, we'll add it.  We don't do a darn thing with that info,
I hear, understand, and agree with your concern, I just need some sample
language that threads the needle.

All the language I've seen would prevent us from displaying the web pages.
That's no good.  We can't say we won't redistribute because the web pages
are definitely redistribution.  We can say we won't sell it if that helps.
If we say we can't aggragate it then we can't do stuff like this:

	http://www.bitkeeper.com/stats/linux-csets-L3W.png

which is something we'd like to make part of bkbits.net.  And I think it's
something that the community wants.

So what's the language that says we won't do the spam style crud that you 
are legitimately afraid of but does allow the useful stuff for the 
community?  It's good to handle this now, if we can get it nailed down
to something reasonable it's hard for BitMover the corporation to lose
its mind and change things later, you can argue fair use or breach of
promise or one of those lovely legal terms, I don't remember which 
covers this, but I know there is one.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm