Is the BitKeeper network protocol documented?

Dammit, *MY* preferred form might be CVS, I want a CVS tree instead!!

I can't use BitKeeper based on my reading of the license and Larry's comments, because one of my current projects is a system-config versioning and tracking system. (Hey Larry et al - thanks for a good tool and getting Linus to use it.. ;)

Just because Linus happens to be using BK currently does *NOT* automagically make it the industry-standard preferred format.

Not everybody has BitKeeper - as such, a .tar.gz of the source tree can reasonably be considered the "preferred" form if your intent is to make the tree available to as many people as possible - if it's a .tar.gz, the only thing you need is a GNU-compatible tar command to extract it. Certainly preferable to BK if you want somebody to be able to get going with as little as possible.

And let's go look at another clause there:

Does this mean that Linus can't distribute a tree with patches integrated, but has to include copies of things as they were posted to LKML?

Actually, you *want* Linus to be editing, so he has copyright on the collection as a whole (very important, as another poster commented).

Moral: Let's not get silly here...

Hmm.. and what is Linus failing to ship here? The .c files are in there, the .h files are in there, the Kconfig/Makefiles are there....

Note that this clause doesn't even apply unless you distribute *binaries*. Linus doesn't do that, RedHat does that - and THEIR preferred format for distributing is a .RPM. Ever tried to figure out what RedHat did to something
when you're on a machine without RPM? Yep, you get to track down rpm2cpio or
similar...

I'll make the only-slightly facetious comment that the *preferred* format for a kernel tree would include a neuron dump of the people who were doing the coding, so we would be able to determine whether a given change was truly enlightened and correct, or if they were just on crack at the time....

				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

Don't blame me. The GPL just says the "preferred" form and leaves us
to wonder. As I understand it, however, you cannot ship binaries of a GPL'd project unless you can distribute the source code in the "preferred form .. for making modifications to it".

I'm still perplexed what you do if the preferred modification form
for a work requires consent to a license more restrictive than the GPL in order to make modifications to it. As I see it, you just can't GPL such a project.

And you can't take a GPL'd work and turn it into a non-GPL'd work
and continue to distribute binaries.

DS

The GPL specifically allows for multiple methods of accessing the 'preferred form' including FTP, including the source in the distribution, etc. BitKeeper is nothing more than another method to access that 'preferred source'.

Please stop this. You're looking kind of silly here.

Dana Lacoste
Ottawa, Canada

PS: nobody said 'IANAL' yet. meaning you're just a noisy peanut gallery :)

I think you're entirely dropping the context. If the development of
a project is centered around a version control system, then that version control system contains metainformation that is useful when you're making modifications.

In this case, the raw source code, less the change history and check
in comments, would not actually be the preferred form of the source code for the purpose of making modifications. This has nothing to do with how you get the information but what information you get.

Only because you are misrepresenting my argument.

Let me give you a hypothetical. There's a program and you have to
make some changes to it. Would you prefer to have the raw source code or the source code with change history and commit comments? I'm not talking about how you get either set of information, I'm talking about what information you get.

Checking code out of a repository is as much an act of obfuscation
as stripping comments.

Any lawyer who claimed he or she could predict how a court would
interpret this clause of the GPL is lying to you. That is why it is essentially impossible to be sure you comply with this.

DS

so are you saying it's illegal for an opensource project to use a commercial version control system, or that use of such a version control system by a GPL project forces the companty to GPL their version control system?

since stallman has already said neither of these is the case I'm curious as to exactly what you are trying to say the requirements are.

David Lang

I don't understand how I can be clearer than I've already been. The
GPL requires you to do some things if you want to distribute binaries. One of those things is to distribute the source code in the "preferred form" for modifying it. Thus, if you don't have the source code in its preferred form for making modifications, you can't distribute binaries.

This then brings up two more complicated issues.

First, what is the preferred form of a work for making modifications
to it? Here, I argue that if a project is based around a version control system, then checking out the source code removes vital metainformation and does not produce the preferred form. The loss of the check in explanations and change history makes modifications more difficult.

Second, is distributing useless source is equivalent to distributing
no source at all? Here, I argue that distributing the source in the preferred form for making modifications to it but such that it cannot be actually modified without agreeing to a license other than the GPL, does not meet the GPL's requirements for source distribution.

That's what I'm saying. You can draw whatever conclusions based upon
my arguments that you like. But those are the two arguments I'm making and I've already posted the justifications for them.

My motive in making these arguments is quite simple. If Congress had
to comply with all of its laws, it'd probably make better laws. So if the people who choose to apply the GPL to their projects are more inconveniences by its quirky bits, perhaps they'll choose better licenses in the future.

I submit that it is impossible to comply with the GPL and distribute
binaries if the preferred form of a work for the purposes of making modifications to it is in a proprietary file format. This is tantamount to encrypting the source.

DS

OK - my current, (I.E. for this evening), prefered form is EBCDIC on a set of 80 or so 9-track tapes. Where can I get a copy of the kernel source in this format?

John.

So, let's say that CVS is the "preferred form" of the Linux kernel source code, because it is freely available. If BK has everything in it that CVS does, and also information that is not even POSSIBLE to store in CVS (i.e. ChangeSet information which links a bunch of individual file changes and comments into a single change entity) what happens then? If you had never put the kernel into BK, that information wouldn't exist at all, yet it is not possible to extract it without resorting to some source-of-all-evil tool like BK (I hope everyone reading here understands the sarcasm, but the fact that I have to annotate it makes me believe some people will not).

The fact that BK is used creates information which WOULD NOT HAVE EXISTED had BK not existed. In fact, until BK was in use by Linus, not even basic CVS checkin comments existed, so the metadata was in a format called linux-kernel mbox (if that). So, the use of a tool like BK makes more data available, but people cannot be worse off than when the kernel was shipped as a tarball and periodic patches. For the sake of those people who don't or can't use BK, just pretend BK doesn't exist and they will not be any worse off than a year ago.

Sure, except BK isn't a proprietary file format (see GNU CSSC and or some Perl scripts reported on this list), so the issue is purely hypothetical.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

If CVS is the "preferred form", then it is CVS you must distribute.
What other tools provide what other information is irrelevant. The GPL is quite clear that the preferred form of the source for making modifications is what you must distribute.

The GPL doesn't care about whether you're better off or worse off.
The GPL just says you have to distribute the source in its preferred form for making modifications.

It sounds like you and I are in violent agreement. But it's not
purely hypothetical -- there are GPL projects today that keep their source in proprietary file formats. (For example, many of the ones using Visual C++.)

DS

What if BK *is* the perferred form?

John.

linux.bkbits.net:8080/linux-2.5 is accessible for all, even people developing another SCM. All incremental changes can be found there again without any licensing issues.

And btw. no-one forces people to use BK to develop the kernel. And the kernel is available as patches on kernel.org.

So what is the point of this thread?

Sam

You'll have to find another project to prove your idea, though.

Bitkeeper is using the AT&T SCCS format (plus compression) to store its data and metadata. People are working on scripts to extract the source from a bitkeeper tree without using the bitkeeper software.

cheers,

Rik

Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://guru.conectiva.com/
Current spamtrap:  <a href=mailto:"[email protected]">[email protected]</a>

No, you're missing something very very very important here (that someone else followed up with but you missed their point too)

The GPL was fundamentally designed to allow for the freedom to modify the products that you have under the GPL.

This means that the source code to the product you have must be in a form that is modifiable, and it must be in the 'preferred' form for YOU to modify that code.

This has NOTHING to do with patches and tracking changes and communicating with Linus. This has to do with the code to the software you use and YOUR ability to change it.

Thus you can take any release of Linux's source and add it into BK or p4 or CVS or rcs/sccs and you can make your own changes to that source code. The binary you have was created from that source code and the GPL protects your right to modify that source code.

BK is merely a way that the product authors can manage their changelists over time. The BK information is not used in the build of the binary, therefore it is not part of the binary and not having it is not preventing you from modifying the source code to the binary you do have. Even if you got it from Red Hat.

Dana Lacoste
Ottawa, Canada

This can't be right for two reasons.

First, I would in fact prefer to have the version control
information to make changes. The commit comments, for example, may explain the rationale for changes. Seeing who made a change may affect my level of confidence in that change. Also, seeing which changes were made a unit helps you to know what code affects what other code. Anyone who has ever modified a project that is managed through a version management system will tell you that they prefer to have access to the repository and the metainformation in it than just have the raw source code out of the repository.

Second, what you say above would imply that if I prefer my source
code on 30mm tape in EBCDIC format, then RedHat has to provide it to me since that's my preferred form.

My best attempt at understanding what "preferred form for making
changes" is the form that the people making the changes actually do in fact prefer.

What happens when one party gets source code from another and both
parties make changes. Suppose, hypothetically, Linus only gave out obfuscated source code. He can do that, since he doesn't distribute binaries. Now, can RedHat ship binaries of Linus' obfuscated source code? If so, anyone can evade the intent of the GPL just by creating a separate company. So it *can't* mean the preferred form of the person you got the binary from.

I think it has to mean the preferred form for making changes by the
people who actually do make changes. And I don't think you can justify removing any information that helps the people who make changes do their change-making, as that is not what they prefer.

I think I've said all I have to say on this subject, especially
since it doesn't affect the Linux kernel at this time. However, I caution against ever allowing a situation where the preferred form for making changes of any GPL'd project, preferred by the people making the changes, is in any way a proprietary system.

DS

What 30mm tape format are you refering to? Or was this comment just inspired by almost the same comment I posted as a joke yesteday:

http://marc.theaimsgroup.com/?l=linux-kernel&m=104309529827231&w=2

John.

The commit comments are available, so why arguing?

Sam

So what? This has nothing to do with getting the source code to a binary distributed product.

Remember, the GPL covers the distribution of binary modules, and how to get the source to those modules, not the documentation from meetings made 5 months before the code was modified.

This is also irrelevant. You receive a binary module (this is your redhat model, remember?) and you want the source code to that module before you install it. Redhat gives you the source used to compile the module. You don't get the checkin comments because they weren't used to compile the source.

Your inability to deal with the source in a raw form is YOUR problem, not the original author's, and not the GPL's raison d'etre.

Once again, the GPL is giving you access to the source code to the module you have, not the modules you don't have, not the modules that were in the past. Why don't you understand this?

No, that's not what 'preferred form' means. Instead, it refers to the form the binary module is preferred to be in when changes are made.

See, in modern computers the CPU speaks what we call 'machine code.' This isn't really easy to read or to understand because, for the most part, we're not computers.
In order to facilitate the difficulties inherent in reading 'machine code' computer programmers routinely use what are called 'higher level languages' such as assembly language (which is essentially a text-based version of machine code) or C (which is one step 'further' from machine code towards the english language) or even APL (which is closer to martian than english.)

Because binary code is so hard to read (for the most part programmers don't even use it, resorting to the above mentioned 'higher level' languages instead) companies are able to sell software products by shipping a binary package that is, for all intents and purposes, unmodifiable by the end user.

Because of the notoriously shoddy work done by many corporations, and the natural desire to have stable and reliable software, RMS started the Free Software Movement, an attempt to gain access to the source code to the programs that cause so much instability in our lives.

Thus, it's required under the GPL to distribute the source code that the binary modules were compiled from, in a form that can be modified.

"a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange"

(Note that although a 30mm tape is a possible medium for software interchange, so is ftp, and it quite clearly says 'a' medium. Meaning the distributor decides.)

The difference here is subtle, so I'll try again.

"Preferred" in english is a relative term. It implies that there is a form that is "not preferred" and the GPL goes to quite a length to explain that binary, machine-code distributions are the "not preferred" form.

Therefore the "preferred form" is the form that is _not_ the binary machine-code form. This is the 'source code' from which the binary form is made.

Because re-distribution counts as distribution, it is important that the re-distributor distributes the source code, even if they didn't make any changes.

It is not important that the re-distributor maintain changes over time, nor that the re-distributor even understand what's going on in the code, what's important is that the end user doesn't get something that they can't make changes to, if need be.

If Linus only gave out obfuscated source code then he wouldn't be in business as the leading open source kernel manager for long, now would he?

Then again, Ulrich Drepper manages to get away with it....

Hmmm....

:) :) :) :)

You can justify whatever the hell you want. The GPL says the source code has to be there, pure and simple. No comments, no system libraries, no BK notes.

I think maybe you need a new license, because the GPL is obviously not what you want.

Dana "Why didn't David reply in private to the private reply?" Lacoste Ottawa, Canada

...

Suppose I take the Linux kernel and make lots of changes to it. I
then obfuscate the source and hand the source to another person. I've clearly not violated the GPL at this point because I haven't distributed anything but source.

That person compiles the source and distributes it. Has he violated
the GPL? The only way your reply can make any sense is if it's okay to distribute obfuscated source to meet GPL requirements if it was the obfuscated source that was compiled to make the executable that was distributed.

It is, at least in principle, possible to make changes to obfuscated
source. I submit that this is a possible interpretation of the GPL's "preferred form" clause. However, I don't think it's what the GPL intended and I wouldn't bet money that a court would go along with it.

I did. I replied privately to your private replies and publicly to
your public replies.

DS

These comments are not part of the source. The source has its own comments. They are helpful when you try to track the changes, but GPL doesn't require releasing the tracking record of a GPL project. It only requires releasing the
whole source (or diff).

The argument that "BK hosts GPL project so BK has to be GPL'd" is also ridiculous. If so, let's GPL all disks that store any bit of GPL code, including
firmware and hardware/chip specs. Then where would we end up? Right, you cannot find anywhere to host any GPL projects. So it's essentially killing GPL in the name of purifying and defending it.

No, a "diff" is _not_ sufficient when releasing a modified binary - you must provide, or offer to provide, the whole source used to make that binary.

People differ in what they think the "whole source" means. The GPL defines what _it_ means by the source code for a work, and that is the definition you are bound by, but even that definition is understood differently by different people. It is the nuances of that definition that are being discussed in this thread.

I agree with Larry that clear boundaries will be found in case law, as and when they are required, and that meeting minutes and repository metadata probably are not considered part of the source code.

It is just tough luck that you miss out on useful information.

In addition, even if Linus refused to work with someone who did not use the repository, that is also tough luck. You have the right to fork the project; the GPL does not give you the right to work with Linus.

However if there was a project where the repository was _essential_ to do any meaningful work on the project, I suspect that a court of law would find that the repository is considered part of the source code per the GPL's definition.

(Note: I am not a lawyer nor have I paid for any advice.)

Please be careful when making logical statements.

Nobody, not even David, has made that argument. His argument is that "BK hosts GPL project so the repository _of that project_ has to be GPL'd".

It has nothing to do with BK, in fact.

-- Jamie

First you would have to find a court willing to accept jurisdiction. One court per country you were interested in. And all the appelate courts. Then you would have to find plaintifs and defendents willing to pony up money to pay for thousands of hours of lawyer time.

All for a product which is "free".

heh heh heh

john alvord

You're not understanding and respecting the concept of a boundary. Suppose you had a GPLed driver and you put it in a BSD kernel, using the driver boundary to limit the license pollution. Suppose that your driver only worked in that BSD kernel and it was useless without the kernel. Your argument would say that the BSD kernel needs to be considered part of the source per the GPL's definition. Obviously incorrect.

A boundary is a boundary. It doesn't matter how much you want or need what is on the other side of that boundary, you don't get to make your license cross that boundary, the law doesn't work that way.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Thus the concept of "derivative work."

The single most vague section of the GPL IMHO.

Can we move on now? We're not going to resolve anything here, and i think we're all argued out :)

Dana Lacoste
Ottawa, Canada

Derivative works don't get to cross boundaries. A boundary is a trump card, it's like a patent, it has strength. Go dig into the legal findings in this area. My memory is that anything you can pull out and replace with another implementation constitutes a boundary and you may have different licenses on either side of that boundary without fear of them fighting. So a derivative work which can't be easily replaced doesn't get to have a different license than the basis. On the other hand, something which plugs into an interface, like a driver or a file system, could have a different license.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

NO it is not.

Copyright assignment to Linus should be enforced with a specific condition. Should Linus ever remove the GPL license, all Copyrights revert back to the original owners. This is a forced stale-mate.

All this allows for Linus to set usage policy under GPL conditions. Outside of GPL, Copyright law is default rules as they are today.

This will kill the wars of the copyright holders v/s the users v/s the vendors blah blah ...

This also give Linux (the kernel) a single point of authority.

The other thing to do is for every one of the copyright holders convert to LGPL and so on .... right, lol, go smoke more crack, blah blah blah.

Comments nah, actions yes ...

Cheers,

Andre Hedrick
LAD Storage Consulting Group

don't forget that sourceforge itself is not GPL so are people saying that all projects in sourceforge can't be GPL?

think people, do you really want to go there?

goeing even further, if the source for a GPL program is stored on a non-GPL filesystem does that conflict with the license of the filesystem? does that meant that if I load the linux kernel source on a Veritos filesystem and decid that that's the 'prefered' form of the source code that veritos is forced to GPL their software?

not even RMS is supporting a position like this so apply a LITTLE sense here, PLEASE.

David Lang