LWN: Comments on "BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)"

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

sammythesnake — Tue, 04 Jun 2024 15:44:39 +0000

I've not read the BK licence (and lack the urge to try to track it down) but there would be some questions to ask about the "Termination" terms - depending on how they were worded, the restrictions might end when Larry terminated the license.

I'd argue that wording the terms in that way would be a mistake from the POV of BitMover, but wouldn't massively surprise me.

There's also the question of enforceability of such terms, depending on jurisdiction (and whims of process/judges etc.) it might be struck as unreasonable...

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

linuxrocks123 — Fri, 31 May 2024 18:39:20 +0000

Tridgell didn't release his BitKeeper client AT THAT TIME. Tridgell _DID_ release his BitKeeper client once he was done writing it.

https://en.wikipedia.org/wiki/SourcePuller

Obviously, he wasn't sued.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

skx — Fri, 31 May 2024 13:33:57 +0000

Ironically Bitkeepr later went open source - as covered here https://lwn.net/Articles/686986/

I'm sure they had customers/paying users in the early days, but it seemed like the project never really took off outside a few places, and of course later git took over the world eclipsing almost all other systems. Mercurial is still limping along, but things like darcs, bzr, cvs, svn, are all obsolete these days.

One thing left out .... BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

tgall — Thu, 30 May 2024 15:35:55 +0000

Nice to see the blog post.

There was a post I had made to LKML looking at the bit keeper license and pointing out problematic bits, which then set off a firestorm. Bummer that detail was left off the blog post.

https://lore.kernel.org/all/Pine.LNX.4.44.0210061410540.5...

That little bit in the license that kept various open source developers from using BitKeeper just because they working for a company that made SCM software was no small problem.

Alls well that ends well and thankfully git was and continues to be an important part of the open source revolution.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

Wol — Thu, 30 May 2024 15:32:35 +0000

> In the end, McVoy technically won.

I read some of the stuff. In it, I think it's McVoy himself that says that he and Sun both fell victim to the same problem - it's hard to surrender a flowing profit stream, even if you can see disaster looming ...

When the time came, he walked the walk. Because he no longer had any choice ...

Cheers,
Wol

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

farnz — Thu, 30 May 2024 12:40:49 +0000

you need a robust set of soft skills to participate in the software industry

I want to give this more visibility, because it's something I see many software developers completely ignore; once a project gets large enough to have multiple developers working on it, your soft skills to get the other developers to work with you, not against you, often outweigh your coding ability. It's better for a project to have 3 developers each splitting their time 50:50 between coordinating work to avoid conflicts and actually coding, than to have 3 developers spending 100% of their time coding, but each undoing the work of the other two to make their code work.

Even at his worst, Linus understood this; his role in Linux for a very long time has been to coordinate developers so that there's a coherent project, rather than to cut code.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

flussence — Wed, 29 May 2024 23:17:05 +0000

In the end, McVoy technically won. He got exactly what he bargained for; nobody dared to tread on him or his crown jewels again, the smelly hippies loitering around his business went away, and whatever became of BitMover after that was entirely his own responsibility. Given that we only hear of his work in museum exhibits nowadays I can make a good guess without looking it up.

He was wrong on the assertion that it was an “open source community problem” that compelled him to burn bridges — the open source community has absolutely no qualms about playing and paying into Microsoft's proprietary ecosystem, to the point where GitHub now dominates the planet in a very real sense. They even let their direct competitors use their service for free. (Microsoft!! Remember what we thought of *them* at the time?)

Unless your audience is mostly government and military, you need a robust set of soft skills to participate in the software industry - those are not things you can tabulate in a spreadsheet, and if you don't make time for them your numbers will end up disastrous and you won't understand *why*, because an entire concept is missing from your vocabulary. Why point this out twenty years after the events in the article? Because organisations involved in FOSS today are still making the same mistake!

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

geert — Wed, 29 May 2024 18:14:37 +0000

https://lore.kernel.org/all/tnxaco48hj6.fsf@arm.com/ has:

| > I was wondering if working on git, is in anyway, in violation of the
| > Bitkeeper license, which states that you cannot work on any other SCM
| > (SCM-like?) tool for "x" amount of time after using Bitkeeper ?
|
| That's valid for the new BK license only which probably wasn't
| accepted by Linus.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

james — Wed, 29 May 2024 13:36:51 +0000

Can I point you to this earlier discussion on the subject?

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

brouhaha — Wed, 29 May 2024 02:08:29 +0000

A very brief search did not turn up a copy of the "Community" BitKeeper License that was in effect at the time, but if the Wikipedia synopsys of it is correct, that a developer using BitKeeper under that license was not allowed to work on a competing tool for the dration of their usage of BitKeeper plus one year, then how did Linus writing Git not violate his BitKeeper License obligations?

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

dskoll — Mon, 27 May 2024 21:38:25 +0000

If you do accept a license and violate it, then it would be a different crime.

No. Violating a license agreement is a civil matter, not a criminal one. (It could potentially be the case that a specific violation also violates criminal law, depending on the nature of the violation, but that's separate from violating the license agreement.)

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

khim — Mon, 27 May 2024 10:53:53 +0000

Reverse-engineering clause is, indeed, unenforceable because law includes explicit permission to do reverse-engineering for interoperability purposes.

What is enforceable is non-competing clause. In fact Russia law (which I refered to, back then, because US law got that exception later) even explicitly says the following: “информация, полученная в результате декомпилирования, может использоваться лишь для достижения способности к взаимодействию независимо разработанной программы для ЭВМ с другими программами, не может передаваться иным лицам, за исключением случаев, когда это необходимо для достижения способности к взаимодействию независимо разработанной программы для ЭВМ с другими программами, а также не может использоваться для разработки программы для ЭВМ, по своему виду существенно схожей с декомпилируемой программой для ЭВМ, или для осуществления другого действия, нарушающего исключительное право на программу для ЭВМ” (translation: information obtained as a result of decompilation can only be used to achieve the ability to interact with an independently developed computer program with other programs, and cannot be transferred to other persons, except in cases where this is necessary to achieve the ability to interact with an independently developed computer program with other programs, and also cannot be used to develop a computer program that is substantially similar in appearance to the decompiled computer program, or to carry out other actions that violate the exclusive right to a computer program, emphasis mine).

Weirdly, if you don't straight-out decompile a program then other means are perfectly acceptable, but again, it all is contingent on being in possession of a license… and if even law itself talks about non-competing rules then we may easily assume that they are perfectly legal to have in a license.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

paulj — Mon, 27 May 2024 10:24:30 +0000

Correction, "internally until after 2005", the 2005 should be 2008.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

paulj — Mon, 27 May 2024 10:22:51 +0000

Interestingly, years ago, you were arguing that even IF Tridge had used the BK client, that the reverse-engineering clause in the copyright licence was unenforceable.

https://lwn.net/Articles/130900/

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

paulj — Mon, 27 May 2024 09:25:15 +0000

Tridge did not recite the copyright material publically.

He connected to a public server, and made a query. The *server* sent him the copyrighted material, over a private connection.

Where is the public recitation?

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

paulj — Mon, 27 May 2024 09:23:52 +0000

How does connecting to an open network server create a binding contract between you and the operator of that server?

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

paulj — Mon, 27 May 2024 09:22:24 +0000

> Would Linus have developed Git, if he had never seen BitKeeper? I mean, probably eventually *somebody* would have (Merkle trees were patented in 1979, so the necessary tech mostly already existed)

Given that BitKeeper was Larry's reinvention of TeamWare - the internal DVCS at Sun Microsystems - but with a simple network daemon instead of NFS for the D part - it is indeed guaranteed someone else would have developed something similar. Many many engineers had worked at Sun and used Teamware (it continued to be used for OS/Net, the core Solaris repo, and other repos, internally until after 2005; I assume they switched to Hg after that at some point, as OpenSolaris did, but I don't know).

Again, Bitkeeper was a clone of an internal Sun Microsystems DVCS. Larry worked on an SCCS library that was used in TeamWare, but he did not invent TeamWare.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

LtWorf — Mon, 27 May 2024 09:10:58 +0000

> So far we have few guys who bring references to law, conventions, court cases and “peanut gallery”

Yes. I don't know why you are bringing this up since you firmly belong in the 2nd category here.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

gdt — Mon, 27 May 2024 04:10:35 +0000

Tridge's was asked about this at linux.conf.au. He telneted from Australia to the Bitkeeper server in the US and asked the crowd what to type. Starting with the command HELP and some knowledge of SCCS, the audience "reverse engineered" the protocol in minutes. Without being presented with or accepting the Bitkeeper terms of use. There was laughter at the claims of illegality by some people, and that same year Stevens v Sony made clear the High Court's view that reverse engineering for interoperability was both acceptable and desirable.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

dvdeug — Sun, 26 May 2024 21:47:40 +0000

> browser can cache content if there are no Cache-Control: no-store line in server answer

The question would be if a browser can cache content if there is a Cache-Control: no-store line. I'd expect the answer would be yes, that "Cache-Control: no-store" has no legal effect and anything you can download you can cache. (I could argue from the "Betamax case", for example.) I'm pretty sure no one can produce a court decision one way or the other.

> random servers attached to public internet are exception to that rule… What? Why? How?

There is a case where a company made money suing downloaders of its NSFW films uploaded to The Pirate Bay. They're now in jail, because they uploaded their own films to The Pirate Bay, and suing people for downloading stuff you made available on The Pirate Bay was considered fraud. If someone asks a server for a file via the public internet, and the server gives them that file, the presumed intent of the people who set up that server was to make the file the available. There's a bunch of hacking laws and computer trespass laws that complicate things, and I can't argue in this specific case, but if you put it online, and there's no password or encryption or the like, it's fair game.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

pizza — Sun, 26 May 2024 15:27:46 +0000

> Yes, but he asked server to make copy the whole BitKeeper history for him.

You do realize that the server could have easily said "Not without authentication" instead of "Sure, here's everything you asked for; can I get you anything else?"

At what point can we say Bitkeeper should have at least made a *token* effort to impose access control or some other sort of usage limitations on something they *intentionally* exposed to the public? Requiring API keys (or some sort of credentials) for certain operations was commonplace well before Bitkeeper was released.

As an added bonus, you make obtaining credentials conditional upon accepting the terms of service.

> That definitely falls under inducement bucket.

[citation needed], especially in light of the utter lack of any sort of access control.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

khim — Sun, 26 May 2024 15:10:09 +0000

It's more about INDUCE Act which was deemed unnecessary because §106 already says that only a copyright owner has the exclusive rights to do and to authorize any of the following (emphasis mine).

Said act was overreaction to the Napster case and an attempted to make people liable when they just only provide things like sha1 sums which make finding copies easier without directly prompting anyone to make any copies.

That was deemed to be overkill and wasn't added to law. But when you impersonate someone to do a copyright violation on your behalf… that's still forbidden. You can find long history with many laws and court cases in the Wikipedia.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

dvdeug — Sun, 26 May 2024 15:08:55 +0000

> But it's most definitely creative and valuable, or else Andrew Tridgell wouldn't have bothered to [try to] access it.

That doesn't follow. Again, Feist v. Rural; Feist copied Rural's phonebook, but it wasn't infringement, because the information was not creative. Data about who accessed what when is not copyrightable; it's simple facts, showing no hand of the human author.

Can we wind this down?

corbet — Sun, 26 May 2024 15:06:48 +0000

Second request: you all can clearly go around in circles on this forever, but there are no lawyers here and little of use is resulting. It really is time to give it (and us) a break.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

dvdeug — Sun, 26 May 2024 15:03:27 +0000

Compilation copyrights cover original anthologies, the creative effort of the editor in choosing works. They don't cover uncreative anthologies, like the Complete Works of Joe, for example (see Feist v. Rural or the US Copyright Office Compendium.) Nobody has or could get a copyright on the simple compilation of Linux kernel commits, since there's no creative selection going on. Any other metadata is unlikely to be to be copyrightable; you can't copyright a blank form, and you can't really copyright the computer equivalent.

As for violating a license you haven't agreed to, the concept is weird. You are under no obligation to care about a license you haven't agreed to, so "violating" it is a really heavy phrase for a completely irrelevant activity.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

mb — Sun, 26 May 2024 14:56:27 +0000

>Yes, but he asked server to make copy the whole BitKeeper history for him. That definitely falls under inducement bucket.

Would you please at least read the Wikipedia article about these terms?

https://en.wikipedia.org/wiki/Inducement_rule

>The inducement rule holds that "one who distributes a device with the object of promoting its use to infringe copyright

Clearly not the case here.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

khim — Sun, 26 May 2024 14:29:01 +0000

> Copyright is generally silent on the right to access copies.

No, it's not. It's only silent about cases where you access copy without making another one. Copyright law if full of exceptions like when copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner.

Thousand years old exceptio probat regulam in casibus non exceptis principle says the only reason for such exceptions to exist is to ensure that law which would otherwise prohibit them wouldn't harm innocent people. And law that restricts the whole thing is very broad: every copy that is made need a license (except when special exception is given). Law wouldn't need to specifically ensure that you have right to load program in memory if you purchased it on disc if that would have been obvious from some other parts of copyright law.

> Trigdell never made a copy of Bitkeeper software.

Yes, but he asked server to make copy the whole BitKeeper history for him. That definitely falls under inducement bucket.

> But if Trigdell never signed the license, never agreed to it, how can he be held accountable to it?

Because he

clearly knew about terms of such license and knew that he violates them
did thing which he needed said license for

At this point description of the form “I had no idea there was a license” or “I had no idea that I need a license” no longer flies. It's clear attempt to have the cake and eat it too.

Courts, it general, have little lenience to such attempts.

> In that case, he sniffed the packets going over the network

If he just snipped packets without ever sending them, then sure it would have been very hard to say about inducement. But that's not what have happened.

> Similar to reverse engineering of SMB

When he reverse engineered an SMB he never induced creation of illegal copies (AFAIK, anyway). While in BitMover case that was his clear goal.

> Apparently Larry McVoy didn't think that what Trigdell did was so wrong that it was worth suing over (at least I'm unaware of a lawsuit).

No. Please open that old link and read again: He [Andrew Tridgell] couldn't talk about much, and he did not announce the release of his BitKeeper client.

This tells us that lawyers were already definitely involved at this stage. Sure, that doesn't mean that Larry had a case (it's not unknown for “mere mortals” to easily fold when threat of court process is there even if said threat is baseless), but we know that Larry was ready to sue. Just Andrew folded before that being necessary.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

mb — Sun, 26 May 2024 14:10:10 +0000

>They where clearly trying to induce or knowingly to cause another person to do something that's prohibited by copyright law.

Convention, law, or court case, please.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

khim — Sun, 26 May 2024 14:00:46 +0000

> IANAL, but from my understanding, the US generally is a permissive law - if it's not forbidden it's allowed

Not when we are talking about making copies of “work of art”. There it's the opposite: by default that's forbidden, but there are licenses and various exceptions codified into law.

> note that, if you read "https://lwn.net/Articles/132938/" you'll see that the group weren't sending random strings, they were sending known commands from other protocols such as "help"

And that's precisely the issue: they weren't just sending random command to perform some kind of network research or anything. They where clearly trying to induce or knowingly to cause another person to do something that's prohibited by copyright law.

> You're aware of the many Youtube ad blockers for browsers out there, aren't you? I'm fairly comfortable none of their creators asked Google for permission. Google's answer has not been to sue, but to change their interface.

That's not because they couldn't sue. And in high-profile cases (like when Microsoft was involved) they threatened to sue. It's just most ad blockers don't belong to companies with deep enough pockets for court processings to be lucrative.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

jjs — Sun, 26 May 2024 13:02:40 +0000

Correction to myself - Statute of Anne passed in 1710 - https://en.wikipedia.org/wiki/Statute_of_Anne

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

ewx — Sun, 26 May 2024 12:56:56 +0000

> The license for the ‘community’ version of BitKeeper had allowed for developers to use the tool at no cost for open source or free software projects, provided those developers did not participate in the development of a competing tool (such as Concurrent Versions System, GNU arch, Subversion or ClearCase) for the duration of their usage of BitKeeper plus one year.

So did Linus violate the Bitkeeper licence by writing git without waiting a year?

(I guess nobody was stupid enough to sue him over it if so...)

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

felixfix — Sun, 26 May 2024 12:56:54 +0000

Your second sentence says you knew that no alternative would be acceptable to BitMover. I listed alternatives. Now, personally I am glad for you, that you know what BitMover would and would not have accepted. Me, I am too ignorant to have such great knowledge of 19 year old events. So, please, accept my apologies for not realizing how much you knew.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

jjs — Sun, 26 May 2024 12:35:04 +0000

I think you're referring to the start of 17 USC 1201(f) - https://www.law.cornell.edu/uscode/text/17/1201

Interesting question. As I read 1201 more (note, IANAL, consult a lawyer for legal advice), it talks often about "circumvent a technological measure" which Wex give details at
https://www.law.cornell.edu/definitions/uscode.php?width=...

Does "not publishing the query terms that work" constitute "a technological measure?" Especially if one of the terms is "help" which then tells you what commands are available.

"So… where that lawfully obtained right to connect to BitMover servers originates, hmm? What gives Andrew or anyone else that right? If not an explicit license (which was pretty blatantly violated) then what?"

Good questions - but asking the questions doesn't mean the answers are what you think they are.

"Something that flies right over the head of technogeeks but is critical and easy to understand to every normal person."

And in law, what a "normal person" understands may not be right (depends on law & circumstances). Maybe the "technogeeks" understand there's nuances in the law, due to exact facts & circumstances, and interactions of laws, and previous case law..

Turns out copyright isn't so black and white (again). And sometimes flimsy arguments are actually correct.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

mb — Sun, 26 May 2024 12:14:20 +0000

>So… where that lawfully obtained right to connect to BitMover servers originates, hmm?

It was a public server.

Do you realize that everybody disagrees with you and yet you fail to provide evidence that a "license" is required to access a public server?
To convince people, you have to provide evidence.
It's your turn.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

jjs — Sun, 26 May 2024 12:14:16 +0000

"Where does it say that? I've read that assertion approximately bazillion times, but have never seen anything that permits you to connect to unknown server using an unknown protocol when you don't have a license to connect to it."

IANAL, but from my understanding, the US generally is a permissive law - if it's not forbidden it's allowed. So, in that case, the question is "what law forbids you from connecting to an unknown server and poking it with known commands" (note that, if you read "https://lwn.net/Articles/132938/" you'll see that the group weren't sending random strings, they were sending known commands from other protocols such as "help")?

The closest I can find is CFAA https://www.law.cornell.edu/uscode/text/18/1030 which forbids such connections if the connection is for certain purposes (see 18 USC 1030(a)). But it only forbids for certain purposes. What if you're doing it for other purposes, such as reverse engineering? What have the courts ruled?

"Every time someone tries to make Google Earth client, or YouTube client, or SharePoint server they are asked for a license first. Then en exception for reverse engineering and other such exceptions start to matter."

You're aware of the many Youtube ad blockers for browsers out there, aren't you? I'm fairly comfortable none of their creators asked Google for permission. Google's answer has not been to sue, but to change their interface.

Also, just because others have asked for permission doesn't make it a requirement.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

jjs — Sun, 26 May 2024 12:03:05 +0000

sure. Copyright deals with the right to copy. The concept dates back to the Statute of Anne in 1709. It controlled who had the right to make copies - specifically who had the right to control who made copies. Prior to the Statute of Anne, it was the printers. The Statute of Anne established that the author has the right to decide who makes copies. US copyright follows that principle.

Copyright is generally silent on the right to access copies. If I legally obtain access to a copy of a book (say I go to the library and check one out), I can read it without asking the author for permission. If I find a book on the street and pick it up, I can read it. If I own a copy and chose to sell it, I can without asking for permission from the copyright holder (I'm not making an new copy).

As we move into (and have moved into) the computer age, these questions come up, and are complicated by other laws such as CFAA (which I don't think was passed when Trigdell was reverse-engineering the Bitkeeper protocol, or the SMB protocol). In both cases, he didn't have a license to the software, but accessed it over the wire. Did he have permission? (see your other post) Which raises the question of "did he need explicit permission to send things to the port & see the answers?" Which is a separate question than "did he have right to copy".

"I fail to see where and how Andrew lawfully obtained the right to use a copy of a computer program if he never accepted the license."

Right to use is different from right to copy. With software, it often gets confused because the normal way to use a copy of software is to make a copy of it (often two - one to your hard drive, and then a copy to memory).

Trigdell never made a copy of Bitkeeper software. He asked it questions and got answers. The software ran on Bitmover's servers. Accessing a computer is a separate question, and the heart of the CFAA.(18 USC 1030- https://www.law.cornell.edu/uscode/text/18/1030).

Did his actions violate CFAA? Good question - what did the courts say? Oh, there was no court case. Question still open.

"The “don't piss of Larry” license included the clause that the one who signs it wouldn't develop any version control programs, and another client is the most blatant violation of that clause that may ever be imagined."

But if Trigdell never signed the license, never agreed to it, how can he be held accountable to it? Similar to reverse engineering of SMB - he never ran the software, never (as far as I know) agreed to run the license of the software. In that case, he sniffed the packets going over the network, figured out which were the SMB packets, deconstructed them, and figured out what was going on. Then reverse engineered the protocol to allow a Unix (Linux specifically, I believe) system to masquerade as an SMB server for purposes of file sharing.

Apparently Larry McVoy didn't think that what Trigdell did was so wrong that it was worth suing over (at least I'm unaware of a lawsuit). Whether that's because he didn't care, because his lawyers felt he didn't have a good case, because he didn't like suing, or for many other possible reasons, you'll need to talk to Larry to find out.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

khim — Sun, 26 May 2024 11:12:04 +0000

> I assume the "most definitely did" refers to reverse-engineering Bitkeeper, as that's what jra was disputing that Tridge did.

The “don't piss of Larry” license included the clause that the one who signs it wouldn't develop any version control programs, and another client is the most blatant violation of that clause that may ever be imagined.

> Which might fall under 17 USC 1201f exemptions for reverse engineering for purposes of interoperability (see my other post).

17 USC 1201f exemptions requires this: a person who has lawfully obtained the right to use a copy of a computer program, may <do many things>. And I fail to see where and how Andrew lawfully obtained the right to use a copy of a computer program if he never accepted the license.

Care to enlighten me?

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

khim — Sun, 26 May 2024 10:56:58 +0000

> Very similar to what he did with the Bitkeeper protocol (minus the documentation).

And minus the permission to access the machine. Something that flies right over the head of technogeeks but is critical and easy to understand to every normal person.

> Which is what I've been saying - regardless of our individual opinions, until a court rules on a case in front of it (which, in this case would be either Larry McVoy or Andrew Trigdell starting a case), it's a gray area, and, as I doubt any of us will be lawyers for one of them in a court case on this (especially not me, without considerable more schooling), our opinions are ultimately not relevant.

Everything is, to some degree, a gray area, till decided by court. But there are different shades of gray.

Everyone loves to bring that idea that people are, somehow, entitled to do a reverse engineering and thus Andrew could ignore the license, connect to server in question and start hacking, but if you actually open the papers and read them you'll see that the whole thing starts like this: a person who has lawfully obtained the right to use a copy of a computer program may <do a lot of things:gt;.

So… where that lawfully obtained right to connect to BitMover servers originates, hmm? What gives Andrew or anyone else that right? If not an explicit license (which was pretty blatantly violated) then what?

One may argue that the fact that you may connect to server, type help and get an answer is enough… but that sounds like a very flimsy argument to me.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

khim — Sun, 26 May 2024 10:44:33 +0000

> Simply talking to a publicly reachable server in order to figure out how to communicate with it - and even circumventing some protections of that server in doing so (which wasn't even the case here) - is explicitly allowed by law.

Where does it say that? I've read that assertion approximately bazillion times, but have never seen anything that permits you to connect to unknown server using an unknown protocol when you don't have a license to connect to it.

When you are using known protocol (like SMTP or HTTP) you may argue that specification for that protocol which usually includes words that explain why it exists and what can you use it for (like: transfer mail reliably and efficiently or HTTP has been in use by the World-Wide Web global information initiative since 1990, which, then allows you to bring documents related to said initiative and go from there). Legally all these talks are congregate on the implied license.

But if you are connecting to random server using random protocol… what give you the right to do that?

> the major difference here is the explicit exception in copyright law for reverse engineering

Explicit exception for reverse engineering is only applicable when you have a license to access something but have no technical means to do that. Well… where is the license that Andrew Tridgell used to be able to lawfully access BitMover server, hmm?

> Fair use is always a complicated balancing act between competing interests, whereas the reverse engineering exception is far less ambiguous.

Sure, but I'm yet to see a case where it was successfully used to circumvent the license. Every time someone tries to make Google Earth client, or YouTube client, or SharePoint server they are asked for a license first. Then en exception for reverse engineering and other such exceptions start to matter.

That's why this Microsoft and Google dance around YouTube haven't ever raised the question of YouTube servers being publicly accessible and thus reverse-engineerable.

No, you need a license first. Then you can start your reverse-engineering activities.

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days (Graphite blog)

tuna — Sun, 26 May 2024 08:48:52 +0000

Thanks for the clarification!