Re: Again: list of advantages of the xGPL

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?
 
> 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.  

> if you document the new functionality, either by the code or by
> written documentations, every one can copy your changes and reimplement
> it in almost no time.

So?  It still takes time to get it out the door.  In the java case, doing so
isn't even allowed.  

> 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.
 
> > Look at word's .doc format.  Many people just got tired of M$ constantly
> > changing .doc format and have their wordprocessor (wordperfect, insert
> > other WPs here) break until the next version where it could read the .doc
> > files again.  Even *IF* M$ disclosed the format, it still wouldn't eliminate
> > (it would shorten) this breaking lag.
> 
> it would eliminate the breaking lag if the disclosure is contemporary
> to the release of the code. 

since when is disclosure synonymous with release of source code?  When I see
the HTML spec, am I reading C source?  Besides, you think a new version will
be instantaneously come out?

> You can close you eyes and try to tell the white as black as many times
> as you want, but this will not change the white to black.

I'm not the one in denial here.
 
>   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.  
 
> > > If they try this with a GPL codebase they need to release their code
> > > to their users, and this means that all their extensions are fully
> > > disclosed and therefore they can be added to the original codebase too.
> > You *missed* the entire point.  If the codebase of GPLed, what M$ would do
> > is "reverse engineer" the code (have one programmer describe the code to
> > another) and recreate the new source.  This code is NOT have GPL on it, so
> > they don't have to release the code and can do with that as they wish.
> > Sure, this is more effort on their part, but it's certainly something they
> > could do.

>   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.  

>   well, then make them do it, 

So, now you are saying that "cannot embrace" really means "well, they can, but
make them do it".  

> so we can see if it is worth the time it requires, with all the work it
> requires. And the new version will be surely more bugged and more unstable
> than the original one, that has been used for far more time.

It certainly isn't more buggy than anything else they do.  :)  

-r