Re: Again: list of advantages of the xGPL

Il ven, 2002-06-14 alle 15:05, [email protected] ha
scritto:
> Message: 5
> Date: Fri, 14 Jun 2002 05:32:11 -0400
> From: Roger Fujii <[email protected]>
> To: [email protected]
> Subject: 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?

  how many browser doesn't implement the CSS today? 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? and BTW the CSS
were introduced by the web consortium a long time ago.

  how much time has required the P&P to get supported by linux and *BSD
at least basically?

  well, less than the time required by those changes to become
mainstream. So it has not been E&E, just evolution.

  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?

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

  the hardware manufacturers have used for long time to just add the P&P
feature, without removing the old jumper-based configuration.

  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.

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

  and their modifications require time to be accepted as mainstream, so
you have all time you need, providing you have not to reverse-engeeneer
anything.

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

  You seems to forget that we were talking of E&E *GPL codebases, don't
you?

  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.

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

  a new version will come out at least in the same timeframe required to
make these changes used by too many people. It may required one or two
month, but it wouldn't required 2 or 3 years as now. They will be
usefull, not useless as they can be today.

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

  I'm speaking of the gap between the moment when the new
functionalities are widely used and the time when they are implemented
by the free software project.
  
> > > > 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.  

  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?

  have you read what you have wrote up to now?

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

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

  well if they had stolen code from the free software community, it
wouldn't have been so buggy. Just see what is happened with the network
code they had stolen from *BSD.

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

  bye,

/pietrobo (no reply will follow, I've had enough of this unconclusive
discussion)


-- 
Stud. Marco Pietrobono            | Murphy's Law: if something could
v. del Calice, 39 - 00178 ROMA    |     go wrong, it does.
Tel. +39.06.7186329  339.7410893  | Legge di Murphy: se qualcosa può
http://www.pietrobo.com           |    andar male, lo farà.
------------------------------------------------------------------------
A strange game.
The only winning move is
not to play.
What about a nice play of chess ?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Per informazioni si veda http://www.gnupg.org

iD8DBQA9CfeaJdpOg6vRQxoRAq5MAKCKdSH3vh4d/KkUJItGRkHsR77dXwCfbv96
kzcM60gYZU7o2b4WqNNLAzU=
=4v8X
-----END PGP SIGNATURE-----