Dear Larry,
Please don't take this as a contentious question. I have an honest
request, and would like a technical answer without politics if that's
possible.
Can't use BitKeeper
-------------------
I'll explain where I'm coming from.
Recently, I was debating with Linus about the new vsyscall code. To
keep track of Linus' changes, so that I might make better comments and
produce a patch or so, I had a need to track the head of the kernel's
bitkeeper repository at bkbits.net. (The experimental code was not
yet available as a normal patch from Linus).
Although I am unfortable using closed source software, it seemed
pragmatic to fetch and install BitKeeper. I went to bitmover.com, and
read the free license before downloading:
http://www.bitkeeper.com/Sales.Licensing.Free.html
That looked ok. I am allowed to use it. Great!
So I downloaded version 3.0, and typed "bk help bkl". I found that
the license with the software is _different_ to the licence on the web
page.
[Note to Larry, you may wish to update the above URL to the
current version].
Unfortunately, the license that comes with the download adds a new
clause 3(d): that's the clause which tells me that actually I'm not
allowed to use BitKeeper, because of other software I occasionally
work on. (No, I do not work on Subversion, but I do occasionally
dabble with sophisticated version management scripts).
So, being conscientious and obedient, I removed BitKeeper from my system.
As a result I had great difficulty having a meaningful debate with
Linus - as I had no easy way to look at the code Linus was checking
in, that we were talking about! (And submitting a patch to illustrate
my thoughts was out of the question).
Real-time kernel tree only available over BitKeeper protocol?
-------------------------------------------------------------
To synchronise with the kernel repository, in order to communicate
effectively with Linus about changes as they are checked in, I think
that it's necessary to use the BitKeeper network protocol (or the
over-HTTP equivalent).
I know that Rik van Riel keeps a mirror of the repository in various
formats over at nl.linux.org:
http://ftp.nl.linux.org/linux/bk2patch/
Thus far, the best solution I have for tracking checkins is to rsync
the SCCS files from Rik's mirror, and use a Perl script to extract the
head version from each SCCS file. (I could use GNU CSSC, but for this
purpose a simple Perl script is enough; the SCCS file format is quite
simple).
However, as is the nature of mirrors, I'd rather not have to wait for
the time delay getting updates to Rik's mirror. Not to mention the
lack of tree-wide atomicity, if I rsync at the wrong moment (I am not
sure if this is a problem in practice).
Anyway, the point is I would like to be able to access the "official"
kernel development tree, in real time like everyone else, which I
understand is only available at bkbits.net.
As far as I know, the only way to follow updates to the offical tree
is using the BitKeeper network protocol.
And I have not been able to find any documentation of that protocol.
(I hope it is not necessary to reverse engineer it!)
My question
-----------
Larry, or anyone else, can you direct me to the information I need to
track the kernel development tree in real time? A document describing
the BitKeeper network protocol would be ideal.
I don't require to use the bk protocol - but if it that is as
efficient as you say on the bitmover.com web site, that would be nice.
Please note that I am _not_ writing a bk clone, or any other
significant VC project. However I do wish to use my own software to
analyse changes to the Linux kernel as they are checked in, and I
think that is a reasonable request.
Thanks in advance,
-- Jamie Lokier
I'm starting to think that one cannot legally use BitKeeper as the
preferred means of developing a GPLed program. The problem is, the
GPL defines the source as the preferred base to modify the software
from and requires you to be able to distribute the source without any
additional licensing requirements.
If BitKeeper is the version management tool, then BitKeeper is part
of the source by this definition. Providing the source in BK form
without BK is as useless as providing it encrypted. Providing it in
any other form does not satisfy the GPL (assuming that BK form is in
fact the preferred way of modifying it).
DS
Jamie Lokier <[email protected]> wrote:
>
> Thus far, the best solution I have for tracking checkins is to rsync
> the SCCS files from Rik's mirror, and use a Perl script to extract the
> head version from each SCCS file.
Do you not use
http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/
?
It always has the latest diff against the last-released kernel.
I snarf it hourly, so I have decent granularity for doing the
binary-search-to-see-where-it-broke trick.
#!/bin/sh
URL=ftp://ftp.kernel.org/pub/linux/kernel/v2.5/testing/cset/
cd /opt/downloads/bk
rm -f index.html
wget --quiet $URL/index.html
VERSION=$(grep 'patches since' index.html | \
head -1 | \
sed -e 's/.*since \([^:]*\).*/\1/')
mkdir -p $VERSION
cd $VERSION
wget --quiet --timestamping --recursive $URL 2>&1
David Schwartz wrote:
> I'm starting to think that one cannot legally use BitKeeper as the
> preferred means of developing a GPLed program. The problem is, the
> GPL defines the source as the preferred base to modify the software
> from and requires you to be able to distribute the source without any
> additional licensing requirements.
It doesn't require that you distribute the tools for editing the
source, though. For example I believe it is fine to distribute a
program for Microsoft Visual Studio, in the form of the files you
would actually use with Visual Studio, even though the format of some
of those files is not documented.
> Providing the source in BK form without BK is as useless as
> providing it encrypted. Providing it in any other form does not
> satisfy the GPL (assuming that BK form is in fact the preferred way
> of modifying it).
I disagree, because the BK file format is actually quite well
documented - it is SCCS with some annotations that do not seem
essential if you are using a different tool.
The data is easily extracted using an SCCS-compatible tool. It is
certainly not encrypted, and I had no difficulty writing a Perl script
to extract any version of the source, although I have yet to look if
changesets are so easy as individual files.
Credit to Larry, for choosing an easily read file format.
(Although not perfectly - see the CSSC documentation for some things
that they are not sure how to decode in an SCCS file - and yes, those
do appear in BK-generated SCCS files from time to time).
> If BitKeeper is the version management tool, then BitKeeper is part
> of the source by this definition.
Linus and other people have said repeatedly that BitKeeper is _not_
essential to working with them on the kernel.
That said, it does seem that if you can't read bkbits.net, then you
are at a disadvantage sometimes.
-- Jamie
Andrew Morton wrote:
> > Thus far, the best solution I have for tracking checkins is to rsync
> > the SCCS files from Rik's mirror, and use a Perl script to extract the
> > head version from each SCCS file.
>
> Do you not use
>
> http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/
Oh, thanks. I didn't know about that.
> It always has the latest diff against the last-released kernel.
It is updated in real time then?
(Assuming yes) that reduces the need to talk bk protocol quite a lot :)
(I'd still like to, though).
> I snarf it hourly, so I have decent granularity for doing the
> binary-search-to-see-where-it-broke trick.
Good idea.
-- Jamie
As far as I can tell your complaint is that you can't have access to
the up to minute source view without using something which violates
your politics.
The fact that you can get almost real time views via one of many BK to
tarball/patch mirrors seems to not be good enough.
I guess I don't know how to help you. As far as I can tell, if Linus
wasn't using BK he'd still be doing what he was doing up until he started
using BK which means you wouldn't have the option of the up to date
snapshots you can currently get.
The basis of your complaint seems to be "BK makes some things possible
which weren't possible before, my politics don't let me use BK but I
want the advantages which would come from using BK". I'm sorry, but
I don't know what to do to help you. The part of BK you'd like me to
disclose is something that we consider quite valuable and unique to our
product and we have no intention of disclosing how it works.
I fail to see why this is such a big deal, you now have up to the
hour snapshots in the form you want where before you had to wait weeks
between releases. That's a dramatic improvement over what you had a
year ago and complaining that you can't have up to the minute views of
the source when the only reason is your politics, well, is it going to
seem really unreasonable if I think that maybe your politics are getting
in the way of your technical goals?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Larry McVoy wrote:
>As far as I can tell your complaint is that you can't have access to
>the up to minute source view without using something which violates
>your politics.
>
>
>
I agree with your sentiment, but you mis-characterize one thing. Jamie
was stating that his interpretation of the BitKeeper license forbade him
to use the free version of BitKeeper because of some of his non-kernel
related activities. This does seem to be a fair interpretation of the
license, according to clause 3-d, and has nothing to do with his
politics. Jamie is stating that it would be illegal for him to use
BitKeeper. Whether or not you agree with the use of BitKeeper for linux
kernel maintenance, it would seem like this is an unnecessarily onerous
clause that prevents some individuals from participating on an equal
footing with everybody else.
-Tupshin
Clause 3-d:
Notwithstanding any other terms in this License, this
License is not available to You if You and/or your employer
develop, produce, sell, and/or resell a product which con-
tains substantially similar capabilities of the BitKeeper
Software, or, in the reasonable opinion of BitMover, com-
petes with the BitKeeper Software.
Larry McVoy wrote:
> As far as I can tell your complaint is that you can't have access to
> the up to minute source view without using something which violates
> your politics.
No, without something that violates your license. Nice of him to actually
respect it :-)
> The fact that you can get almost real time views via one of many BK to
> tarball/patch mirrors seems to not be good enough.
>
> I guess I don't know how to help you. As far as I can tell, if Linus
> wasn't using BK he'd still be doing what he was doing up until he started
> using BK which means you wouldn't have the option of the up to date
> snapshots you can currently get.
Yes, a huge thank-you for making this possible... it's easy to forget that
the max wait time is now an hour, and it used to be weeks... linus's brain
is a much harder protocol to mirror than bk :-)
> I fail to see why this is such a big deal, you now have up to the
> hour snapshots in the form you want where before you had to wait weeks
> between releases. That's a dramatic improvement over what you had a
> year ago and complaining that you can't have up to the minute views of
> the source when the only reason is your politics, well, is it going to
> seem really unreasonable if I think that maybe your politics are getting
> in the way of your technical goals?
Well, I would point out that it's not politics, but rather respect for your
licensing terms that prevents him from using bk. (this part got snipped
relatively early, maybe you missed it)
> Although I am unfortable using closed source software, it seemed
> pragmatic to fetch and install BitKeeper. I went to bitmover.com, and
> read the free license before downloading:
>
> http://www.bitkeeper.com/Sales.Licensing.Free.html
>
> That looked ok. I am allowed to use it. Great!
>
> So I downloaded version 3.0, and typed "bk help bkl". I found that
> the license with the software is different to the licence on the web
> page.
>
> [Note to Larry, you may wish to update the above URL to the
> current version].
>
> Unfortunately, the license that comes with the download adds a new
> clause 3(d): that's the clause which tells me that actually I'm not
> allowed to use BitKeeper, because of other software I occasionally
> work on. (No, I do not work on Subversion, but I do occasionally
> dabble with sophisticated version management scripts).
>
> So, being conscientious and obedient, I removed BitKeeper from my system.
So, as you said you would consider case by case license grants if this
clause became a problem when it was last discussed (IIRC anyway, I don't
mean to put words in your mouth if I'm remembering that thread wrong),
maybe this would be a good time for one. Or he can use the hourly changeset
mirror :-)
(Whoops, sorry Larry, it's appropriate to include l-k in To:).
Larry McVoy wrote:
> As far as I can tell your complaint is that you can't have access to
> the up to minute source view without using something which violates
> your politics.
No; my complaint is that I'm not _allowed_ to use BitKeeper.
I'll use it if you say it's ok. Do you grant me permission?
Your license seems to request that I don't use it, because of other
programs I work on which have nothing to do with the kernel or
politics. I'm not going to enumerate them; suffice to say I think
they fall under clause 3(d) of the bkl. I could be mistaken.
(It seems ironic, given that you and I share an interest - in tools to
improve the software engineering process).
Thanks,
-- Jamie
ps. Yes I know it's possible to pay - if I had any money.
pps. I was also letting you know you might like to update your web
page, which is out of date.
I've sent Jamie mail asking him why he things 3(d) is a problem for him,
we'll see what he says. If he's working on things that compete with BK
then the answer is no, if he's not, then there is no problem.
We want to help the kernel team, that should be obvious. I draw the line
where helping the kernel team hurts BitMover, as would any of you in my
position. Fortunately, it's pretty rare that anyone talented enough to
work on the kernel also wants to work on source management.
We could change the license to have the standard legalese which says you
can't reverse engineer, etc. If the community at large would prefer that,
we could discuss it. I suspect that when you realize the implications of
that legalese, the BKL will seem a lot nicer by comparison. Would you
rather have something like:
You may not yourself and may not permit or enable anyone to: (i) modify or
translate the Software; (ii) reverse engineer, decompile, or disassemble the
Software or otherwise reduce the Software to a form understandable by humans,
except to the extent this restriction is expressly prohibited by applicable
law notwithstanding this limitation; (iii) rent, lease, loan, resell or cre-
ate derivative works based on the Software; (iv) merge the Software with
another product; (v) separate the Software into its component parts; (vi)
copy the Software, except (A) as expressly provided herein and (B) as reason-
ably necessary for back up and recovery purposes; or (vii) remove or obscure
any proprietary rights notices, labels, copyrights, trademarks, servicemarks,
confidentiality notices and/or restricted rights notices on or in the Soft-
ware.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, 18 Jan 2003 05:10:12 +0000, Jamie Lokier wrote:
>It doesn't require that you distribute the tools for editing the
>source, though. For example I believe it is fine to distribute a
>program for Microsoft Visual Studio, in the form of the files you
>would actually use with Visual Studio, even though the format of
>some of those files is not documented.
So then suppose the tool I use for modifying the source code
unpacks/decrypts it, allows changes, and then packs/encrypts it
again. Suppose further that this tool is proprietary and not
available without onerous licensing requirements. Would you say
releasing the source code thus packed/encrypted meets the GPL?
If not, then what would? The decrypted/unpacked form of the source
is not the preferred form for making modifications.
It seems to me that if you can't distribute the source in its
preferred form for modification such that it can actually be used and
modified without complying with some other more restrictive license,
you cannot comply with the GPL. The alternative is to say that you
can distribute utterly useless "source" and still comply with the
GPL.
Anyway, this has veered off-topic for this list. I apologize for
that.
DS
David Schwartz wrote:
> So then suppose the tool I use for modifying the source code
> unpacks/decrypts it, allows changes, and then packs/encrypts it
> again. Suppose further that this tool is proprietary and not
> available without onerous licensing requirements. Would you say
> releasing the source code thus packed/encrypted meets the GPL?
I think that if you distribute a program in Emacs-Lisp, but you don't
provide the Emacs-Lisp interpreter, that is considered ok. If you
distribute a program in Visual Basic under the GPL, that is considered
ok too. Similarly if it's a GPL'd Excel spreadsheet macro, or a
program written in Jonny's own version of Prolog.
However if you distribute obfuscated or encrypted files, then clearly
that's not the preferred form for making changes. If it's encrypted,
the preferred form obviously includes the decryption key. (And if the
code has to be signed to run, it might include the signing key - ooh).
I don't know where the line in the sand stops. It's not something GNU
people seem to worry much about, and neither do I as it is usually
quite clear cut one way or the other.
-----
About BitKeeper: if it were actually essential, I think you'd have a
point. But it isn't.
However, this begs another question: the kernel source is GPL'd. But
is the _repository_ at bkbits.net GPL'd? And if so, do I have the
right to demand a copy of the whole repository whenever I receive a
binary kernel, or is that right restricted to the checked out files
used to compile that kernel?
cheers,
-- Jamie
Larry McVoy wrote:
> I guess I don't know how to help you. As far as I can tell, if Linus
> wasn't using BK he'd still be doing what he was doing up until he started
> using BK which means you wouldn't have the option of the up to date
> snapshots you can currently get.
Oh, I agree that BK makes things possible that didn't happen before.
The only downside is that now Linus _assumes_ you can see what he's
doing - because that makes less work for him - which is fair enough
really. That's the best part of decent version management!
Anyway, I am mostly satisfied with the hourly patch link that Andrew
Morton pointed me to.
Thanks,
-- Jamie
Jamie Lokier <[email protected]> wrote:
>
> Larry McVoy wrote:
> > I guess I don't know how to help you. As far as I can tell, if Linus
> > wasn't using BK he'd still be doing what he was doing up until he started
> > using BK which means you wouldn't have the option of the up to date
> > snapshots you can currently get.
>
> Oh, I agree that BK makes things possible that didn't happen before.
Well. Many source management tools would give us the things we are now
enjoying. The main difference is that Linus is actually using one now.
Hi,
Larry McVoy wrote:
> I guess I don't know how to help you. As far as I can tell, if Linus
> wasn't using BK he'd still be doing what he was doing up until he started
> using BK which means you wouldn't have the option of the up to date
> snapshots you can currently get.
IOW "You should be thankful for what I offer, if you don't like it, piss
off!"
Might not be what you've intended, but that's what I arrived here and
I'm sure I'm not the only one.
bye, Roman
On Jan 18, 2003 15:22 +0100, Roman Zippel wrote:
> Larry McVoy wrote:
> > I guess I don't know how to help you. As far as I can tell, if Linus
> > wasn't using BK he'd still be doing what he was doing up until he started
> > using BK which means you wouldn't have the option of the up to date
> > snapshots you can currently get.
>
> IOW "You should be thankful for what I offer, if you don't like it, piss
> off!" Might not be what you've intended, but that's what I arrived here and
> I'm sure I'm not the only one.
That's what he intended, and rightfully so. You now have things you didn't
have before (i.e. hourly snapshots of Linus' tree) and you still aren't
happy. I guess some people will never be happy with anything, so there is
no point in trying to appease them.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Andreas Dilger wrote:
> That's what he intended, and rightfully so. You now have things you didn't
> have before (i.e. hourly snapshots of Linus' tree) and you still aren't
> happy. I guess some people will never be happy with anything, so there is
> no point in trying to appease them.
Hey, I only asked, and I made it clear what I would be happy with.
-- Jamie
Hi,
Andreas Dilger wrote:
> > IOW "You should be thankful for what I offer, if you don't like it, piss
> > off!" Might not be what you've intended, but that's what I arrived here and
> > I'm sure I'm not the only one.
>
> That's what he intended, and rightfully so.
I just wanted to make sure I understood correctly, I have an appropriate
answer, but I can't word it as nicely as Larry.
> You now have things you didn't
> have before (i.e. hourly snapshots of Linus' tree) and you still aren't
> happy. I guess some people will never be happy with anything, so there is
> no point in trying to appease them.
If you don't see the problem, maybe you should read
/usr/src/linux/COPYING again for a change.
bye, Roman
On Jan 19, 2003 22:50 +0100, Roman Zippel wrote:
> Andreas Dilger wrote:
> > > IOW "You should be thankful for what I offer, if you don't like it, piss
> > > off!" Might not be what you've intended, but that's what I arrived here
> > > and I'm sure I'm not the only one.
> >
> > That's what he intended, and rightfully so.
>
> I just wanted to make sure I understood correctly, I have an appropriate
> answer, but I can't word it as nicely as Larry.
>
> > You now have things you didn't
> > have before (i.e. hourly snapshots of Linus' tree) and you still aren't
> > happy. I guess some people will never be happy with anything, so there is
> > no point in trying to appease them.
>
> If you don't see the problem, maybe you should read
> /usr/src/linux/COPYING again for a change.
There is nothing in the GPL which requires anyone to make their changes
available to you the minute they make them. The fact that you have access
to the changes within an hour of when they are made far exceeds the
requirements in the GPL, which only require that the source code be made
available if you distribute the OBJECT CODE OR EXECUTABLE.
If Linus uses BK to make pre-releases available to some people, that
does not appear to even invoke the "executable distribution" clause,
any more than him emailing patches to other developers privately. If
Linus started making kernel patches available via a Lotus Notes database
(heaven forbid, I think even the IBM folks agree on that one ;-) doesn't
mean that IBM suddenly has to make all the details of Lotus Notes
available, or that Linus is forbidden to use tools as he wants. There
are still lots of other ways to get the kernel source.
In fact (think about this for a while 8-o), EVERY SINGLE CHANGE that has
gone into the "official Linus kernel" had Linus doing the merge
(i.e. acting as editor of the combined work which is the kernel), which
may imply that Linus even owns a complete copyright over the entire
kernel source tree (i.e. compiled work). Since he has never (or not
in the last decade, AFAIK) distributed a binary or object version of
the kernel, it may be that he isn't under any obligation to do anything
related to distribution under the GPL. If you think that being the editor
of a combined work is not enough to give him copyright over the combined
work, then you need to learn your copyright law a bit more. If it wasn't
for Linus acting as a "gatekeeper", the kernel would be full of the crap
that makes up 99% of the sourceforge projects out there.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
On Sun, 19 Jan 2003 16:26:14 -0700, Andreas Dilger wrote:
>There is nothing in the GPL which requires anyone to make their
>changes
>available to you the minute they make them. The fact that you have
>access
>to the changes within an hour of when they are made far exceeds the
>requirements in the GPL, which only require that the source code be
>made
>available if you distribute the OBJECT CODE OR EXECUTABLE.
I think you're ignoring the way the GPL defines the "source code".
The GPL defines the "source code" as the preferred form for modifying
the program. If the preferred form of a work for purposes of
modifying it is live access to a BK repository, then that's the
"source code" for GPL purposes.
>There
>are still lots of other ways to get the kernel source.
You are using the conventional meaning of "source code", which is
roughly, "whatever you compile to get the executable". However, this
is not the "source" for GPL purposes. For GPL purposes, the source is
the preferred form of a work for purposes of modifying it.
This means you can't remove meta information that's useful for
modifying because that is not the preferred form. Such meta
information includes whatever is useful for modifying it, such as
revision history and chain of custody.
You can't have two "source"s, one a private repository that you
prefer to use for making changes and the other an "obfuscated" public
version you distribute for GPL compliance which is missing all the
other useful information.
Checking source out of a repository, separating away the revision
history, is an obfuscatory act. The GPL prohibits such source
obfuscation and requires you to distribute the source in whatever is
the actual preferred form for modifying it. Really. Sorry.
DS
On Jan 19, 2003 15:57 -0800, David Schwartz wrote:
> On Sun, 19 Jan 2003 16:26:14 -0700, Andreas Dilger wrote:
> >There is nothing in the GPL which requires anyone to make their
> >changes available to you the minute they make them. The fact that
> >you have access to the changes within an hour of when they are made
> >far exceeds the requirements in the GPL, which only require that the
> >source code be made available if you distribute the OBJECT CODE OR
> >EXECUTABLE.
>
> I think you're ignoring the way the GPL defines the "source code".
> The GPL defines the "source code" as the preferred form for modifying
> the program. If the preferred form of a work for purposes of
> modifying it is live access to a BK repository, then that's the
> "source code" for GPL purposes.
I think you are ignoring the fact that this clause (#3) in the GPL only
relates only if "you copy or distribute the Program (or a work based on
it, under Section 2) in object code or executable form".
> >There are still lots of other ways to get the kernel source.
>
> You are using the conventional meaning of "source code", which is
> roughly, "whatever you compile to get the executable". However, this
> is not the "source" for GPL purposes. For GPL purposes, the source is
> the preferred form of a work for purposes of modifying it.
>
> This means you can't remove meta information that's useful for
> modifying because that is not the preferred form. Such meta
> information includes whatever is useful for modifying it, such as
> revision history and chain of custody.
>
> You can't have two "source"s, one a private repository that you
> prefer to use for making changes and the other an "obfuscated" public
> version you distribute for GPL compliance which is missing all the
> other useful information.
>
> Checking source out of a repository, separating away the revision
> history, is an obfuscatory act. The GPL prohibits such source
> obfuscation and requires you to distribute the source in whatever is
> the actual preferred form for modifying it. Really. Sorry.
Again you are ignoring the fact that there are other methods by which
the source code is available in the "preferred form", just not quite as
timely as directly from the BK repository (which is itself in a form, SCCS,
which does not require BK to access), and there is nothing in the GPL which
requires that the source be made avaible instantly.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
On Sun, 19 Jan 2003 17:20:04 -0700, Andreas Dilger wrote:
>I think you are ignoring the fact that this clause (#3) in the GPL
>only
>relates only if "you copy or distribute the Program (or a work based
>on
>it, under Section 2) in object code or executable form".
Here's the problem. RedHat ships the code in "object code or
executable form". This requires them to distribute the source code in
the "preferred form for modifications". The problem is, the preferred
form for modifications might well be Linus' BK tree, which RedHat
might not even have!
>Again you are ignoring the fact that there are other methods by
>which
>the source code is available in the "preferred form", just not quite
>as
>timely as directly from the BK repository (which is itself in a
>form, SCCS,
>which does not require BK to access), and there is nothing in the
>GPL which
>requires that the source be made avaible instantly.
If you assume that live access to Linus' BK tree is the preferred
form for modifying the Linux kernel, then RedHat can't ship a
compiled kernel if they can't give people access to Linus'
repository.
The GPL is nonsense. Lots of people have suffered absurdities
similar to this one in a crazy attempt to comply with it. I think if
the people who *chose* it had to suffer its insanities a little,
they'd think twice the next time they choose a license for their open
source projects.
DS
On Sun, 19 Jan 2003 15:57:40 PST, David Schwartz said:
> I think you're ignoring the way the GPL defines the "source code".
> The GPL defines the "source code" as the preferred form for modifying
> the program. If the preferred form of a work for purposes of
> modifying it is live access to a BK repository, then that's the
> "source code" for GPL purposes.
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:
> 1. You may copy and distribute verbatim copies of the Program's
> source code as you receive it,
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...
> making modifications to it. For an executable work, complete source
> code means all the source code for all modules it contains, plus any
> associated interface definition files, plus the scripts used to
> control compilation and installation of the executable.
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
> So then suppose the tool I use for modifying the source code
> unpacks/decrypts it, allows changes, and then packs/encrypts it
> again. Suppose further that this tool is proprietary and not
> available without onerous licensing requirements. Would you say
> releasing the source code thus packed/encrypted meets the GPL?
It is not the preferred form for editing the source code,
so it is not the real source code as defined by the GPL.
However, this begs another question: the kernel source is GPL'd. But
is the _repository_ at bkbits.net GPL'd?
I believe the contents are all under the GPL.
And if so, do I have the
right to demand a copy of the whole repository whenever I receive a
binary kernel, or is that right restricted to the checked out files
used to compile that kernel?
Whoever distributes a binary kernel to you has the obligation to
offer you the complete source code corresponding to the binary.
Source code not used in producing that binary need not be
included.
On Sun, 19 Jan 2003 19:36:12 -0500, [email protected] wrote:
>Moral: Let's not get silly here...
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
On Sun, 19 Jan 2003 17:05:02 PST, David Schwartz said:
> 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".
Hmm... <ponders a bit>
> 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.
<ponders a bit more>
It's a red herring, folks.
The preferred form for *MAKING* modifications is a /usr/src/linux source
tree. The form that's in BitKeeper is in the preferred format for *tracking*
and *managing* changes. Remember - you have to check the source out of
the repository to do the edit/compile/test loop, and then commit it back
when you're done. So the BK repository isn't where actual development happens,
because gcc and make can't read the repository.
Of course, having written this, some damn fool will prove me wrong by writing
a 'bkfs' file system (similar to the various 'pgfs' front-ends for Postgres)
so you actually *CAN* do a 'make' of the repository :)
/Valdis
On Sun, 19 Jan 2003 [email protected] wrote:
> 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...
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
On Sun, 19 Jan 2003 [email protected] wrote:
> Date: Sun, 19 Jan 2003 16:36:12 -0800
> From: [email protected]
> To: David Schwartz <[email protected]>
> Cc: [email protected], Roman Zippel <[email protected]>,
> Larry McVoy <[email protected]>, [email protected]
> Subject: Re: Is the BitKeeper network protocol documented?
>
> On Sun, 19 Jan 2003 15:57:40 PST, David Schwartz said:
>
> > I think you're ignoring the way the GPL defines the "source
> code".
> > The GPL defines the "source code" as the preferred form for modifying
> > the program. If the preferred form of a work for purposes of
> > modifying it is live access to a BK repository, then that's the
> > "source code" for GPL purposes.
>
> 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:
>
> > 1. You may copy and distribute verbatim copies of the Program's
> > source code as you receive it,
>
> 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...
>
> > making modifications to it. For an executable work, complete source
> > code means all the source code for all modules it contains, plus any
> > associated interface definition files, plus the scripts used to
> > control compilation and installation of the executable.
>
> 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
>
>
Hi,
Andreas Dilger wrote:
> > > You now have things you didn't
> > > have before (i.e. hourly snapshots of Linus' tree) and you still aren't
> > > happy. I guess some people will never be happy with anything, so there is
> > > no point in trying to appease them.
> >
> > If you don't see the problem, maybe you should read
> > /usr/src/linux/COPYING again for a change.
>
> There is nothing in the GPL which requires anyone to make their changes
> available to you the minute they make them. The fact that you have access
> to the changes within an hour of when they are made far exceeds the
> requirements in the GPL, which only require that the source code be made
> available if you distribute the OBJECT CODE OR EXECUTABLE.
I knew I should have been more specific. It would have been enough to
read and understand the preamble.
"By contrast, the GNU General Public License is intended to guarantee
your freedom to share and change free software--to make sure the
software is free for all its users. [..] When we speak of free software,
we are referring to freedom, not price."
The GPL is intended to protect our freedom. How does BK fit in here? BK
is not free and even worse not everyone is allowed to use it. You don't
see a small discrepancy here?
The few who are allowed to use it have to use considerable extra effort
to make the source available to people who can't or don't want to use
BK. How does this help to promote freedom? Is the convenience of a few
really helping here?
The actual license is more for lawyers, but for the users it's a lot
more important to at least understand the preamble. It's a real pity how
easily users forget about this and only think of their own short term
advantage. Only because they can use something for free, they believe
they gained some kind of freedom, but what is this "freedom" worth if it
depends on the mercy of others or it can't be shared with others? In the
end it's the decision of every user what they do, but at least they
shouldn't fool themselves.
bye, Roman
On Sun, 2003-01-19 at 20:05, David Schwartz wrote:
> 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".
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
:)
On Sun, Jan 19, 2003 at 03:57:40PM -0800, David Schwartz wrote:
> I think you're ignoring the way the GPL defines the "source code".
> The GPL defines the "source code" as the preferred form for modifying
> the program. If the preferred form of a work for purposes of
> modifying it is live access to a BK repository, then that's the
> "source code" for GPL purposes.
You're being insane. The preferred form is still the C source code.
You can store that C source code in many different forms. For
example, I could put that C code in a CVS source repository, and only
allow access to it to core team members. Many other open source
projects do things that way. And many other open source projects
don't give raw access to the CVS source repository. Sometimes this is
necessary, if they need to fix a security bug before it is announced
to the entire world.
The GPL does not guarantee that you have access to the master source
repository, whether it is stored in a CVS repository, or a BK
repository. And whether the master source repository is CVS or BK,
the preferred form for modifications doesn't change; it's still the C
code.
> You are using the conventional meaning of "source code", which is
> roughly, "whatever you compile to get the executable". However, this
> is not the "source" for GPL purposes. For GPL purposes, the source is
> the preferred form of a work for purposes of modifying it.
You don't run emacs on the CVS ,v files, or BK's s. files. That's
just the container. It's no different from the raw underlying
filesystem format.
You need to distinguish between how information is stored, and the
information itself. If I store the master repository for an Open
Source project on an NTFS filesystem, does that make the NTFS
filesystem part of the preferred form? Of course not! You might have
to use the NTFS filesystem to get at the sources, but that doesn't
make it part of the preferred form.
- Ted
>You need to distinguish between how information is stored, and the
>information itself. If I store the master repository for an Open
>Source project on an NTFS filesystem, does that make the NTFS
>filesystem part of the preferred form? Of course not! You might
>have
>to use the NTFS filesystem to get at the sources, but that doesn't
>make it part of the preferred form.
> - Ted
I think you're deliberately glossing over a critical distinction.
Taking source code out of an NTFS filesystem and packing it up in a
tarball doesn't obfuscate the source and in no way affects your
ability to make changes to the source. Taking source code out of a
version control system obfuscates the rationale for changes and makes
it more difficult to modify the source.
I would argue that if the development of a project is based around a
version control system, checking the source out of that version
control system is equivalent to stripping the comments out of it.
The GPL makes it quite clear that the source code is not "whatever
you can compile to get the executable", but it is the source code in
its preferred form for modifications. The loss of metainformation
helpful to modifying the source, such as check-in comments, is
different from the loss of irrelevant metainformation such as inode
numbers.
DS
David Schwartz <[email protected]> said:
> On Sun, 19 Jan 2003 16:26:14 -0700, Andreas Dilger wrote:
> >There is nothing in the GPL which requires anyone to make their >changes
> >available to you the minute they make them. The fact that you have
> >access to the changes within an hour of when they are made far exceeds
> the requirements in the GPL, which only require that the source code be
> >made available if you distribute the OBJECT CODE OR EXECUTABLE.
> I think you're ignoring the way the GPL defines the "source code".
> The GPL defines the "source code" as the preferred form for modifying
> the program. If the preferred form of a work for purposes of
> modifying it is live access to a BK repository, then that's the
> "source code" for GPL purposes.
You are a lawyer working in this area, and so can cite chapter and verse
where this definition was made (the GPL text is rather vague)?
Anyway, Andreas Dilger is (curiously) right AFAIU: Linus has _never_
distributed a binary to anybody AFAIK, so he is under no obligation by the
GPL do give out any form of source. Furthermore, as he is (in the editor
sense at least) copyright holder for the whole source, he isn't bound by
the GPL in any case. ;-)
IANAL, etc.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
On 20 Jan 2003 09:28:35 -0500, Dana Lacoste wrote:
>On Sun, 2003-01-19 at 20:05, David Schwartz wrote:
>> 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".
>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'.
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.
>Please stop this. You're looking kind of silly here.
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.
>PS: nobody said 'IANAL' yet. meaning you're just a noisy peanut
>gallery
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
On Mon, 20 Jan 2003, David Schwartz wrote:
> Date: Mon, 20 Jan 2003 11:00:35 -0800
> From: David Schwartz <[email protected]>
> To: [email protected]
> Cc: [email protected]
> Subject: Re: Is the BitKeeper network protocol documented?
>
> On 20 Jan 2003 09:28:35 -0500, Dana Lacoste wrote:
>
> >On Sun, 2003-01-19 at 20:05, David Schwartz wrote:
>
> >> 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".
>
> >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'.
>
> 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.
>
> >Please stop this. You're looking kind of silly here.
>
> 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.
>
> >PS: nobody said 'IANAL' yet. meaning you're just a noisy peanut
> >gallery
>
> 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
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Mon, 20 Jan 2003 16:52:56 +0100, Horst von Brand wrote:
>> I think you're ignoring the way the GPL defines the "source
>>code".
>>
>>The GPL defines the "source code" as the preferred form for
>>modifying
>>the program. If the preferred form of a work for purposes of
>>modifying it is live access to a BK repository, then that's the
>>"source code" for GPL purposes.
>You are a lawyer working in this area, and so can cite chapter and
>verse
>where this definition was made (the GPL text is rather vague)?
Nobody knows, that's definitely part of the problem. If you
genuinely want to make a good faith effort to comply with the GPL,
I'm not sure what you can do other than guess.
>Anyway, Andreas Dilger is (curiously) right AFAIU: Linus has _never_
>distributed a binary to anybody AFAIK, so he is under no obligation
>by the
>GPL do give out any form of source. Furthermore, as he is (in the
>editor
>sense at least) copyright holder for the whole source, he isn't
>bound by
>the GPL in any case. ;-)
The problem then occurs with companies like RedHat. They distribute
binaries, so they must distribute the source in the preferred form
for making modifications to it. *If* metainformation in Linus' BK
tree is part of the preferred version of the work for the purposes of
making modifications to it, then RedHat *cannot* comply with the GPL.
Checking source code out of a repository is an obfuscatory act that
separates the raw source code from the rationale for that source
code. It's equivalent to stripping comments. The GPL does not allow
you to obfuscate the source, so if all *you* have is obfuscated
source, *you* cannot ship binaries.
I don't think this is currently an issue for the Linux kernel.
However, it may well be an issue for projects using things like
sourceforge or using proprietary file formats to hold portions of
their source.
DS
On Mon, 20 Jan 2003 16:52:56 +0100, Horst von Brand wrote:
>> I think you're ignoring the way the GPL defines the "source
>>code".
>>
>>The GPL defines the "source code" as the preferred form for
>>modifying
>>the program. If the preferred form of a work for purposes of
>>modifying it is live access to a BK repository, then that's the
>>"source code" for GPL purposes.
>You are a lawyer working in this area, and so can cite chapter and
>verse
>where this definition was made (the GPL text is rather vague)?
Nobody knows, that's definitely part of the problem. If you
genuinely want to make a good faith effort to comply with the GPL,
I'm not sure what you can do other than guess.
>Anyway, Andreas Dilger is (curiously) right AFAIU: Linus has _never_
>distributed a binary to anybody AFAIK, so he is under no obligation
>by the
>GPL do give out any form of source. Furthermore, as he is (in the
>editor
>sense at least) copyright holder for the whole source, he isn't
>bound by
>the GPL in any case. ;-)
The problem then occurs with companies like RedHat. They distribute
binaries, so they must distribute the source in the preferred form
for making modifications to it. *If* metainformation in Linus' BK
tree is part of the preferred version of the work for the purposes of
making modifications to it, then RedHat *cannot* comply with the GPL.
Checking source code out of a repository is an obfuscatory act that
separates the raw source code from the rationale for that source
code. It's equivalent to stripping comments. The GPL does not allow
you to obfuscate the source, so if all *you* have is obfuscated
source, *you* cannot ship binaries.
I don't think this is currently an issue for the Linux kernel.
However, it may well be an issue for projects using things like
sourceforge or using proprietary file formats to hold portions of
their source.
DS
On Mon, 20 Jan 2003 11:31:53 -0800 (PST), David Lang wrote:
>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 company to GPL their version
>control system?
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
On Mon, 20 Jan 2003 11:43:48 PST, David Schwartz said:
> Checking source code out of a repository is an obfuscatory act that
> separates the raw source code from the rationale for that source
> code. It's equivalent to stripping comments. The GPL does not allow
So is shipping the source without the transcript of the kernel developer's
conference, because then you're stripping out some of the design rationale.
So is shipping the source without a neuron dump of the programmer - let's face
it, we've ALL looked at code and said "What WERE they thinking?", and therefor
a neuron dump would be part of the *preferred* format.
You seem determined to obfuscate the issue by confusing the *SOURCE* that
actually gets modified, and metainformation used to keep TRACK of the source.
Quick sanity test:
Do people actually modify the BK repository, or do they check it out
so they can actually modify *THE CHECKED OUT TREE*? Last I heard, people
actually did edits on the source tree, and they used gcc (or whatever compiler)
on the source tree. Then they make diffs between the old tree and new tree
and send them to Linus.
Seems to *ME* that since almost all of the source code was actually
created in a '(vi|emacs) / make / gcc / diff' environment, that is the
PREFERRED format for making modifications.
Don't confuse the source tree with metainformation, or you'll end up having
to carry around inode information. Lest you think I'm joking, consider the
fact that the original Crowther&Woods Adventure game was called 'ADVENT.FOR',
and the case and number of chars was actually significant information....
> >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 company to GPL their version
> >control system?
>
> 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.
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.
On Jan 20, 2003 12:19 -0800, David Schwartz wrote:
> On Mon, 20 Jan 2003 11:31:53 -0800 (PST), David Lang wrote:
> >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 company to GPL their version
> >control system?
>
> 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.
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.
> 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.
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/
On Mon, 20 Jan 2003 13:48:31 -0700, Andreas Dilger wrote:
>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).
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 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.
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.
>>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.
>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.
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
On Mon, 20 Jan 2003 15:32:53 -0500, [email protected] wrote:
>On Mon, 20 Jan 2003 11:43:48 PST, David Schwartz said:
>>Checking source code out of a repository is an obfuscatory act
>>that
>>separates the raw source code from the rationale for that source
>>code. It's equivalent to stripping comments. The GPL does not allow
>So is shipping the source without the transcript of the kernel
>developer's
>conference, because then you're stripping out some of the design
>rationale.
If a transcipt of the developer's conference is part of the
preferred form of the source for making modifications, then the
GPL requires that you distribute that. I would argue that it probably
isn't, but if many of the developers have access to that transcript
it and use it while they make modifications, then it's an arguable
point.
>So is shipping the source without a neuron dump of the programmer -
>let's face
>it, we've ALL looked at code and said "What WERE they thinking?",
>and therefor
>a neuron dump would be part of the *preferred* format.
If the people who make most of the modifications have access to and
use such a dump in the process of making modifications, then it would
probably be part of the preferred form.
>You seem determined to obfuscate the issue by confusing the *SOURCE*
>that
>actually gets modified, and metainformation used to keep TRACK of
>the source.
You seem determined to pretend that by "source" the GPL means
"whatever you can compile to create the executable" when it clearly
says otehrwise.
>Don't confuse the source tree with metainformation, or you'll end up
>having
>to carry around inode information. Lest you think I'm joking,
>consider the
>fact that the original Crowther&Woods Adventure game was called
>'ADVENT.FOR',
>and the case and number of chars was actually significant
>information....
The test seems to be whether the metainformation is actually useful
in the process of making modifications or, to put it another way,
whether the people making such modifications prefer to have that
information. I would certainly prefer to have change history and
commit rationales. If the people who actually make most of the
modifications actually have access to and use that information in the
process of making modifications, I don't see how you can argue that
this information isn't part of the source as defined by the GPL.
Keeping the comments in a different file and claiming that's not
part of the source is completely equivalent to stripping the comments
from the source before you distribute it. The GPL doesn't permit
obfuscated source. "Just enough to compile it" isn't sufficient. It
requires the "preferred form" for making modifications. If this
actually includes design rationale documents, revision history, and
other such things, then they are part of the source.
The intent of the GPL seems to be to put "outside" developers on the
same footing as "inside" developers. Being able to withhold
development information that is actually useful for making
modifications seems to be prohibited.
This leaves interesting questions like how you can GPL a project
that includes signed components.
DS
> 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.
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
On Mon, 20 Jan 2003, David Schwartz wrote:
> 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.
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>
> The GPL just says you have to distribute the source in its preferred
> form for making modifications.
What if BK *is* the perferred form?
John.
I want a lock of David Millers hair with every TCP/IP stack patch. Without
the hair, I cannot make my vodoo doll and without that I have nothing.
David Schwartz <[email protected]>
> On Mon, 20 Jan 2003 16:52:56 +0100, Horst von Brand wrote:
> >> I think you're ignoring the way the GPL defines the "source
> >>code".
> >>The GPL defines the "source code" as the preferred form for modifying
> >>the program. If the preferred form of a work for purposes of
> >>modifying it is live access to a BK repository, then that's the
> >>"source code" for GPL purposes.
> >You are a lawyer working in this area, and so can cite chapter and
> >verse where this definition was made (the GPL text is rather vague)?
> Nobody knows, that's definitely part of the problem. If you
> genuinely want to make a good faith effort to comply with the GPL,
> I'm not sure what you can do other than guess.
Well, as a license is in escence a promise not to sue you for using my
property as long as you comply with certain conditions, it will then be up
to the licensors. If Linus is OK with distributing just tar.bz2's, its OK
for the kernel. Also, RMS specifically said using bk doesn't make the
repository source in the GPL sense (this is presumably the intention the
FSF will put forward, and which most other GPL-licensing parties will
agree).
IANAL (and happy for it ;-)
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
David Schwartz <[email protected]> said:
[...]
> >So is shipping the source without a neuron dump of the programmer -
> >let's face
> >it, we've ALL looked at code and said "What WERE they thinking?",
> >and therefor
> >a neuron dump would be part of the *preferred* format.
> If the people who make most of the modifications have access to and
> use such a dump in the process of making modifications, then it would
> probably be part of the preferred form.
Hummm. _now_ I see the fundamental problem: The GPL isn't distributed with
a neuron dump of RMS so we can check what he meant by "preferred format".
Seems the GPL is being distributed illegally...
[Can we let this die, now? Pretty please?]
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
On Mon, 2003-01-20 at 14:00, David Schwartz wrote:
> 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.
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
On 21 Jan 2003 11:04:31 -0500, Dana Lacoste wrote:
>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.
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
> 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.
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.
On Tue, Jan 21, 2003 at 10:34:12AM -0800, David Schwartz wrote:
> 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.
The commit comments are available, so why arguing?
Sam
On Tue, Jan 21, 2003 at 10:34:12AM -0800, David Schwartz wrote:
> 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.
But people don't make changes with BitKeeper, they record them. So if
you want to push this point, you need to address 2 sections of the GPL:
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
It's extremely easy to argue that putting a work in BK, CVS, a file
system, a tarball, whatever, is "mere aggregation". Just because you
put a GPLed program on a Windows PC does not make the Windows NTFS
metadata GPLed. The same is true for any storage container.
The source code for a work means the preferred form of the work for
making modifications to it.
People modify source code with editors. No source management system
modifies the data, just as tar doesn't modify the data and a file system
doesn't modify the data. So this statement doesn't make your case and
it seems to be the cornerstone of your case.
You'd have a much stronger argument if BitKeeper was an editor or an
IDE in which people made changes. You could perhaps make the case that
Visual Slickedit (or some other commercial editor) had to come with the
source if everyone were using that editor to make changes.
I don't think you have a case. There is a fair amount of case law which
makes it clear that no matter what a license says, it can't overstep
the law. A good one was on slashdot in the last few days, some company
had a fairly standard "you can't benchmark this and report results"
and someone challenged it and won. The license was telling you that
you couldn't do something that you had the legal right to do, so that
part of the license was overturned.
I think your "preferred form" argument falls into a similar camp. It may
be that you and the rest of the world decide that your preferred form
is the BK repositories; unless enforcing that is actually legal, your
decision is meaningless, it has no legal weight. I strongly believe that
what you are suggesting is not legal and I'm pretty sure IBM's lawyers
have looked deeply into this and they share my belief. There is a fair
amount of case law concerning the boundaries and limits of a license.
I think if you go dig into it, you'll find that you can reach out across
clear boundaries. Trying to apply the GPL to the metadata of a container,
be it an SCM system or a file system or an archival system, is crossing
clear boundaries and the law could care less what you prefer, a boundary
is a boundary is a boundary.
I'm not a lawyer. I have spent a fair bit of money in legal fees looking
into this topic, however, so I'm not exactly ignorant on the topic either.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Tue, 2003-01-21 at 13:34, David Schwartz wrote:
> On 21 Jan 2003 11:04:31 -0500, Dana Lacoste wrote:
>
> >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.
> This can't be right for two reasons.
>
> First, I would in fact prefer to have the version control
> information to make changes.
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.
> 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.
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.
> 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.
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?
> 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.
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.)
> 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.
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.
> 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.
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....
:) :) :) :)
> 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.
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 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.
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
> 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.
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.
>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.
...
>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.
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.
>Dana "Why didn't David reply in private to the private reply?"
I did. I replied privately to your private replies and publicly to
your public replies.
DS
Hua Zhong wrote:
> > 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.
>
> 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).
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.)
> The argument that "BK hosts GPL project so BK has to be GPL'd" is also
> ridiculous.
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
On Wed, 22 Jan 2003 07:10:28 +0000, Jamie Lokier <[email protected]>
wrote:
>Hua Zhong wrote:
>> > 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.
>>
>> 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).
>
>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.
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
On Fri, 17 Jan 2003, Larry McVoy wrote:
> As far as I can tell your complaint is that you can't have access to
> the up to minute source view without using something which violates
> your politics.
Not his politics. These no-competition clauses quickly extend to where
you don't expect them, unintentionally.
> I guess I don't know how to help you. As far as I can tell, if Linus
> wasn't using BK he'd still be doing what he was doing up until he started
> using BK which means you wouldn't have the option of the up to date
> snapshots you can currently get.
I'd translate it to the old "have a GP/BSD-licensed tool to just check
out the stuff" (and leave modifications to some party that is entitled
to the full BK version by whatever means, no competition + openlogging
for instance or something). You mentioned CSSC in the past, but AFAIR,
that's for local uncompressed repositories only.
On Wed, Jan 22, 2003 at 07:10:28AM +0000, Jamie Lokier wrote:
> 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.)
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
On Wed, 2003-01-22 at 10:18, Larry McVoy wrote:
> 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.
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
On Wed, Jan 22, 2003 at 10:27:40AM -0500, Dana Lacoste wrote:
> On Wed, 2003-01-22 at 10:18, Larry McVoy wrote:
>
> > 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.
>
> Thus the concept of "derivative work."
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