Slashdot Mirror
Microsoft Agrees to Release Work Group Protocols
UnknowingFool writes "Groklaw is reporting that the Protocol Freedom Information Foundation (PFIF) has signed an agreement with Microsoft to release their protocols relating to Windows Work Group Server. The Foundation agrees to pay MS $10,000, and the agreement does not cover patents. This agreement apparently was made to somewhat satisfy the EU Commission complaints. With PFIF's objective to aid open source, this agreement means that the Samba Team may finally get the information they need to fully interoperate with Windows AD servers."
that EU did something the US government couldn't.
Are you sure about that? Workgroup is often designated as software separate from their Enterprise or Domain integrated stuff. Are you sure that releasing their workgroup protocols includes Active Directory access?
"I use a Mac because I'm just better than you are."
Telling someone the punchline of a joke after they beat you to it.
It is pitch black. You are likely to be eaten by a grue.
Good news for Samba. Still listening to that audio link, but it's interesting that the Samba team aren't allowed to release the information they receive, just use it for developing OSS.
I'm sure Microsoft will use this in their 'we support open source' campaign. (I've always reckoned Microsoft should release the code for their unsupported OS's such as Windows 3.11)
Doesn't cross license patent's, but Microsoft does have to provide a full list the patents that they believe Samba infringes. This allows Samba guys to code around it. Good news for them.
I am somewhat dubious, but this /could/ mean that I may finally be able to convince my workplace to adopt more linux workstations. I for one will work on samba if the allusions made by the summary are true. I say this because, all other issues aside, Windows interoperability really is an issue where I work.
Correct me if I'm wrong but, reverse engineering for compatibility purposes is legal. IIRC, that's why OOo is able to handle .doc.
Active Directory certainly is limited in Samba. Now imagine Samba sufficiently AD-esque that it could be used as a DC for an Exchange 2003 member server.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Taking a quick look at the agreement, it looks like PFIF can't release the documentation to the public. So, as a user of Samba, if I find a bug in Samba's handling of the protocols, how do I fix it? If I have to rely on the "Samba Team" to fix the problem, this isn't much better than source-available proprietary software---I'm still tied to a single vendor.
Let's be serious, they're still confidential, proprietary protocols, aren't they? Way to go, Microsoft.
http://outcampaign.org/
If the licensed documentation is under non-disclosure terms, but the source code is still freely distributable....
what's the point to the documentation not being disclosable?
Talk about pointless legalese...
Welcome to the Panopticon. Used to be a prison, now it's your home.
Am I going to be able to run a Linux based Domain Controller? Is my Samba box going to be able to publish Active Directory compatible ACLs for the shares it hosts? Is nmap now going to tell me that Samba boxes are Win2K3 servers?!?! ;)
Merry Xmas, happy new years etc.
Lurking at the bottom of the gravity well, getting old
Right, but according to Jeremy Allison on the podcast he hasn't seen them with his own eyes yet, so I think the may was reasonable.
Joe Llywelyn Griffith Blakesley
[This post is in the public domain (copyright-free) unless otherwise stated]
THis is only worth anything so long as MS does not "innovate" and "extend" the protocol and break compatability.
Engineering is the art of compromise.
Totally legal in the United States. In other jurisdictions, the law is not so clear-cut. In Europe, the right to reverse engineer is not sacrosanct. Then again, Europe doesn't (yet) have software patents.
Standard IANAL disclaimers apply, of course, but I've worked for several companies that relied on reverse engineering precisely for the purpose of compatibility with undocumented file formats. In one such company, I was informed by management (after advice from legal counsel) that it was actually legal not only to reverse engineer the file format, but it was even legal to reverse engineer / decompile the code for the application that generated the files in order to see how they were written -- the caveat being, you could only reverse engineer the code to insure compatibility, not to plagiarize it. (Usually you do a clean room reverse engineering process to insure that the people who reverse engineer the code write a clean spec that the people who write your code then use. The people doing the reverse engineering shouldn't be writing code based on that process, to avoid even the appearance of impropriety.) Of course, that particular employer's policy was to not reverse engineer the code of the applications themselves, only the files they wrote, but if we had the resources and we needed to, we could reverse engineer just about anything we wanted.
The legal climate in the U.S. was shaped in part by the outcome of a case where IBM sued Compaq for reverse engineering the BIOS of the IBM PC. Clearly, Compaq prevailed, and the clone PC market was born.
Dell's been shipping Linux for a while. They just moved on to 7.10 when they had been shipping 7.04. No bigger news than when OEMs started selling Vista instead of XP. It was inevitable.
It's actually 10,000 Euro. That's a $14,333.65 windfall for the Redmond current account!
It's not so much a price as its worth to Microsoft as much as it is a fee to keep the protocol out of the hands of the average Joe. It's a move mostly aimed at open source I'd imagine.
Linux 7.10 ? Wow!!!!
Idiot
Now can we do the same thing for the Outlook/Exchange protocol?
thegodmovie.com - watch it
You know what I meant. Would you prefer that I had said they had moved on to Ubuntu 7.10?
Put identity in the browser.
This makes a mixed environment more accessible and I imagine with Microsoft seeing that they are having to deal with many solutions not of their own that they'd treat this as a playing nice in the sandbox. Customers are tolerant but if they can find a compelling solution that saves them money I think Microsoft is wise to put this in so as to stem such customer defections.
Comment removed based on user account deletion
The shell company and the subcontracted developers (Samba etc) cannot release the documentation.
BUT, they can create a reference implementation with normal source code comments and release that without any limits. This will effectively document the protocols. The hoi polloi just can't read Microsoft's documentation directly.
And if the documentation is incorrect, there are recourses.
And if patents come into play, there are recourses.
And if the documentation gets out of date, there are recourses.
And if you read the docs you are only NDA for three months (patents, not so much, as ususal)
This actually looks really good. Fingers crossed the inevitable gotchas are small and can be lived with.
MB
I am a viral sig. Please copy me and help me spread. Thank you.
Just to say thank you for all your work.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
http://lynxcache.com/Groklaw_Samba_Team_Receives_Microsoft_Protocol_Documentation.html
As with the original EU descision, i am somewhat disappointed.
The WSPP protocols dont covery enough. And to be honest, things like smb/ad should be FORCED into an open standard when they're a dominant player in the market (and used as leverage for even more monopolism).
On top of that, it should have covered many more protocols, the exchange protocols for starters.
Really very disappointed in this descision and AT for going out making it sound like a win.
This is fine and good but I was under the impression the Samba team had reverse-engineered a lot of protocols to get where they are. Can they not do the same with Active Directory too? Is it a patent or legal issue or is it actually a technical hurdle?
Its pretty funny that Novell cant make their products work against AD. They have this agreement with Microsoft and it sure looks like pure vapour.
Samba seems the only way that Novell can make for example Open Enterprise work as an AD controller. This is in my mind pretty funny considering they are supposedly in an interoperability agreement with Microsoft.
What i think happened was that Novell was given a large wad of money to shut up and pretend that Microsoft is working togheter with others in the industry and to give credibility to the patent FUD.
HTTP/1.1 400
If there is a locking mechanism or some other encryption, however feeble, it will become illegal to reverse engineer, right? Or would that still be OK for compatibility purposes?
No apostrophe in Nazis. ;-)
Even then, doing so would be really, really stupid, as such a setup won't be supported by anyone :)
Using Samba as a fully-fledged fileserver would be a start, but currently doesn't support any of the advanced features like DFS-R.
Then again, using Windows as a fileserver works well, and isn't that expensive.
I've never really understood why i'd want to use a Linux server with Windows clients - it just doesn't work all that good, causes way more headaches than you save in terms of money.
It's like looking at the four horsemen of the apocolypse or something.
If Mr. Edison had thought smarter he wouldn't sweat as much. --Nikola Tesla
Great! Now maybe someone in OSS can figure out how to route Netbeui!
What!?
I bet the PostPath guys would...
Reverse engineering is legally protected within the E.U. courtesy of directive 92/250/EEC on the legal protection of computer programs. In the UK this is implemented in the Copyright (Computer Programs) Regulations 1992 (S.I. 1992 No.3233). Basically I get to reverse engineer any hardware/hardware, hardware/software or software/software interface.
Apart from EMCA bits to do with circumventing *effective* copyright protection, I am aware of nothing that overrides this directive.
I haven't had any problem working with windows domains in about a year.
Samba has been able to participate fully iin *NT style* domains for a very long time now--I have a Linux box acting as a PDC that runs a domain that authenticates against linux LDAP and takes care of roaming profiles (so my desktop settings, preferences, etc follow users between machines).
Samba also, for quite some time, has allowed Linux (and MacOS X and other UNIX-style systems) to PARTICIPATE in Active Directory domains as clients or "member servers"--that is, it can connect to and authenticate against a Windows 2003 Server domain controller. This development would've made such a feat possible much quicker than it actually took to happen, but the Samba team did manage this very notable feat.
What remains elusive today is the ability for Samba to act as the AD domain controller itself. Developers have been struggling to make this functional and reliable enough in the alpha releases of Samba v4.0 and have had some modest success, but it seems that progress has been quite slow to this point. You can set up Samba 4.0 today and get AD clients to participate in that domain, but major issues remain. I'm thrilled that MS has finally been goaded into disclosing vitally needed information for providing interoperability, and that although there is still a one-time licensing fee and a bullsh!t NDA required to get the specs the source code that results can remain GPL and free from stupid IP encumbrances. This means that not only should Samba 4 progress much faster now, but that if it's written well other parties can learn MSFT's bastardised standards through studying Samba's source without involving their own NDA crap.
Merry Christmas Samba team, love your new present!
I've never really understood why i'd want to use a Linux server with Windows clients - it just doesn't work all that good, causes way more headaches than you save in terms of money.
I use a Linux server with Windows clients and haven't found it to be all that burdensome--it certainly works just as well as NT or 2000 did as a non-AD PDC...and for a small outfit Windows Server licensing is a significant investment. Wherever Samba doesn't work well as a server you can almost exclusively blame it on the fact that MSFT kept the specs secret and Samba had to do its best to reverse-engineer them. With the specs now available to Samba developers their project should work much better as a server in the near future.
As for why you'd want to use Samba as an AD member server or domain controller, there is far more than licensing and maintenance costs to consider. Linux with Samba has much smaller resource requirements--you need not load in a GUI or extra cruft that MS has welded to Windows Server (you will not be able to do that with Windows Server until a future release). There are also more security, remote admin, etc. choices available for Linux that are free (and Free). Last but not least, there are more viruses, worms and trojans that compromise Windows appearing in the wild in a day than have existed for Linux in its entire history. Invulnerability to malware is a pretty valuable characteristic for a system that is as critical as a domain controller or major server.
That last reason has to be the most important reason to run a non-Microsoft AD server--a "diverse ecosystem" is important overall, but it is probably most important to have a diverse array of architectures in the server space, because that is where a malware outbreak can cause the worst disruption.
...a Microsoft press release announced the replacement for Windows Work Group Server, Windows Team-Up. Among its enhancements will be an all-new protocol which Microsoft claims will be more efficient and powerful than its predecessor.
Chris Mattern
Not really. The PFIF's sole purpose is to pay MS and then give access to that information to open-source developers.
It does keep it out of the hands of hobby or low-end commercial developers, but not open source ones.
Better to run a Samba situation if all you have are linux gurus. Better that than have people completely unfamiliar with windows try to setup a windows system securely and reliably. That tends to not work well.
Likewise, if you have access to folks with windows experience, and you're a primarily or all windows shop, then that works well.
In general, better to have a slightly weird configuration (samba servers, windows clients) if its managed and configured well by people who know what they're doing, than a normal configuration thats managed poorly.
I'm sorry, but your point doesn't make that much sense to me. If you have folks that are "completely unfamiliar" with Windows, i wouldn't want them to administrate Servers OR Clients. You'll get a security nightmare either way.
And how do you e.G. deploy Windows updates (WSUS), provide Office document versioning (Sharepoint), Groupware that is fully integrated with Microsoft Office (Exchange) or a fully integrated IM & VoIP Solution (Office Communication Server)?
Dude, if you've drank THAT much MSFT kool-aid then you're very VERY far off from considering Linux seriously for anything! In any case, with the specs provided to the Samba team, they could produce file and printer sharing servers and AD domain controllers that fully participate in that infrastructure. BTW, Typically you wouldn't put WSUS, sharepoint, Exhange and Communication Server on a Windows Server configured as a domain controller (in fact I don't think MSFT will even take your support call in that kind of setup). you COULD however, eventually use modestly-specced Linux machines with Samba 4 as your AD servers and have ALL of the above as member servers on the Samba domain. Furthermore, third parties can now develop their own competing or complementary systems and be "full citizens" of the Network Neighbourhood.
As far as everything you mentioned here, there are non-MSFT (and sometime Free/open source) alternates to ABSOLUTELY ALL of the services you mention with the exception of WSUS. For example there is a brand-new add-on for the GPLed Citadel groupware system that makes it a full replacement for MS Exchange. Subversion can be used for document revision control. There are solutions based upon Asterisk that do what Office communication server can do. Citadel can be set up in a fraction of the time it takes to set up Exchange, and you can buy asterisk "appliances" that plug-and-play for much cheaper than the MSFT solution.
No, it isn't. Microsoft's Small Business Server offering is dirt cheap - nothing compared to the manhours required to setup a Windows OR Linux solution.
"Dirt cheap" is a relative term. Free is definitely cheaper than $600, and if you have more than 5 user you have to spend $500 more, and the mandatory licensing costs go up incrementally from there, whereas Samba remains free. For a non-profit org office or struggling small business with 6 to 20 users the difference is enough to be of concern. Furthermore you can set up a domain controller in a few hours using either solution, so unless you value your time in the multiple-hundreds of dollars hourly then licensing costs are indeed significant.
Reusing old desktops isn't what i'd want in a corporate IT environment.
Nor what I'd like, but it can and does happen...it is in fact common practice to use old hardware in many corporate environments (sadly, far beyond what makes economic sense in too many cases).
But you can run a WS2003 DC on pretty much anything with a hard disk and 256MB memory.
It's pretty sad nowadays that people brag about needing "only" 256MB as somehow being efficient. Samba would perform equally well with 128MB of RAM. Conversely more current hardware could handle more users under a properly-tuned Samba server than using Windows Server 2003.
Most of the vulnerabilities that exist for Windows do not affect Windows servers
A significant portion of vulnerabilities do nonetheless. Unfortunately, some of the most aggressive of the malware out there are the opposite--they are most destructive on servers and have little to no effect on a workstation or home machine. Code Red and Slammer come to mind (they affected server products like IIS and SQL Server that are not widely deployed or included with client machines). Windows Server is probable the most hazardous of all the Windows flavours in this regard: users on clients do stupid things and infect files which they save onto servers, where the most damaging delivery vectors are launched when the server is in turn infected.
I disagree. The more complexity a system has, the higher is the chance that a security vulnerability is introduced. Remember, security is not only dependent upon Software, but also upon Configurati
The products of the CodeRed & Slammer days are very different from those released and deployed now. You then also disagree with notable industry experts. A monocultural infrastructure might be "simple" and easy to configure, but it is impossible to make any system completely invulnerable, and when a vulnerability is exploited in a monocultural system it can completely wipe it out. Many experts in the field believe the risks of this universal vulnerability of a system to various exploits far outweigh the benefits of the simplicity in managing a single-platform solution. Notable industry experts are not very impressive.
This theory is one of those that sounds great on paper, and sells lots of books and conference keynotes, but doesnt really work in reality.
Even in large orgs with centrally managed everything, when there are outbreaks of things, its always unit by unit, some units within the org get hit, some dont. Happens over and over. One set of servers gets hit, the others dont.
It just doesnt work the way Greer describes in reality. Even in an homogenous system, there are sufficient differences between groups and departments to make it a moot point. Wouldn't you think, in an Active Directory situation, if you had a mix of Windows and Samba AD domain controllers handling your domains it would be more robust in an attack? It would dramatically reduce the chance that a single exploit could knock out all your domain controllers at once and essentially knock out your whole network. It wouldnt help you much at all. Unless you're using tokens, smart-cards, etc
Attacks these days arent about 'knocking out' machines. They're about getting stealthy ownership and using them for profit.
Well, you asked why people do it, and thats why. Whether it makes sense to you or not, even whether it is logical or not, thats the primary reason why people do it, that I've seen.
that is great news for developers