> Actually it's not that simple. With the free BK license it's not _your_ > choice that affects validity; It's the choice of any person at your > company deciding for everyone else. So if one OSDL employee uses the > free BK licence, *nobody else* at OSDL can work on an SCM, even at home > in their spare time. Technically, if any one of the other 10,000 people > at my university work on an SCM, I can't use it either since they pay > me. I try to bury my head in the sand and think that they aren't. In > reality however, I can't vouch for what the other 9,999 people are > doing.
The reason it is worded that way is so that we avoid the situation where one guy is doing the work on $SCM and the other guy is sitting there running BK commands in order to reverse engineer BK.
We aren't going to come make a fuss if you are using BK and some other guy is tinkering with CVS, we're not unreasonable people. On the other hand, that doesn't give you carte blanche, if your officemate or friend is working on a BK replacement and you are helping him, yes, we will likely make a fuss. -- --- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
> The reason it is worded that way is so that we avoid the situation where > one guy is doing the work on $SCM and the other guy is sitting there > running BK commands in order to reverse engineer BK.
I don't think you can stop that from happening, legally.
On Thu, Oct 28, 2004 at 04:06:20PM +0200, Xavier Bestel wrote: > Le jeu 28/10/2004 ?? 15:53, Larry McVoy a ??crit :
> > The reason it is worded that way is so that we avoid the situation where > > one guy is doing the work on $SCM and the other guy is sitting there > > running BK commands in order to reverse engineer BK.
> I don't think you can stop that from happening, legally.
Since you haven't paid for the product, copyright law applies and that's quite different than contract law. You get a certain set of rights, which vary worldwide, when you buy something. Copyright is far more restrictive.
"Fair use" != "reverse engineering" in any venue so far as I know.
> Since you haven't paid for the product, copyright law applies and > that's quite different than contract law. You get a certain set > of rights, which vary worldwide, when you buy something. Copyright > is far more restrictive.
> "Fair use" != "reverse engineering" in any venue so far as I know.
> As always, IANAL, so contact yours for clarification.
As I understand the law, at least in the United States, you have the exact same rights whether you buy the product or get it for free, so long as you acquire it legally. This includes the right to use the product as it is normally used. Otherwise, I could write a poem, put it up on billboards, and then try to sue everyone whose eyes passed over it. This is legally enshrined in the doctrine of "first sale", which despite its name applies to any legal acquisition.
It's not clear whether shrink wrap or other licenses can reduce this basic right to use that which one lawfully acquires. Some have pointed to various cases (such as ProCD v. Zeidenberg), but all the cases I have seen have differed from the shrinkwrap/copyright issue in at least one key respect.
David Schwartz wrote: > As I understand the law, at least in the United States, you have the exact > same rights whether you buy the product or get it for free, so long as you > acquire it legally.
But there's the rub: acquiring it legally (for free) requires acceptance of the license terms. If you do not accept the terms, or accept them but later take actions which violate the terms you accepted, you can no longer say that you "acquired it legally". You have violated the terms of the agreement between the two parties, and the party that owns the copyright to the product in question has every right to take action against you, if warranted.
You are correct in saying that the mere act of money changing hands does _not_ give you any rights that you wouldn't have gotten for free, presuming that the license being offered in both cases gives you the same rights. In the case of BitKeeper, it does not. The free and for-pay licenses give the licensee different rights. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Thu, Oct 28, 2004 at 08:10:04AM -0700, Larry McVoy wrote: > On Thu, Oct 28, 2004 at 04:06:20PM +0200, Xavier Bestel wrote: > > Le jeu 28/10/2004 ?? 15:53, Larry McVoy a ??crit :
> > > The reason it is worded that way is so that we avoid the situation where > > > one guy is doing the work on $SCM and the other guy is sitting there > > > running BK commands in order to reverse engineer BK.
> > I don't think you can stop that from happening, legally.
> Since you haven't paid for the product, copyright law applies and > that's quite different than contract law. You get a certain set > of rights, which vary worldwide, when you buy something. Copyright > is far more restrictive.
US copyright law isn't the only one in the world...
> "Fair use" != "reverse engineering" in any venue so far as I know.
German copyright law explicitely allows every person allowed to use a program to observe and test this program for getting the ideas behind the program as long as you can do this through normal usage of the program.
If you aren't building a similar program but require disassembling for interoperability, this is explicitely allowded.
According to German copyright law, any licence clauses that violate these rules are void [1].
Note that German copyright lay doesn't differentiate whether you paid or not - it only requires that you allowed to use the program.
> As always, IANAL, so contact yours for clarification.
These are paragraphs 69d(3), 69e and 69g(2) of German copyright law - IANAL, but the text of the law is pretty unambiguous.
cu Adrian
[1] the clauses are void, not the licence itself
- --
"Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
iD8DBQFBgU+zmfzqmE8StAARAv9PAJ9klSxSbl8zi9kKv2MI96oq0r0pggCdHTDv tMik8nm1bVB5seygLyQfmgc= =kTsy -----END PGP SIGNATURE----- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Iau, 2004-10-28 at 20:38, Kevin P. Fleming wrote:
> But there's the rub: acquiring it legally (for free) requires acceptance > of the license terms. If you do not accept the terms, or accept them but > later take actions which violate the terms you accepted, you can no > longer say that you "acquired it legally". You have violated the terms
Thats not actually the case. The law in countries writes in additional implicit clauses you cannot avoid and also forbids clauses. Those clauses vary by country but you'd find in most of the world that a clause like
3. Not to be used by Women except for payment of a $500 additional tech support fee
> "Fair use" != "reverse engineering" in any venue so far as I know.
Reverse engineering is enshrined in EU law as a right (although this started due to abuse by car companies not for computing). While people jump up and down and point to that its not always clear you can do so for the purposes of cloning rather than interoperability.
Ie its one thing to reverse engineer BK to make a BK->Subversion tool but quite another to reverse engineer it to reimplement BK
(leaving aside that all the patch files are publically grabbable and every patch Linus sends goes out to a mailing list so it would be a rather hard work way of doing it)
On Wed, 27 Oct 2004, Larry McVoy wrote: > Warning: long message. Reason you should read it: because I show you > how you can independently verify, without a BK license, that Roman is > spreading FUD. So read this, check it out, you'll see that this is > all Roman's nonsense. If you already believe that, you can skip this > but there is a lot of useful BK2CVS data in this message.
I have to apologize, there is a little more data in cvs repository, but it doesn't change in any way what I was trying to tell Linus. It seems I made another mistake, I have to apologize for. I didn't realize that the kernel repository is a private party and you are the bully at the door. Well, it seems I'm not cool enough and I deeply apologize for bothering you guys.
All I have left to say is that, what I said before is everything but nonsense and I invite everyone to verify what I say and whether Larry really tells the complete story. So for example the 56% number is very real:
$ rlog ChangeSet,v | grep BKrev: | wc -l 23461
The number of the changesets in the bk repository is around 53000, this is the difference I talked about and it's real. What does this mean? The bk repository contains around 53000 snaphots of kernel development history, 44% of these snapshots can be restored via bkcvs. So where is the rest?
bk preserves the history nonlinearly, e.g. something like this:
This means someone cloned the repo at t1 and committed some changes at t1.1 and t1.2, in the meantime the changes t2, t3, t4 were applied to the parent repo and at t5 the changes from the cloned repo were merged.
CVS by itself can't of course represent this history, so it only contains the changes from t1, t2, t3, t4, t5, the snapshots t1.1, t1.2 cannot be restored anymore reliably from bkcvs, one can only get the merged changeset t5. As it's rather likely that every commit changes different files, one can actually get 100% of the file changes, but you still have in this case only 71% percent of the commits. Why would anyone be interested in the remaining 29%? Only with the complete information one go back to any previous snapshot, so if e.g. something went wrong during the merge in t5, it's quite easy to tell that it still worked at t4 and t1.2. Without the extra information one only knows that it went wrong after t4. Applied to bkcvs this means a problem can be located with a precision of 44% and this number is still quite high as I mentioned in the last mail. The more bk users the less this number becomes. Let's say 5 people set up a repo with 20 changes each to let Linus pull from them, instead of sending them to Andrew, so they can end up as just 24 commits in bkcvs. The little grepping I did on ChangeSet,v seems to backup my theory (if someone knows how to get real numbers, I'd love to hear them), I looked at pulls from the net, scsi and Greg's repo and most of them are indeed merged into a single bkcvs commit.
On the other hand Larry's 96% number sounds impressive, but it's the less interesting one, if some of the commit information is missing, it's nontrival to put the file changes in the correct context. In the example above this means the individual file patches of t1.1 and t1.2 have to be matched to the corresponding splitted changelog of t5, it's anything but trivial, if it's possible at all and it doesn't provide the information that t1.1 has to be applied on top of t1. This means that it's often possible to extract a changeset manually, but doing it automatically is rather impractical and not worth the trouble.
Now it's theoretically possible to extract data via bkweb, but I (and I hope not only me) still remember what happened last time Andrea tried that, so I haven't actually looked into it too deeply. It certainly is possible to extract all commits, the problem starts with putting them into a context. The repository information in bkweb is a bit filtered (e.g. empty merges), which are of only little interest to the human viewer, but that makes it interesting to reliably tell where a branch starts and end. Without further research I can only guess, whether that information is deducible or has to be extrapolated.
Finally the commit mails have really only informational value, as they lack any usable context.
Well, that's about it about the usefulness of the public available information. So if anyone could tell me, what exactly is FUD about this, I certainly would love to know it.
So why do I actually care about this data? For one I have that weird idea that the goals of a free software project should be reflected in its development process, that I actually get insulted for this is a truly strange experience. I would really like to have access to this data, it's data I contributed to, it's data I care about and which I'm working on a lot of time anyway, but unfortunately full access to this data is restricted to a private club. Consequently this means that there will never be a gateway to easily exchange data, if synchronization is limited to bkcvs, this will cause unnecessary conflicts. If the information has to go via scm->patch->bk->bkcvs->scm, some information obviously get lost and the scm can only guess whether the information has been merged or not. IOW an alternative scm will always be in a disadvantage...
Anyway, I will now go away and play with the other uncool kids.
> Note that German copyright lay doesn't differentiate whether you paid > or not - it only requires that you allowed to use the program.
Sure, but you aren't allowed to use it if you are going to do this. That's pretty unambiguous as well and we think we can make it stick, or at least that's what the lawyers have told me.
It's most unfortunate that people take the position "hey, I can rip off your stuff, here's the law that says so" when it is something we gave them to use for free. All that means is that we stopped improving the free version and put all the effort into the commercial version because we just can't afford the risk exposure.
All of the "we can do whatever we want" statements may well be true, I don't really know and don't really care. But the fact that people take the attitude that it's OK to bite the hand that feeds you is doing nothing but shooting yourself in the foot. What are we supposed to do in the face of "I can rip you off, here's the law"? Give you more stuff to copy? -- --- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
