Re: Again: list of advantages of the xGPL

Sorry, too many inaccuracies to let this one go....

Marco Pietrobono <[email protected]> wrote:

> > > > > Embrace and Extends works by copying something and extending it with
> > > > > UNDISCLOSED functionality.
> > > > It is most EFFECTIVE when you don't disclose it, but it doesn't REQUIRE it.
> > > BS. And you know very well this is BS.
> > You don't think IE's adding of stylesheets to html as being an embrace and
> > extend tactic?  How about that god-awful Plug&Play(ray)?  How about adding new
> > DOCUMENTED classes to the java runtime?
> 
>  how many browser doesn't implement the CSS today?

So?  How many WPs don't attempt to read a word .doc file?

> how many doesn't implement it yesterday? or one year ago? two years ago? How much time
> has passed before the CSS became widely used on the web?

quite a while, given netscape4 certainly didn't do it 'correctly'.  Let's see, when 
did mozilla go final?  Oh, that's right - THIS YEAR.

> and BTW the CSS were introduced by the web consortium a long time ago.

yeah.  It was DOCUMENTED all this time, and look how long it look.  HTML was
embraced, then extended with a DOCUMENTED extension.  What's netscape's/
mozilla's market share before and after CSS?
 
> BTW, how much these new classes have been used? Microsoft has lost the
> right to use the Java trademark due to these changes, do you know?

yes, and they paid tens of millions of dollars in damages.  So?  I never
claimed all E&E tactics are always successful.

> > > E & E REQUIRES the UNDISCLOSURE. Otherwise, it is just new
> > > functionality, not an embrace and extends strategy.
> > If you cause other people's stuff to break, and it takes them time to fix this
> > (and *any* product that has *any* QA cycle will suffer a lag between the
> > time the feature was added and the release that contains it), it is an
> > E & E tactic.
>   the addition of CCS has not break anything and has not been done in
> one day. Same for the new java classes (they needs to be used, you
> know...).

Look, here is a simple example.  Let's say they came up with a FAT64 and used
linux's partition type for it.  It's documented and disclosed.  Do you think
it will have no effect?  
 
>   the hardware manufacturers have used for long time to just add the P&P
> feature, without removing the old jumper-based configuration.

I wasn't talking about the HW companies - they (for the most part) *have* to
be compliant.  It's the software co's that make OSes (like BeOS, Solaris, *BSD,
*linux,
qnx..) that have to deal with this.
 
>   All cases of other people's stuff breakage have always been related to
> UNDOCUMENTED and UNDISCLOSED changes. As fully demonstrated by the acts
> of the various <insert_here_whoever_you_want,_there_are_plenty_of_them>
> vs Microsoft causes.

How do you fit M$'s joliet FS into your view? 

> > > If you don't, there is only the reverse-engeenering way to reimplement
> > > them, and it is both slowly and costly.
> > Trying to implement from a specification isn't instantaneous either.
>   if they have been forced by the *GPL to release their code, it's a
> snap. You can reuse their code.

Are you saying that the GPL applies to M$ code that they have re-written
by "reverse-engineering" from the source?  If not, don't claim you can
reuse their code.
 
> You seems to forget that we were talking of E&E *GPL codebases, don't you?

No.  You are ignoring the point of making their own version of the GPL
codebases.  
 
>   and even if there is only a specification, there is an order of
> magnitude between the two approach in terms of the required time and
> resources: years vs. months, just see how much work has been required to
> reverse engeeneer the .doc format. And it still hasn't completed
> understood.

Linux had NFS V2 specs forever.  I *know* it wasn't working correctly until a couple
of years ago (took 6 months for them to accept the bug, not even certain they
accepted
the patch I included with it).  The quickness of when things get done is
proportionate
to the amount of importance it has to the developers and the amount of resources they
have.  Saying that any changes will 'instantly' (or even shortly) be incorporated
is just wishful thinking.  
 
> [snip]
> > >   If the .doc specifications are opened and released with newly released
> > > Office versions, there will be no gap between Office and its
> > > competitors.
> > You must have a really funny definition of "no gap".  I'm glad code will
> > instantly appear and a new version will instantly happen upon
> > disclosure.
> 
>   I think I've described enough why the gap you see is way lesser than
> you think.

Are you a programmer?  "no gap" is like saying "gap == 0.0f"  "small gap"
would mean "gap >=0.0f && gap < SMALL_GAP_VALUE".  Stop saying "no gap"
then there *is* a gap.

> > >   no. we were talking about the embrace and extends of free code. They
> > > cannot embrace and extends the free code if it is under a GPL license.
> > > They need to rewrite all from scratch.
> > what part of what I wrote don't you understand?  The don't have to start
> > from square one - they can refer to the source.  They just can't compile
> > the source directly.
>   ok, so if it is a free software project that needs to read an official
> code it can require ages to be rewritten to implement the same
> funcionality, while if it is Microsoft it requires almost no time. Are
> you really saying so?

where are you getting that from?  GPLed projects don't have to rewrite the code.
Obviously, M$ does if it wants to E&E.  I am saying that given M$ has the code
to look at, it's a lot easier to "reverse-engineer".

>   have you read what you have wrote up to now?

apparently more than you have.
 
> > >   well, then make them do it,
> >
> > So, now you are saying that "cannot embrace" really means "well, they
> > can, but make them do it".
> 
>   I'm saying that nothing is granted for sure in this world. So they can
> even try to E&E something that requires so much time and resources,

it isn't nearly as expensive as you imply.  A slight example of this
would be the MIT PGP code - it had to be optically scanned in to circumvent US
export restrictions at the time.  Granted there's more work than simple scanning
to transcribe code, but I think a company with $40B in the bank can afford to do this
-
how many people do you need to code pseudocode?

> but I can't understand why it should be made more easy for them (or every
> other, there isn't only Microsoft in this world, even if the original
> example was the kerberos hijacking) to do so.

I never said anything about making it easier.  I said they *CAN*.  You were
trying to argue that they *CAN'T* with GPL.  It's absolutely true it is 
*more* difficult, but it is fallacy that it would be extraordinarily difficult
for them to do so.

>   How much of their modification to that code has been contributed back
> to the *BSD projects?

As if the *BSD would want 9xified source?  Besides, why does it matter given
the current topic?  

-r