Slashdot Mirror
Microsoft Settlement Compliance Criticized
Jeremy Allison - Samba Team writes "A report on the Microsoft "release" of communication protocols, as required by the proposed settlement. Article from the Washington Post. Speaking for the Samba Team, we can't look at these documents as they require signing an NDA before even getting the terms of release. Jeremy Allison,
Samba Team."
Since when does the GPL prevent monetary costs for obtaining information used? Last time I checked, the GPL even allowed programs licensed under it to have a cost associated. Of course, once someone has obtained the program they must also have [access to] the source code and the other various rights protected by the GPL, but that's only once they obtain the program in the first place.
Luke-Jr
In fact, the GPL explicitly allows payment, as you can confirm for yourself by walking into an Borders and buying a copy of Redhat or Mandrake.
The GPL does not prohibit payment, it prohibits *prohibiting* giving it away for free. A subtle difference that appears to be beyond the Post's writer. Said writer should expect to find a *very* full inbox tommorow.
KFG
You can charge a distribution fee, but not a royalty.
To gain an understanding of these issues, you can read the GPL itself (compared to a EULA its quite easy to grok). If you need clarification, you can read the GPL FAQ.
~Phillip
This statement is flat wrong. There is nothing in the GPL which prohibits charging for GPL'ed software. The point of the GPL is that source must be made available for at-cost prices (postage, etc), and that source for any derivative product must be made similarly available. It only says that source must be made available at cost if the buyer asks for it. A lot of times, they don't ask. And a lot of times, they're willing to pay big $$ for a nice, installable binary distribution on CD. The GPL also says explicitly that "you may at your option offer warranty protection in exchange for a fee". This is exactly what Red Hat does.
In summary, GPL is hardly the same as 'gratis'. It is, OTOH, a good try for 'libre'. Someone please beat these media guys with a cluestick.
This post expresses my opinion, not that of my employer. And yes, IAAL.
You missed the point. The Court says that these protocols are not to remain trade secrets, as that perpetuates Microsoft's illegal monopoly.
You are wrong. The Court hasn't said anything about these protocols. They are merely part of the proposed settlement which the court has not ruled upon yet.
Mmmm.. Donuts
By making it the same for everyone naturally A flat fee of $1M is the same for everybody, but it is still discriminatory. Can you see how?
Microsoft does not pay income taxes, and has not paid income taxes for the last several years. They also pushed through the legislation that legalized some of the accounting practices of Enron and Worldcom.
This is not insightful at all. You say:
Well, first of all, Microsoft haven't been convicted of anything. They haven't been charged with any crime either, which is a necessary first step. It was a civil trial and they have been found liable for civil offences.
Secondly, the remedy is not supposed to be a punishment. Since punitive damages were not asked for, the judge is not permitted to impose a punitive remedy. She is required by law to impose a remedy that will fix the problem (by compensating victims and maybe preventing future abuse), if at all possible without punishing Microsoft.
Later you say:
Well, as noted above, they haven't been convicted have they?
Arguing for a more lenient remedy is the right of every losing defendant. Even if Microsoft was a convicted criminal, and the remedy was a punishment, it would still be their right to argue for a more lenient one. Even killers are allowed to appeal their sentences.
The opinions you expressed are objectively wrong about the material facts enumerated above. You are still entitled to express them, but you are still wrong, no matter how protected your speech is.
NO ID: BEING FREE MEANS NOT HAVING TO PROVE IT
You're close!
A protocol is the flow of data and an agreement on the type of data that will be transported within that flow.
An API is an interface allowing one entity to interact with another entity. Normally that interaction causes an action of some type to be taken.
Now then, it is certainly possible to have a known protocol with an unknown API. Knowing the protocol alone does little for you. Likewise, the inverse is also true. Knowing what the API is and how to use it does little good if you are unable to convey your intentions if you don't know what the protocol is.
I point that out as you seem to imply that knowing an API will be helpful while knowing the protocol may not. Fact is, BOTH are very important and this has nothing to do with "make[ing] 2 pieces of software running on the same machine work better together...". Fact is, it has everything to do with making software work better together regardless as to their location (same or different machine).
You further went on to comment, "the only reason Samba would need an API would be if they were trying to write software for Windows that tied into the OS somehow". That of course, if incorrect. If you look at my first statment you'll soon realize why. The API may be needed to allow SAMBA to remotely access windows services OR allow windows machines to remotely access SAMBA services.
Remember, the protocol is only the portion which transports data. The API or interface is what determines how that transported data will be used once it's delivered. They are distinct yet closely complimentary.
So, in summary, an API is often worthless if you don't have means to access it. Likewise, a protocol is often worthless if you don't know what and why it is you're supposed to be transporting in it. Here's an example. Imagine an API as a form that you have to fill out. If you don't use the form or incorrectly fill it out, the person that gets it will throw it away. That form is the API. Now, imagine an envelope. If you don't place the form into the envelope and then, correctly label, stamp and clearly enscribe on it, it will never get to the designated person. In short, you may as well not bother filling out the form (let alone correctly) if you don't know how to get it to the designated party.
We clear now? Surely you can now understand why they are BOTH very important.
This is correct (and those later posts that say the Appeals Court prohibbited break-up are wrong, the Court said that procedurally the break-up was not appropriate b/c of Jackson's ex parte comments and lack of hearings on remedies. In fact, the Court issued a later ruling spelling out quite clearly, in a two sentance order, that no remedy was off the table!)
However, the DoJ, chose on their own, to take break-up off the table. They took away their best bargaining chip for reasons people can feel free to speculate on. In their later seperate action, the hold-out States also chose not to pursue break-up and instead wanted full unbundlin, port of office and IE to rival browsers inc. Linux, and a crown jewell provision to open up source code for future violations.
The gist is this, Judge CKK is not going to impose a break-up that no one is asking for. It will probably be a remedy that is stronger than the DoJ sell-out but less stringent than the State's proposal. Expect MS to appeal again, expect this not to end soon, or expect the unexpected.
I point that out as you seem to imply that knowing an API will be helpful while knowing the protocol may not. Fact is, BOTH are very important and this has nothing to do with "make[ing] 2 pieces of software running on the same machine work better together...". Fact is, it has everything to do with making software work better together regardless as to their location (same or different machine).
It really depends on what you are doing, though. From my limited knowledge of Samba it would seem that they have no use for any Windows API in their software, since their software interacts with Windows at a protocol level, not an API level. Of course, if they needed an API rather than a protocol, they wouldn't be harping over this NDA, either.
You further went on to comment, "the only reason Samba would need an API would be if they were trying to write software for Windows that tied into the OS somehow". That of course, if incorrect. If you look at my first statment you'll soon realize why. The API may be needed to allow SAMBA to remotely access windows services OR allow windows machines to remotely access SAMBA services.
Remember, the protocol is only the portion which transports data. The API or interface is what determines how that transported data will be used once it's delivered. They are distinct yet closely complimentary.
but that API would only be applicable on the Windows side, as it's the way Windows handles the interaction between CIFS and the file system, authentication, and print services, for example. Since Samba doesn't run on Windows, the information required to do that would not be in a Windows API, because authentication and file and print services are handled differently on Linux. Now, if the protocol was sending data in a way that was not described in the protocol itself, you'd have a point.
So, in summary, an API is often worthless if you don't have means to access it. Likewise, a protocol is often worthless if you don't know what and why it is you're supposed to be transporting in it. Here's an example. Imagine an API as a form that you have to fill out. If you don't use the form or incorrectly fill it out, the person that gets it will throw it away. That form is the API. Now, imagine an envelope. If you don't place the form into the envelope and then, correctly label, stamp and clearly enscribe on it, it will never get to the designated person. In short, you may as well not bother filling out the form (let alone correctly) if you don't know how to get it to the designated party.
We clear now? Surely you can now understand why they are BOTH very important.
I agree that both are very important, but there are cases in which you clearly do not need the API to utilize the protocol, and vice versa. My point was primarily to make a distinction between APIs and protocols and to point out that if Samba was looking for an API, the API wouldn't be covered under this NDA. Since CIFS is on the list of protocols covered under the NDA and CIFS is one of the protocols used by Samba, it does make sense that they are looking for this particular information. Whether or not they need details on the API that Windows uses with CIFS would really depend on the level of detail in the CIFS specification in the first place. You certainly don't need the Windows networking API to communicate with Windows systems over IPv4, but it makes life easier if you're trying to communicate over IPv4 from a Windows system.
-PainKilleR-[CE]