[Fsfe-se] EU-rättegången

[Jon Kristensen]

När och hur kommer rättegången att fortsätta?
Hur tror ni att det kommer gå?

/Jon

tis 2004-10-05 klockan 21.11 skrev Jonas Oberg:
> Tänkte att det kanske finns intresse här att läsa det inlägget i
> debatten som FSF Europe och därigenom Jeremy Allison (Samba) gjorde
> förra veckan i rättegången mot Microsoft;
> 
> 
>    INTERVENTION to the Court of the European Union on behalf of the
>    Free Software Foundation Europe, Thursday Sept 30th. 2004
> 
> 
>  Introduction by Carlo Piana:
>  ----------------------------
> 
> Mylord,
> 
> My name is Carlo Piana, I appear on behalf of the Free Software
> Foundation Europe. The Free Software Foundations have a 20 year
> history of starting, developing and furthering the GNU and after the
> GNU/Linux system, often referred to as "Linux". FSFs are in particular
> the single largest fiduciary of the interests of the thousands of
> authors of that system, especially their legal interests through
> defense of their Copyright and Licenses (precisely the GNU GPL and
> LGPL, published by the FSF).
> 
> One of these groups of authors is the Samba Team. May I therefore
> introduce Mr. Jeremy Allison of the Samba Team whose first hand
> experience will represent and show further how the factual assumption
> on Microsofts part are flawed and overstating the consequences of the
> remedies.
> 
> 
>  Intervention by Jeremy Allison:
>  -------------------------------
> 
> Mr. President,
> 
> My name is Jeremy Allison, and I'm speaking on behalf of the FSFE who
> is representing the Samba Team, who have a great interest in this
> case. Samba is one of the few competing products to Microsoft in the
> Workgroup server market. It is commonly shipped with Linux, but is
> developed separately. I am one of the original authors of the Samba
> code, and with my colleague from Germany Volker Lendecke have been
> working on interoperating with Microsoft software for over 12 years.
> I speak from many years of experience of implementing Workgroup server
> software.
> 
> In the development of Samba Microsoft has already disclosed to us
> specifications similar to those that we are now requesting. Microsoft
> has given to the Samba Team in the past internal documents describing
> exactly the level of protocol information we now need. These documents
> are now no longer useful, as Microsoft creates modified versions of
> its protocols on a regular basis, as it releases new versions of its
> Windows software. The documents given to us were marked internal we
> used them to create Samba code, as Microsoft intended when they gave
> them to us. They gave us these documents knowing we would create code
> with them, and they encouraged this. We were not required to sign
> non-disclosure agreements to obtain this information, we were simply
> treated as a trusted third party, as I believe we have been. We have
> never disclosed their contents publicly, only the code we created.
> 
> What we are requesting via these remedies is that Microsoft return to
> the policy of openness and co-operation with others that they followed
> in the past. The claims that we have not requested information on the
> protocols is not true. We have made repeated requests to Microsoft
> that they continue the kind of disclosures they made before they came
> to dominate this market.
> 
> A protocol, like a language, is a convention for communication. We
> need to know if the noun comes before the verb. We can learn ourselves
> by listening to others speak, this is what we do now to teach
> ourselves how to talk with Microsoft software. But such a self-taught
> student will always be behind someone properly taught by a native
> speaker well versed in grammar.
> 
> Microsoft claims that to disclose interoperability information would
> cause them irreparable harm. However, we believe the information that
> they are being asked to disclose is not of the immense value they
> claim.
> 
> The protocols Microsoft uses to prevent interoperability are mostly
> based on open and standard protocol specifications. Microsoft have
> added undisclosed extensions and additions to standard protocols that
> create dependencies between their clients and servers. For a
> non-Microsoft server to provide services to Microsoft clients these
> interdependencies must be understood by the programmers
> involved. Microsoft uses this lack of knowledge in third party servers
> for competitive advantage ("tying together" of clients and servers).
> Microsoft is building on the standards work of others, and adding
> small but critical changes for the pure purpose of making Windows
> clients depend on the presence of Microsoft servers, and Microsoft
> servers depend upon Microsoft directory servers.
> 
> A good analogy would be with the telephone network. The Microsoft
> documentation for the phone network would tell you how voice is
> transferred over the lines, but would neglect to tell you how to dial
> a number. As you can imagine this would cause difficulty for other
> phone manufacturers. Microsoft is trying to claim that the particular
> tones that they have chosen to use to dial 1-2-3 are a multi-million
> dollar investment.
> 
> The protocols Microsoft wants to keep secret to prevent
> interoperability are *not* of high intrinsic value. These protocols
> are not kept secret by Microsoft because they are valuable, they are
> valuable to Microsoft because they are kept secret, and thus prevent
> competition.
> 
> Whilst we are proud of Samba, it is not yet up to the level of
> interoperability of a Windows Workgroup server of 1996 (NT4). This is
> due to the lack of timely information from Microsoft on how their
> products talk to each other. Without this it is impossible to fairly
> compete on the merits of our products, as we are always without the
> basic levels of interoperability that Windows servers can provide. We
> are always scrambling to try and catch up to work out how the latest
> version of Windows has modified the protocols we implement.
> 
> We are not able to achieve interoperability by the existing methods we
> use, sophisticated though they are and there are no others available
> to us. We are 8 years behind and will only fall further behind if
> these remedies are delayed. It is trivial for Microsoft to change a
> detail in the protocol in a service pack or new release, and we need
> to first write our own protocol spec. before we can even begin to
> implement that change.
> 
> We do not wish to copy the Windows Operating System or to see any of
> the code that implements it. We wish to be able to expose our own
> merits, which we believe are considerable, not to reproduce the
> features of the Windows Operating Systems. Such a task does not
> require Microsoft to provide details of Windows internals, only
> network protocols.  We wish to have the opportunity to provide file,
> print and authentication services with the same amount of network
> protocol information that is available to Microsoft engineers.
> 
> 
> 
> _______________________________________________
> Fsfe-se mailing list
> Fsfe-se at fsfeurope.org
> https://mail.fsfeurope.org/mailman/listinfo/fsfe-se
> 
>