Re: wine-license digest, Vol 1 #148 - 8 msgs

Il gio, 2002-06-13 alle 13:26, [email protected] ha
scritto:
> Message: 6
> Date: Thu, 13 Jun 2002 06:13:25 -0400
> From: Roger Fujii <[email protected]>
> To: [email protected]
> Subject: Re: Again: list of advantages of the xGPL
> 
> Marco Pietrobono <[email protected]> wrote:
> > > So the embrace and extend tactic is harder with GPL code than with
> > > BSD code, but not impossible.  But given that Microsoft has
> > > repeatedly used this tactic against other commercial developers,
> > > it doesn't seem that the GPL would be much of a deterrent.
> 
> > I don't agree.
> > 
> >   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.

  E & E REQUIRES the UNDISCLOSURE. Otherwise, it is just new
functionality, not an embrace and extends strategy.

  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.

  If you don't, there is only the reverse-engeenering way to reimplement
them, and it is both slowly and costly.

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

  If the .doc specifications are opened and released with newly released
Office versions, there will be no gap between Office and its
competitors.

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

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

  bye,

/pietrobo who will not reply anymore. There is no reason or gain to
speak to someone who don't listen, or worst, who listen only to what he
likes.

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

iD8DBQA9CJ13JdpOg6vRQxoRAtl1AJ9rcr7VRpnGqMD8UhSDw394P0lwPgCghubE
ZchfEhHG1R/tDeLFb56cVXI=
=Dw/d
-----END PGP SIGNATURE-----