[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