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.
Is Samba available for Win32 platforms?
I know this sounds like a strange question, but consider: Microsoft's SMB-based file sharing system is buggy and insecure. Could Samba be used as a drop-in replacement for regular Windows file sharing?
E.G.: you don't like Windows file sharing. So, you turn it off and install Samba instead. It works the same -- you wind up with shared folders that appear on the network -- but the sharing is being handled by Samba instead of the vanilla Win32 file sharing.
Is that possible? Maybe I'm suffering from hallucinations induced by too much Mountain Dew . . .
Although this particularly license has no real implications, and I think we can be sure Microsoft is aware of this, perhaps their is a more sinister goal here: testing the waters of anti-GPL and/or anti-free-software licenses.
What would happen, for example, if Windows were "licensed" to exclude its use in conjunction with certain free software -- such as -- oh say -- Wine. Wine works better with Windows binary libraries accessible, and Microsoft might be thinking about some kind of anti-free-software clause in the Windows license.
I suspect this obsolete Samba license is just a beta test of their newest scam.
-- Ken Kinder ken@_nospam_kenkinder.com http://kenkinder.com/
I have a crazy idea. Since Samba is probably used by many Microsoft-oriented shops too, why can't the Samba Team embrace and extend the CIFS protocol? This would be a two pronged attack. One of the prongs would be the Samba Team which will extend the CIFS protocol and publish it under the GPL. The other prong will be a group that will write win32 applications that will take advantage of the Samba extensions to the CIFS and distribute the app for free. Since the OSS community numbers in the thousands at least, this would be very straightforward to accomplish.
I wonder what Microsoft will do if the Samba extensions to the CIFS become a de-facto standard? When is the next iteration of Windows anyway? Right now could be a window of opportunity just opening up.
Sigh, I know I'm day dreaming. But, wouldn't it be nice to give MS a dose of its own medicine?
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?
...SMB will have to go away.
Micro$haft is the main company working on Windows networking protocols, and as has always been the case they don't seem to encourage standards or interoperability.
I'm thinking a better solution would be to use OpenAFS. It works on Windows and Linux just fine, and its not going to have interoperability problems because all of the stuff is open source.
I believe its only a short time, maybe a year or four, before M$ doesn't have anything to do with network interoperability software, unless they change their policy.
A saying comes to mind:
"The more you tighten your grip, the more star systems will slip through your fingers."
Mod me down and I will become more powerful than you can possibly imagine!
Blockquoth the responder:
Heh.
Tell that to the Mozilla team, or anybody who's worked on a win32 web browser in the last few years. Internet Explorer is proprietary, comes bundled with all windows versions . . . and it's got a big, red bulls-eye in the middle that all the other browsers are aiming for.
Thanks for the info on the Cygwin Samba client. I actually did do a couple of Google searches before posting, but evidently I didn't pick the magic words.
I have a crazy idea. Since Samba is probably used by many Microsoft-oriented shops too, why can't the Samba Team embrace and extend the CIFS protocol? This would be a two pronged attack. One of the prongs would be the Samba Team which will extend the CIFS protocol and publish it under the GPL. The other prong will be a group that will write win32 applications that will take advantage of the Samba extensions to the CIFS and distribute the app for free. Since the OSS community numbers in the thousands at least, this would be very straightforward to accomplish.
This would work so long as there was a compelling advantage (i.e. - lots faster file transfers). There's no point adding extensions just for the hell of it - they have to do something that users want done. Personally I'd like to see SSL support built into SMB, and adding that to the Samba implementation with a seamless Win32 client would be enough for me to switch all the Windows boxen I use to the Samba implementation.
Neat work, MS.
Fear, Uncertainty, Doubt. You can't choose just two out of the three, they come co-mingled.
No, cuz when you try to install Samba, you'll now get an error that says:
"We're sorry, the Network Neighborhood is a Gated community."
W
-------------------
This is my SIG. There are many like it, but this one is mine.
If I can't, I hate to say it, but I may be forced to switch my network storage box to some Windows variant.
Wrong answer. I am not obsoleting my entire system because a user adds a new incompatible box. I insist the new stuff is compatible with my LAN. I have the incompatible new box user find and install the drivers needed to access the system. If it can't do SMB and TCP/IP, it's incompatible.
The truth shall set you free!
- MS/RPC on top of
- DCE/RPC and
- Remote Access Protocol (RAP) over
- Named Pipes on top of
- Transactions on top of
- Server Message Block (SMB) on top of
- NetBIOS
If you do an RPC call it goes through all of that (minus RAP which is quite dead post NT). A redesign would be trivial to implement by comparison because you could reduce all of that crap to one uniform API.