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.

Comments

Samba/MS

[neksys]

As much as I like and support the Samba team, I think they're going to end up fighting a losing battle here - Microsoft won't give up its stranglehold on any facet of its operating system. And while in the old days, the would have just purchased the entire Samba project, now they have little choice but to try these sneaky strongarm tactics. After all these months/years of bashing the GPL and OSS in general, Microsoft can't just absorb and accept Samba - especially not in front of the courts.

A thought: How many snippets of Samba code do you think has found its way into, say, Windows 2000?

Re:Samba/MS

[TightByte]

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.

Re:Samba/MS

[kinkie]

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.

Re:Why...

[TightByte]

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.

Hmm -- Samba for win32?

[Selanit]

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

Hmm...

[Khaed]

Uh, so it's a non-issue?

That's kind of what I thought when I first heard about this.

"Microsoft...documented basically what Samba already knows...and doesn't want people to...use the documentation for GNU purposes...Ok...what about what they already have? Oh, not affected? Ok."

Looks to me like Microsoft just got these reactions: Loving fanboy support(all three of them), people who could care less(most people), people who went into an idiotic rage(a lot, but not a majority), and people who scratched there heads and asked, "So?"(more than the first, less than the other catagories.)

I mean, basically all they did was brass off some of the geek community and make themselves look, well, dumb. No one really cares about their documentation...do they?

Testing Waters

[Bouncings]

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.

Re:Testing Waters

[Da Schmiz]

What would happen, for example, if Windows were "licensed" to exclude its use in conjunction with certain free software -- such as -- oh say -- Wine.

Actually, the latest Wine builds are working better and better even without Microsoft libraries. A far more likely scenario -- and one with a more powerful impact -- would be if MS Office was licensed so that it could only be used with Windows... or if it could only authenticate using Passport, or something along those lines. In fact, I believe that the reason CodeWeavers Office does not yet support MS Office XP has to do with this kind of licensing issue.

Or worse, what if the Windows EULA was changed to explictly forbid running it in an emulated virtual machine? That would kill VirtualPC, VMware, and plex86 all with one fell swoop -- and drive a lot of users back to the Windows platform.

You've got a good point. Hopefully, if enough people become aware of the dangerous possibilities of this kind of faux-open documentation licensing, the antitrust people will be able to do something about it.

Re:Testing Waters

[glwtta]

the antitrust people will be able to do something about it

Yeah, they've got an excellent record so far.

Re:007

[leviramsey]

As James Bond said once, "How do you kill a few hours in Rio, if you don't samba?"

Network configuration

[totallygeek]

So, now we will have this list in the network neighborhood properties?

Microsoft Client for Microsoft Networks
Microsoft Client for Netware Networks
Samba Team Client for What Microsoft Should Use

Re:Network configuration

[VValdo]

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

Re:Interesting aspects

[yeOldeSkeptic]

When I upgrade to XP or 2002 or whatever, I'm going to want to make sure I'm still able to access the Samba shares. If I can't, I hate to say it, but I may be forced to switch my network storage box to some Windows variant.

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?

Performance comparisons

[Waffle Iron]

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?

For the sake of interoperability

[fireboy1919]

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

Re:For the sake of interoperability

[trenton]

Yeah. Let's just hope Microsoft doesn't destory Alderan before a "structural remedy" is delivered down their thermal exhaust port.

Re:Or...

[Selanit]

Blockquoth the responder:

. . . a drop in replacement for something that is proprietary to begin with and comes bundled with all windows version sounds kind of ridiculous, doesn't it. ;)

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.

Re:Interesting aspects

[Bronster]

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.

Mischief-making

[Observer]

So, it seems that MS spent a little small change cooking up some documentation that raised the possibility that Samba might infringe on some of MS's intellectual property. Samba Team was then obliged to spend (proportionally considerably more) time and resources analysing this suggestion so they can issue a plausible refutation. In the meantime, all the 'careful' line management types whose reason for existence is never to be seen to be responsible for a mistake will have taken the point that deploying Samba is 'risky', and will now have to be persuaded all over again that this particular risk is an acceptable one, and that in this case there was smoke without fire.

Neat work, MS.

Fear, Uncertainty, Doubt. You can't choose just two out of the three, they come co-mingled.

Re:Interesting aspects

[Technician]

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.

Re: Time for something new?

[KidSock]

I second this. I think it's high time some people get together and start to think about a network filesystem that addresses all the issues. I don't know much about NFSv3 but historically NFS has huge holes. And RPC is overrated I think. The API just doesn't change enough to warrant it. It's just overhead and an implementation barrier for other languages. How hard is it to serialize data structures for cripes sake. CIFS is actually good to know when considering a new protocol though. It's got a lot of different stuff in there. That's why it sucks but it's useful to how they tried something, saw it fail in some way so they abondonded it and stuck another layer of crap on top to hide the previous layer of crap. It's quite funny to think about the layers. You have:

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

Re: Time for something new?

[benhaha]

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:

• MIME on top of
• HTTP on top of
• TCP on top of
• IP on top of
• Ethernet on top of
• voltages on copper wires

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!