It's almost impossible to see and do everything you want at a Linux conference. This year's LWCE was no exception. I spent a lot of time running (well, walking briskly) from one event to another, and wishing that so many events weren't scheduled simultaneously.
The first session I attended was the State of Samba talk, given by Gerald (Jerry) Carter, a member of the Samba team and employee of Hewlett-Packard. Carter talked about a number of topics related to Samba, the status of the 3.0.x tree, the next version of Samba (4.0.x) and what might happen when Windows Vista ships.
After a bit of humor to lighten up the talk, Carter made sure to clear up a common misconception namely, that Samba is "reverse-engineered." Instead, the Samba team uses what Andrew Tridgell calls the "French Cafe technique." In short, Samba developers use network sniffers to "listen" to conversations between Microsoft clients and servers and then learn what they need to know to implement Microsoft protocols so that Samba can interoperate with Microsoft clients and servers.
Of course, everyone who uses Samba wants to know, when will Samba 4 be released? Unfortunately, nobody knows that right now, and Carter didn’t go out on a limb to guess. He did say that there should be a technical preview of Samba 4 in 30 to 60 days, which would not even be considered alpha-quality software. It won’t be feature-complete, nor will it be considered stable enough to use with production data, but it will be useful for those who want to test Samba 4 or help in development.
Even though we don’t know when it will be released, Carter did give a lot of good information about the upcoming release. It will be a complete re-write, and there are plenty of features that Samba users should be salivating over.
According to Carter, about 50 percent of the code for Samba 4 will be “auto-generated” from Interactive Data Language (IDL) files that describe the protocols. This means fewer opportunities for error. The IDL files that the Samba team generate are also being put under the LGPL, rather than the GPL, so that other teams, like the Wine project or ReactOS, might make use of them. This is good news for other groups who do work related to Windows protocols.
Samba 4 will also have its own LDAP implementation, with the Active Domain schema built in so that Samba 4 will be able to act as a Active Directory controller. There are a few things that are in AD that are not implemented in Samba 4, DNS for example, but the team is planning a way to interoperate with Bind for that issue.
Carter also discussed things that are expected in Samba 3.0.20. Keen observers may note that there are a few version numbers missing between 3.0.20 and the 3.0.14 release. That’s because they’re skipping a few versions to note the substantial number of changes. This includes an asynchronus version of winbindd, new RPC server pipes, support for printer migration tools, and reading and writing of Windows binary registry files. Carter tried to do a demo of the printer migration tool, but it didn’t quite go as planned — however, one audience member who had attended another discussion attested to the fact he saw it work elsewhere.
Samba users are also probably curious about what effect Windows Vista will have on Samba. Carter told the audience that the Samba team is subscribed to MSDN and is following Vista development, and (ideally) that Samba would work “out of the box” with Vista when it is released. It’s still not known what changes will be made to Vista over the next year or more, though, so it’s hard to say what will happen.
In all, Carter’s discussion was very enlightening as to the state of Samba, and much more enjoyable than one might expect from a technical discussion.
I also had the opportunity to attend a talk given by Eben Moglen of the Software Freedom Law Center (SFLC). Let me say this to start: If you ever have the opportunity to see Professor Moglen speak, take it.
Moglen’s talk was titled something like, “What you need to know about the GPL version 3,” but he revised it to “What you need to know about the GPL version 3, that I will tell you.” Though the audience was hopeful that they’d get an earful on the contents of the new license, Moglen didn’t spell out terms that would be in the new license. He did, however, discuss the process that would be followed in designing the new license.
First off, Moglen told the audience that the revision was “not about fixing holes” in the license, but about taking account globalization and (jokingly) “world domination” of the GPL.
He also discussed principles that would be followed in developing the next version of the GPL. For example, the first principle of the process is to “do no harm.” In short, Moglen said that they want to avoid changing freedoms already enjoyed by authors of free software.
Another principle, according to Moglen, is to make no changes which have uncertain consequences. If a proposed change has consequences that cannot be predicted, it won’t go in.
Moglen also stressed the importance of “equal respect for all stakeholders” of the GPL. This means that the needs or interests of any users and developers of the GPL should not weigh more heavily than others.
Moglen said that they would be releasing a first draft towards the end of this year or the very beginning of next year, and that there would be one year for discussion and revision of the license. He also said that they would release a detailed document with the first draft noting their rationale for each change and, in some cases, rationale for not making changes.
He noted that there would be hard cut-off dates for the stages of the process to revise the license, and that it would be a very well-organized process to help all stakeholders have an opportunity to be heard on the revision of the license. In the end, however, he noted that the final word on changes to the license would be Richard Stallman’s. Moglen also said that they wanted to “limit yelling, without limiting discussion” on the license.
Some issues may have separate discussions. For example, whether or not to provide “official” translations of the GPL version 3. There are a lot of legal issues and complexity around providing translations of the GPL, since it’s often difficult to translate a document such as the GPL precisely into another language.
The LGPL will also be revised during this period, though most of the attention has been focused on the GPL. Moglen noted, however, that some parties may be more interested in the LGPL’s revision than in the GPL.
While Moglen didn’t specify what would be in the new license, he did talk about some areas of speculation. For example, the topic of Web services. Some want to see clauses that require distribution of changes to code when GPL’ed code is used to provide a web service but the code itself isn’t actually “distributed” to users. Moglen talked about the two sides in the discussion and the possible downsides of including Web services clauses in the new GPL. No doubt it will be a strong subject of debate, but no clue yet as to whether the first draft of the revised license will include any language on Web services.
Many people also want to see patents addressed in the new version. However, Moglen noted that a new GPL was unlikely to solve the “patent problem,” but didn’t rule out or confirm any changes in the new license to address patents.
In the end, Moglen said that the revised license would actually not be radically different from the current GPL, and that it would be more like renovating a house than starting from scratch.
Though Moglen’s talk didn’t give us a clear picture of the new GPL, it was encouraging to see how much thought has obviously been given to the revision of the license and doing the revision without making radical changes that would affect the adoption of the new license or cause a rift in the free software community.
I also had a chance to attend Bruce Perens’ “Expert Author Panel,” which ended up being largely a discussion of the problem of software patents. The subject of patents kept cropping up in discussions around the show and after the show. Unfortunately, nobody seems to have a concrete answer for what users can actually do to help defeat the threat.
After Perens’ panel, I talked for a while with Jeff Waugh of Ubuntu and GNOME fame, mostly about the things coming up in Breezy Badger and beyond for Ubuntu. One of the first things Waugh mentioned to look for in Breezy is OEM configuration tools that will let OEMs set up custom Ubuntu installs, that then have a simple configuration for the user before they’re launched into the desktop.
Waugh also talked about the certification program for Ubuntu, which would be implemented on top of the LPI certification. Users who already have the LPI 101 and 102 exams under their belts will be able to take a single exam that focuses only on the Ubuntu-specific bits.
We also talked about Malone, the collaborative bug tracker being developed by Canonical, and Soyuz, a tool to keep track of software in Ubuntu and other Linux distributions. These tools look very promising, and may be able to take open source development to the “next level” by letting various projects and vendors collaborate in the same way that individual developers have been able to collaborate in specific projects. Right now, there’s a lot of bug fixing and revisions that get accidentally “dropped” between different vendors and projects. For example, each Linux distributor ships Samba. Their fixes and modifications to Samba for their version of Linux may not be easy to send back upstream. However, by using Malone and Soyuz, it would make it easier to share patches between projects and vendors.
I also asked Waugh why Ubuntu was not participating in the DCCA. Waugh said that “we don’t really have any confidence that the DCCA will work,” and gave a number of reasons why. One problem, according to Waugh, is that the DCCA plans to be compatible with Debian Sarge, but also to provide LSB 3.0 compatibility — which Sarge is not. “The kinds of things they need to do to make it compliant means it’s not Sarge anymore…for LSB 3, it’s going to be pretty rough.”
He also said that the DCCA has “been described as an open source project, and that’s not something ISVs are interested in working with.” Waugh also cited previous failures (the UnitedLinux Project and the Linux Core Consortium) as examples that the idea is unlikely to succeed.
Waugh also talked about the upcoming release for next year, that will be released by the Ubuntu Foundation. This release will be supported for five years, which makes it very attractive for OEMs and corporations who need that kind of lifespan in a distribution.
Unfortunately, Xen won’t be making it into Breezy. Waugh said that it wasn’t quite ready in time for the Breezy release, but did say that it would be in the release next year.
There are few other things that Waugh and I talked about, which will appear early next week in a podcast. Due to technical difficulties, that will have to wait until I have access to a different computer to upload audio.
Tomorrow, I’ll post a report on the final day of the conference and pictures from the show floor.