Re: Disgusted with kbuild developers

Re: Disgusted with kbuild developers

[Giacomo Catenazzi]

Daniel Phillips wrote:

>>. A Microsoft engineer wrote scripts/Configure.  For three years, I have
>>  lived in fear that Microsoft would notice this fact and use it to attack
>>  Linux through public relations channels or legal means.  They haven't yet,
>>  so I have been wrong so far.
>>
> 
> Teehee.  I don't think you have anything to worry about, Microsoft would be
> incredibly embarassed to admit they're contributing to 'problem number 1'.


I agree, but we know some strange 'behaviour' of MS.
They have a lot of lawers, they can make us a lot of trouble.
(You will notice that there are no copyright statment on that file,
only the name of authors).

Remember the RMS (a flame with the word 'ESR' MUST have also the 'RMS' :-))
way to include 'free' patches: sign and send to FSF a piece of paper,
that the patches CAN be included.
I think nobody in Linux have done that, thus we can expect some
more troubles and microsoft is a large troubles-maker

	giacomo

Re: Disgusted with kbuild developers

[Alexander Viro]

On Tue, 19 Feb 2002, Giacomo Catenazzi wrote:

> I agree, but we know some strange 'behaviour' of MS.
> They have a lot of lawers, they can make us a lot of trouble.
> (You will notice that there are no copyright statment on that file,
> only the name of authors).
> 
> Remember the RMS (a flame with the word 'ESR' MUST have also the 'RMS' :-))
> way to include 'free' patches: sign and send to FSF a piece of paper,
> that the patches CAN be included.
> I think nobody in Linux have done that, thus we can expect some
> more troubles and microsoft is a large troubles-maker

... and script in question is fscking trivial to reimplement if and when it
happens.  End of story.

Re: Disgusted with kbuild developers

[Daniel Phillips]

On February 19, 2002 09:04 am, Giacomo Catenazzi wrote:
> Daniel Phillips wrote:
> >>. A Microsoft engineer wrote scripts/Configure.  For three years, I have
> >>  lived in fear that Microsoft would notice this fact and use it to attack
> >>  Linux through public relations channels or legal means.  They haven't 
> >>  yet, so I have been wrong so far.
> > 
> > Teehee.  I don't think you have anything to worry about, Microsoft would 
> > be incredibly embarassed to admit they're contributing to 'problem number 
> > 1'.
> 
> I agree, but we know some strange 'behaviour' of MS.
> They have a lot of lawers, they can make us a lot of trouble.
> (You will notice that there are no copyright statment on that file,
> only the name of authors).
> 
> Remember the RMS (a flame with the word 'ESR' MUST have also the 'RMS' :-))
> way to include 'free' patches: sign and send to FSF a piece of paper,
> that the patches CAN be included.

Under the GPL Having exclusive copyright just means that you can relicense 
later stuff if you want.  I'm not clear on why FSF considers it so important
but for Linux it just means that nobody, not even Linus, can ever release
under a new license (e.g., the BSD license).  So actually, having multiple 
copyright holders is a good thing for you, it protects your investment in GPL 
capital better.  I say, if Microsoft employees want to contribute to Linux, 
the more the merrier.  Heck, even billg is going to wake up on day (with a 
start, in the middle of the night) and realize which way the wind is blowing. 
Steve Jobs did.

> I think nobody in Linux have done that,

Great.

> thus we can expect some more troubles and microsoft is a large 
> troubles-maker

Oh yes...

-- 
Daniel

Re: [kbuild-devel] Re: Disgusted with kbuild developers

[Martijn van Oosterhout]

On Tue, Feb 19, 2002 at 10:15:16AM +0100, Daniel Phillips wrote:
> Under the GPL Having exclusive copyright just means that you can relicense 
> later stuff if you want.  I'm not clear on why FSF considers it so important
> but for Linux it just means that nobody, not even Linus, can ever release
> under a new license (e.g., the BSD license).  So actually, having multiple 
> copyright holders is a good thing for you, it protects your investment in GPL 
> capital better.  I say, if Microsoft employees want to contribute to Linux, 
> the more the merrier.  Heck, even billg is going to wake up on day (with a 
> start, in the middle of the night) and realize which way the wind is blowing. 
> Steve Jobs did.

OTOH, having exclusive copyright means you can more successfully defend that
copyright. If someone took a copy of the linux kernel and used it in a
blatently non-GPL compliant way, who could sue?

>From the FSF website:  If there are multiple authors of a copyrighted work,
successful enforcement depends on having the cooperation of all authors.

All the authors of the linux kernel? That would be more difficult than
herding Debian developers.

Since I don't think anyone has registered the copyright for the kernel
no-one would be eligable for statutory damages and actual damages is zero.
The Samba Team ran into exactly this problem. The Linux kernel lucky because
public opinion is in its favour.

Not that I think the FSF's way is necessarily the right way, but it is not
without merit.
-- 
Martijn van Oosterhout <kleptog@svana.org>
http://svana.org/kleptog/
> Terrorists can only take my life. Only my government can take my freedom.

Re: [kbuild-devel] Re: Disgusted with kbuild developers

[Alan Cox]

> OTOH, having exclusive copyright means you can more successfully defend that
> copyright. If someone took a copy of the linux kernel and used it in a
> blatently non-GPL compliant way, who could sue?

At least one opinion is that everyone whose code is used would be entitled
to sue the offender if they shipped a full GPL kernel. Think "class action"
When people start linking with fragments of the kernel and the like it
gets much more complicated, and depends upon whom.

On the bright side nowdays people you may have on the copyright
enforcing side of a kernel dispute include IBM, HP, Compaq, AMI, LSI,
Cirrus Logic, AMD, Intel, .... none of whom I suspect would ever have
signed copyrights over to the FSF.

> Since I don't think anyone has registered the copyright for the kernel
> no-one would be eligable for statutory damages and actual damages is zero.

This is not neccessary in most civilised countries, and in fact the current
US policy seems very suspect when compared to current WIPO treaties. Things
like the DMCA also changed the rules a little. 

Alan

Re: Disgusted with kbuild developers

[Bill Davidsen]

On Tue, 19 Feb 2002, Daniel Phillips wrote:

> On February 19, 2002 09:04 am, Giacomo Catenazzi wrote:

> Under the GPL Having exclusive copyright just means that you can relicense 
> later stuff if you want.  I'm not clear on why FSF considers it so important
> but for Linux it just means that nobody, not even Linus, can ever release
> under a new license (e.g., the BSD license).  So actually, having multiple 
> copyright holders is a good thing for you, it protects your investment in GPL 
> capital better.  I say, if Microsoft employees want to contribute to Linux, 
> the more the merrier.  Heck, even billg is going to wake up on day (with a 
> start, in the middle of the night) and realize which way the wind is blowing. 
> Steve Jobs did.

So did IBM, SCO, HP and Sun. We shall see what transpires...

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Disgusted with kbuild developers

[Pavel Machek]

Hi!

> >>. A Microsoft engineer wrote scripts/Configure.  For three years, I have
> >> lived in fear that Microsoft would notice this fact and use it to attack
> >> Linux through public relations channels or legal means.  They haven't 
> >> yet,
> >> so I have been wrong so far.
> >>
> >
> >Teehee.  I don't think you have anything to worry about, Microsoft would be
> >incredibly embarassed to admit they're contributing to 'problem number 1'.
> 
> 
> I agree, but we know some strange 'behaviour' of MS.
> They have a lot of lawers, they can make us a lot of trouble.
> (You will notice that there are no copyright statment on that file,
> only the name of authors).
> 
> Remember the RMS (a flame with the word 'ESR' MUST have also the 'RMS' :-))
> way to include 'free' patches: sign and send to FSF a piece of paper,
> that the patches CAN be included.
> I think nobody in Linux have done that, thus we can expect some
> more troubles and microsoft is a large troubles-maker

FSF is actually doing something completely different, they want to be
able to change copyrights.
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: [kbuild-devel] Re: Disgusted with kbuild developers

[Michael Elizabeth Chastain]

Jeff Garzik replies to me:
mec> I believe that CML1 is rococo and I welcome a replacement.  I think that
mec> leapfrog development is a good strategy here, just as it was for ALSA.
jg> I think this is a key mistake.  See Al's message "Of Bundling, Dao,
jg> ...".

I am reading lkml from an archive and I saw only the Friday night messages.
I have caught up now.

I agree with Al's strategy in "Of Bundling, Dao, and Cowardice".

Let me talk about the list-based makefiles.  Long before I submitted the
first list-based makefile to the kernel tree (drivers/sound/makefile),
I had a whole rewrite of every makefile.  These were the "Dancing Makefiles"
and several ideas came out of them: CONFIG_SMP and list-based makefiles
in particular.

I never thought I'd be able to get the Dancing Makefiles adopted.  I spent
a whole year just getting CONFIG_SMP merged!  So I came to view it as
a useful laboratory project to show what kinds of things were viable or not.

Then 2.1.XX developed a real problem with drivers/sound/Makefile.  The
"if-statement" based approach was not working.  The "if-statements"
changed on every patch level and new bugs came in for every patch level.

I said to myself "aha, list-based makefiles will solve this problem".
I wrote a new drivers/sound/Makefile.  Here is the important point:
I did not touch Rules.make *at all*.  I put some translation lines
into drivers/sound/Makefile so that it would just work.

Between 2.2 and 2.4, several people -- including Jeff Garzik -- converted
a lot more makefiles incremenetally to the new style.  This process got
about 80% done incrementally.

Eventually one of the old-style Makefiles developed a similar problem
with new tweaks in every patch level leading to a new batch of bug
reports.  Linus said something like "to hell with this" and summarily
removed support for the old-style.

So ... I leapfrogged in my own work area, but I put out incremental
patches that solved problems that other people wanted solved.

It was also a very painful process for me.  My patches got black-holed
numerous times.

jg> It's impossible to prove that Eric's CML2 rulebase reflects a current
jg> CML1 rulebase, primarily for this reason.

That's an important property and I haven't given enough weight to it.  :-(

It would be nice if:

  The new tool reads both CML1 and CML2.
  Deploy the new tool.
  People could convert directories to CML2 one at a time.

jg> Those are meta-properties.

Indeed, all my criteria are meta-properties.

jg> CML2's syntax is not reflective of the direction of being able to plop
jg> down "driver.c" and "driver.conf" and having the config/make system
jg> magically notice it.

This "driver.conf" idea did not exist when CML2 was invented.

So it looks like there is a market opportunity here: a tool that
reads CML1 files and also reads some kind of new driver.conf files,
which can be written in a fresh new language.

jg> Would you support the replacement of in-kernel
jg> configure/Menuconfig/xconfig with in-kernel mconfig?

I believe that mconfig is best distributed as a semi-independent package,
distributed in the way that modutils is distributed today.  I think that's
better than in-kernel.  Between the choice of in-kernel
configure/menuconfig/xconfig and in-kernel mconfig, I would go for
in-kernel mconfig.

jg> If we want to migrate to a point where all kernel configuration is
jg> maintained solely outside the kernel, I actually support that.  But as a
jg> SEPARATE migration step.  I do not want to drop all config tools from
jg> the kernel and tell people "use mconfig" in the same breath.

My vision of the migration path was that mconfig would be distributed
separately and co-exist with configure/menuconfig/xconfig.  When the
market share of mconfig becomes high enough( (say, 80% to 90%),
then drop support for configure/menuconfig/xconfig.

Michael Elizabeth Chastain
<mailto:mec@shout.net>
"love without fear"