Samba Team Responds to Microsoft CIFS Spec License
Jeremy Allison - Samba Team writes: "The Samba Team has released a statement regarding the Microsoft CIFS specification license and its effect on Samba. Regards! Jeremy Allison" Reading this and the Microsoft CIFS Technical License raises a number of issues worth considering. The statement maintains that the specification details an old implementation of the SMB/CIFS protocol, one Microsoft itself has abandoned. One wonders if the only reason they release such docs are as props for a court case or something.
Regardless of whether what you suggest would or would not be legal, it isn't necessary. As the article points out, the document is obsolete and the methods it describes are not even in use by Microsoft anymore. Besides, they are inappropriate for a Posix/Unix implementation, so alternative methods have been in use for some time anyway.
I believe the poster you replied to asked his question with a jesting undertone, but you afforded him/her the courtesy of a serious reply, and so I'll do the same to you.
While it's unlikely that Microsoft has used any code from the Samba project, it's certain that they optimised their SMB/CIFS implementation in Windows 2000. And prior to that, it had been verified (and heavily marketed, if you remember) that SGI servers running Samba achieved better performance than Windows NT servers. Hence it is not impossible that this served to motivate Microsoft to improve their implementation, proving how the benefits of GPL'ed code fosters innovation and betterment.
However, the SMB protocol was not created by Microsoft. If any one entity, corporate or otherwise, is to be credited with the design of this protocol, it is IBM corporation. It IS true that Microsoft then developed the protocol further from its early LANMAN days, however.
I found the other news link for today on the Samba home page even more interesting. Could this be the motivation behind the strange licensing hijinx?
Not really. SMB was created by DEC for their Pathworks software and by IBM (see http://samba.anu.edu.au/cifs/docs/what-is-smb.html ).
Strike one more Microsoft innovation from the list.
Firstly MS RPC is not "on top of" DCE RPC. It is an implementation of DCE RPC. Secondly if you make an RPC call, it can go over a variety of transports -- one of the great things about DCE RPC. Most windows boxes from NT4.0 onwards are configured to use IP by default.
Some more errors:
- RAP is not a layer in the stack for most of what you describe, only for the actual RAP functions, such as NetShareEnum. Most operations (such as open/read/lock) don't use it at all.
- Named Pipes are not "on top of" transactions. Transactions are an option for Named Pipes.
- Named pipes aren't on top of SMB. They are one of the things you can open using SMB, i.e. a type of file in a special part of the filesystem. The analogy is with character or block fifos in unix.
I might as well say:If you reduced it all down to copper wires imagine how efficient it could be! All you'd need is different voltages! Just code your application to read directly from an ADC!
NO ID: BEING FREE MEANS NOT HAVING TO PROVE IT