BK MetaData License Problem?
Quoted 6 lines
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.
Quoted 6 lines
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
Quoted 2 lines · Manfred Spraul
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.
Quoted 5 lines
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
On Sun, Oct 06, 2002 at 03:13:24PM +0200, Ingo Molnar scribbled:
Quoted 6 lines · Manfred Spraul
Quoted 3 lines
Where is the problem? This asks for a permission, not for exclusive rights.
[snip]
Quoted 6 lines
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.
Quoted 5 lines · Ingo Molnar
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)
Quoted 7 lines · Alan Cox
Quoted 5 lines · Ingo Molnar
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.)
Quoted 6 lines
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.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 4 lines · Russel King
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...
Quoted 5 lines · Marek Habersack
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
On Sun, Oct 06, 2002 at 06:26:18PM +0200, Manfred Spraul scribbled:
[snip]
Quoted 8 lines
Quoted 6 lines · Marek Habersack
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?
Quoted 6 lines
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