[PATCH] fdisk.c: major whitespace/style cleanup
Bernd Petrovitsch
bernd at firmix.at
Sun Feb 26 14:10:18 UTC 2006
On Sat, 2006-02-25 at 11:15 -0500, Rob Landley wrote:
> On Saturday 25 February 2006 6:57 am, Bernd Petrovitsch wrote:
> > On Sat, 2006-02-25 at 10:46 +0300, Vladimir N. Oleynik wrote:
> > > Bernd Petrovitsch wrote:
> > > > You have to choose: Either if *is* GPL (as the license on th orignal
> > > > seem to imply), then please delete that "condition" or it is not GPL
> > > > which implies that you
> > >
> > > Each author has the inseparable right to own work.
> >
> > Yes, but first this comes out of local jurisdiction (which is - judging
> > from your email address - Russia and I know nothing about Russian law)
> > and second this cannot invalidate some parts of the GPL and leave others
> > intact.
> > -) US copyright allows you transfer the copyright completely without
> > trace or whatever.
>
> You need a written instrument of conveyance explicitly transferring a
> copyright. (You basically need a signed physical piece of paper. It's one
> of the central issues in the current SCO vs Novell litigation being covered
> on Groklaw.)
>
> But that's a side issue. Licenses don't transfer copyright, they're give
Not necessarily, yes.
> people conditional permission to exercise the rights that copyright reserves
> to the owner of the copyright, as long as the conditions are met.
[...]
> Having a copyright on a derived work doesn't absolve you of the license terms
> applicable to the base work you derived from. Vladimir obviously doesn't
> understand this.
Yes. To put it even further: If I patch GPL code, I have at most the
copyright/authors rights (if any) to my modificiations and especially
not to the rest of it.
[....]
> > But this can't and/or doesn't remove the GPL from busybox and each
> > "producer" of these "non-GPL products" must at least offer the source
> > code and build description (+ toolchain if necessary) for the GPL parts
> > of that product.
>
> The "+ toolchain if necessary" is probably unenforceable. Makefiles could be
> considered a necessary part of the source code (and unique to your project),
They contain the build "instructions" so I consider such files a
necessary part to comply with the GPL (but IANAL).
> but if you compiled a binary with Microsoft Visual C you can't be made to
> distribute Microsoft Visual C to comply with the GPL. The GPL doesn't apply
Of course (and I didn't want to imply that. My wording was here
apparently too strict).
> to the operating system you run it on either, because it's not a derived work
> of that. (A documented API is a good boundary here.)
It is enough to have "one toolchain" to build the source - not
necessarily the one which is prefered or actually used by the
maintainers and/or real users.
Reason: The "toolchain" rule is required to not use a programming
language where I own the only compiler in the world and have everything
on that programming language and all related tools trademarked,
patented, etc.
So for (more or less plain) C/C++ it is probably enough to have a
Makefile for VC++ and people trying to compile that source can fix the
options and similar problems.
> The GPL only applies to what the copyright covers, and there are boundaries to
> what is considered a derived work (which have to do with established
> copyright law and legal precedents). The boundaries are a bit squishy and
> arguable, but asking for the compiler and the OS is way the heck over them.
> (Your copyright on a document doesn't apply to the word processor used to
> compose the document, either.)
ACK. But it makes sense to store that document (or source code) in a
file format which is actually known by text editors/word processors
enough to be actually of use (even if e.g. unnecessary formatting is
partly lost).
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
More information about the busybox
mailing list