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

Fully interoperate with the AD

[0racle]

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?

Re:Just another example

[Anonymous Coward]

Couldn't or wouldn't? When they were under pressure earlier this decade, Microsoft spent a lot of money lobbying/buying off US state and federal governments, creating fake "grass roots" campaign sites and paying for press releases from pro-corporate lobbyist groups such as the cato institute (source1 [sourcewatch.org] source2 [zdnet.com]).

Re:So, they can follow the law now?

[calebt3]

Correct me if I'm wrong but, reverse engineering for compatibility purposes is legal. IIRC, that's why OOo is able to handle .doc.

Re:Just another example

[Spy der Mann]

that EU did something the US government wouldn't.

There, fixed it for ya.

Re:Fully interoperate with the AD

[Jeremy Allison - Sam]

Yes it includes all AD protocols.

Jeremy.

Re:and you'll see this in a glossy brochure...

[calebt3]

I've always reckoned Microsoft should release the code for their unsupported OS's such as Windows 3.11

The OSs may be unsupported, but the code is still used.

Re:So where can I find the documentation?

[Jeremy Allison - Sam]

They way it will work is as follows. We'll read the docs and work on creating client-side test cases and embedding them into Samba4 smbtorture. Once that's in place, any competent engineer can create the server-side implementation without having to have access to the actual docs. We need the test cases anyway (remember, untested code is broken code), so this is the way we've been going about doing things anyway. This should just open up new protocols and new protocol areas to implementation by others.

Jeremy.

Re:So, they can follow the law now?

[LionMage]

Correct me if I'm wrong but, reverse engineering for compatibility purposes is legal.

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.

Re:What's this mean in the real world?

[UnknowingFool]

Samba has been developed without the actual documentation of the protocols. The team has done a remarkable job of reverse-engineering them as much as possible. The end result is that Samba is mostly compatible with Windows servers and clients. But there have been some missing pieces because the protocols haven't been open. For example Samba can operate in an Active Directory (AD) domain but cannot be used as a primary AD server. It could be used to make a Linux Primary Domain Controller though.

Re:What's this mean in the real world?

[ScytheBlade1]

Primary Domain Controllers died with NT4. As of server 2000, the concept of "primary" was removed and everything was made multi-master.

To that end, no, samba has not been able to *fully* function as a "domain controller" - as that is a separate technology from that of a "primary domain controller." They share some characteristics, but they are not the same thing.

Re:works just long enough

[civilizedINTENSITY]

"Section 3 is where Microsoft promises to provide the documentation that we need. It deals with the timeliness of that documentation, how errors in the documentation will be dealt with, how and when updates will be provided and what type of technical support will be provided."

WSPP Documentation - Updates.
3.2
(a) General. Microsoft will make updated WSPP Documentation for modified and new WSPP Protocols (that are added to WSPP after Microsoft initially provides WSPP Documentation to Licensee under Section 3.1) available for license by Licensee under this Agreement:
(i) if applicable, upon release of the First Beta for the relevant Service Pack to the relevant product, or new version of that product, that includes the modified or new WSPP Protocol (documentation provided in such instance, a "Preliminary Documentation Update"), or
(ii) if no such First Beta is released, then at least 15 days before the : (A) commercial release of the Service Pack to the relevant product (i.e., Windows Client Operating System or Windows Server Operating System), or new version of that product, that includes the modified or new WSPP Protocol, or
(B) the day on which the final version of any other Update is released. "First Beta" means the first public beta testing version of the Service Pack or new version of the relevant Windows operating system product made available by Microsoft via an MSDN (Microsoft Developers Network) subscription offering or of which 150,000 or more copies are distributed. Licensee will be given automatic access to the WSPP Documentation for any Licensed Protocol modifications made available under this Section 3.2, for no additional charge beyond the License Fee. Licensee will be given access to the WSPP Documentation for any other WSPP Protocol modifications or any new WSPP Protocols pursuant to the process described in Section 3.1(b)(ii), for no additional charge beyond the License Fee.
(b) Preliminary Documentation Updates. When a Preliminary Documentation Update is made available to Licensee, Microsoft will also make the WSPP Documentation for the commercially released version of the relevant Service Pack or new product version (such documentation, a "Final Documentation Update") available to Licensee within 15 days after the relevant date production is authorized for the manufacture of copies of software for commercial availability. THE WARRANTY PROVISIONS OF SECTIONS 3.3(a) AND 6.3 DO NOT APPLY TO PRELIMINARY DOCUMENTATION UPDATES, BUT DO APPLY TO FINAL DOCUMENTATION UPDATES. SINCE THE FIRST BETA CODE, FEATURES AND/OR FUNCTIONALITY MAY BE SIGNIFICANTLY DIFFERENT FROM THE CODE, FEATURES AND/OR FUNCTIONALITY OF THE COMMERCIALLY RELEASED VERSION, LICENSEE IS ADVISED THAT THERE ARE RISKS IN ANY RELIANCE ON PRELIMINARY DOCUMENTATION UPDATES, AND TO THE EXTENT THAT LICENSEE INCURS ADDITIONAL DEVELOPMENT OR ANY OTHER COSTS AS A RESULT OF SUCH RELIANCE, IT DOES SO AT ITS OWN RISK.
(c) Availability. Once a protocol becomes a WSPP Protocol under the WSPP, Microsoft will continue to make WSPP Documentation for that protocol available during the Term. Subject to the foregoing, nothing in this Agreement requires Microsoft to (i) deliver any WSPP Documentation for any modified or new protocol other than as provided in this Section 3.2 or (ii) continue to implement any WSPP Protocol in any Windows Client Operating System or Windows Server Operating System. However, Microsoft will provide notice to Licensee in the relevant portion of the WSPP Documentation of WSPP Protocols that remain available for license but which are no longer used by Microsoft in Windows Client and Server Operating Systems, generally in accordance with the timeframe in Section 3.2(a)(i).

Re:Fully interoperate with the AD

[Daengbo]

Off-topic for a second. THIS is why I have continued to suffer the 1:19 signal:noise ratio and goatse trolls on Slashdot since 1997. Especially before the dot bomb, every story had someone directly involved with the situation posting somewhere in the comments.

Got a story about VAX? There are fifteen people with decades of experience on the forum. Bruce Perens is always on any story involving him (sometimes to an annoying level...). You had to know that Jeremy would be posting on this story.

Although less than it used to be, Slashdot still has people I can't see anywhere else. Thank you, Slash!

Re:What's this mean in the real world?

[joeytmann]

Well there are the FSMO roles, and the one I think he is referring to is the PDC Emulator role, which there can be only one.

This is a real victory ... if it pans out

[megabunny]

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

Re:That's akin to

[ozmanjusri]

Maybe someone with knowledge of Samba development

You'll be disappointed. They don't use Lisp.

Most importantly though,

Under the agreement, Microsoft is required to make available and keep current a list of patent numbers it believes are related to the Microsoft implementation of the workgroup server protocols

That means Microsoft must tell Samba which patents apply to the protocols, and keep telling them. The developers will be able to avoid any patent traps.

Re:That's akin to

[Anonymous Coward]

> That means Microsoft must tell Samba which patents apply to the protocols, and keep telling them. The developers will be able to avoid any patent traps.

Those patents apply only in the US.

Hello from EU by the way ;) Believe or not, Novell/MS deal was like godsent boost for Linux here. As we don't have braindead software patents here - stuff like Mono (+ those "evil" patented apis) and OpenXML support etc, do only good here.

Shame that you guys there have to suffer from software patents ;) Even if EU would approve software patents later it wouldn't really matter (As everything before that point would go under 'prior art' and they would need to come up with new stuff and they couldn't apply for all these insane "innovations" they have patented now)

Re:Impresisons

[ledow]

Yeah, they can do the same, so long as they follow the well-established clean-room procedure, as they have done previously and are still doing. And the current (and next) Samba already has a lot of AD in it, just not stuff that's useful to managing networks like Group Policy etc. which IS covered by this agreement. AD auth is already in most samba's distributed. However, if you want to work out all the corner cases, all the undocumented stuff etc. then you need specs. Or else you can spend (literally) another decade, not to mention a lot of money on people's wages, to figure out how it all works using a bit of cleanroom reverse-engineering by which time it's obsolete and outdated.

It's a hurdle on all three counts - there are patents (but with this agreement MS has to tell us what they are and if they get any new ones that affect licensees), there are legal problems (making sure the code is CLEANLY reverse-engineered for starters) and there are technical issues (it's a whole heap of a mess and it's taking years to find out useful information that you can put in a nicely programmed version, it requires literally throwing educated-guess packets at a Windows server and trying to replicate it's response depending on the state of the entire network, the packet and the server databases).

Re:That's akin to

[sepluv]

Actually, in practice, we do have quite a lot of software patents on the books, they just aren't legally valid. That doesn't stop lawyers, judges, the European Patent Office and member state's government (especially those that wish to cosy other to the US) trying to enforce them illegally.

Even if EU would approve software patents later it wouldn't really matter

It would. The proposed directive the European Patent Office and European Commission where trying to get through that was defeated by the European Parliament would have done exactly that: retroactively grant validity to invalid patents illegally granted by the patent office.

Re:So, they can follow the law now?

[jabuzz]

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.