Chris DiBona's job--manager of Google's open-source programs--is a balancing act.
Google consumes a lot of open-source software for its own highly profitable business. But as he oversees the search powerhouse's open-source work, DiBona has to ensure that the company reciprocates. It can't be all take and no give.
Chris DiBona, Google's manager of open-source programs
(Credit: Stephen Shankland/CNET News.com)Free and open-source software advocates can be powerful allies--but also vocal critics. For example, some have critized Google for its lack of support for the Affero GPL license, which can require those using software for a publicly available network service to share modifications they've made to an AGPL software project.
DiBona thinks Google strikes the right balance, though, by offering its own modifications back to many open-source projects, advocating the philosophy in general, and trying to nurture the next generation of open-source programmers.
DiBona has been steeped in open-source software for more than a decade. Before his job at Google, he worked for Slashdot, still an influential virtual water cooler for open-source discussion. Slashdot was part of Linux server maker VA Linux Systems, which had a spectacular initial public offering in 1999 followed not long after by a drastic cutback.
DiBona will be preaching the open-source gospel at the Google I/O conference Wednesday--"open source is too good to be true and thus must be magic," according to the agenda--but I sat down with him beforehand to hear his view of open-source software at Google.
What's the view of open source within Google?
I asked myself, "Who am I trying to address?" The world of open-source business? No. The world of the open-source enthusiast? No. I'm really looking to work with open-source developers. We came up with these goals for our group: to support open-source development in general, which means to support open-source infrastructure; support the release of open-source code, from Google and in general; and to create more open-source developers, because especially when I started, there was a perception that Google took a lot of people from the open-source world and then went away. It was partly true, because people would come here and say, "Wow, I've been working on my open-source project forever, and I want a new problem," and we have a very good class of new problem. So they kind of went away.
That was too bad. The last thing we wanted as a company was to hurt the release of open-source software, because we consider it pretty important. We use a ton of it. Every engineer we bring on--how much open-source do they want to use? We have new packages and new libraries being brought into the company all the time. It's our group's job to track that. As we brought people in, we wanted to be sure more open-source developers were being created. So that's where we came up with the Google Summer of Code, and now we have a high-school flavor of that as well. I think we've made a very real impact in creating new people in the open-source world.
I'm curious about maintaining a balance between contributing back to upstream projects vs. maintaining your own internal forks. How do you go through that evaluation?
Google considers some projects more important than others. Obviously the Linux kernel is incredibly important. Every time you use Google, you're using a machine running the Linux kernel. We have a fairly large kernel team, and we employ people whose job is just to work on the external kernel. Andrew Morton is a good example of that. We try to make sure those guys patch out (submit their modifications to the main open-source project) whenever they can. It's usually more dictated by the engineer's time than it is any lack of desire on our part. I always wish we were able to release more, but it takes time for an engineer to do that. For the larger efforts, it's a little easier because there are more personnel on it.
The same thing goes for our compilers (software that translates programmers' code into instructions a computer understands). The great thing about our compiler team is they patch as a matter of their jobs. They're always patching out things from the compiler work we do internally to the outside world. We recently released the new linker, Gold--Ian Lance Taylor works for us on our compiler team. He's been on the GCC team forever. He used to be at Cygnus (a company that developed GCC). We have a lot of ex-Cygnus people.
Then there are Googlers who just want to patch into an existing projects. They found a bug, they want to add a feature. That takes no time at all. Our team looks at the first couple patches an engineer wants to send out, makes sure the engineer knows what they're doing with the outside world, then they're basically given free rein to do that. They keep us posted on what they're patching. We want to make sure our code gets out to the projects as fast as possible because projects keep on iterating. If you don't get your patches in, they won't get accepted, because they'll be too old or won't matter. If you've got a patch, getting it out there fast is better for us, because then as that project iterates and comes back into the company, we don't have to reapply a patch.
What are the most important open-source projects you ingest?
The kernel, compilers--GCC, the Python interpreter. Python is very important to us. Google App Engine--it's a Python hosting system, basically. Java is very important to us, and that's become open-source now. We have some very good Java people working for us--Josh Block, Neil Gafter--they've got a great handle on that technology.
Once you get past those three projects--the compilers, the languages, the kernel--then you go to the libraries. For us that's OpenSSL, zlib, PCRE. MySQL is hugely important to us. Past that, it starts tapering off pretty quick.
Has the open-sourcing of Java changed anything for you?
Not really. I think it had more impact on the outside world than for us. Java is a fairly mature language now. We've been using it for a long time. Before, it was the JCP (the Java Community Process to govern Java's future)--it had the rubric of openness around it. It was never really not so open. There are questions around what open source means now around Java, specifically J2ME (Java's mobile edition for gadgets such as cell phones) and the TCK (the technology compatibility kit).
Are you using a super-uber-customized Linux kernel, or are you guys pretty much vanilla?
I don't think there's such thing as a customized Linux kernel anymore. The kernel is incredibly flexible. It's got all these different architectures. I think the Linux kernel itself is this ubercustomized thing.
But do you have a lot of in-house customizations?
Not a lot. Google is exposed to some interesting hardware before the rest of the world. So internally we'll be sampling code for that hardware. So that's pretty custom stuff. But eventually that goes to the outside world. We funded some work with a group in Berkeley called Xorp to bring high-speed Broadcom networking chip functionality to Linux. It's not in our interest to keep control of it ourselves. So is it customized? Absolutely. But is it heavily customized? I don't think it is as heavily customized as you might think.
Is it true you still use 2.4 kernels?
In some places, sure.
How about for the core search product?
I don't know how it's partitioned out. When you think of Google, you think of search being on top of a kernel that's static. It's not always like that. It differs on data centers. I think 2.6 predominates, though.
I do worry about this. I think it is a largely incorrect perception. You can always give out more, and there are always people who will never be satisfied. Could we be giving back more? Sure. One of the ways I ameliorate that problem is (through) projects like the Summer of Code. Google is releasing every year, not counting Android or the really large open-source projects like GWT, a new project every two or three weeks. Or patching hundreds of projects a month. I conservatively estimate we're releasing about a million lines of code a year from the company.
If you talk to open-source developers--people who are working on projects--I think they understand that. It came back to who do we want to interact with. I always felt the enthusiast community would understand that eventually, and I think that's true. There are some people who are upset with us because we didn't embrace the Affero-style GPL, but it's not practical for us to do so. When they had an Affero-style clause in GPLv3, the thing I told Eben was, "Listen, you can adopt whatever you want. We'll still keep on backing up the FSF and the SFLC as much as we can, but it means we won't be able to use that license inside, because it won't be practical for us to do so." I think that's a very realistic response. The Affero GPL is out there. That's great for the people who use it. It's just not for us.
That's the thing about free software. You're not obligated to use it. We have enough fine-grained control within the company that we don't use things we don't want to use.
What are your preferred licenses?
We generally release under the Apache License--Apache 2. We think it has the fairest language of the licenses. And the GPL requires a lot of management--more than we have time for to run a project well under that license--patch flow and all that. Apache 2 encourages people to take the thing and run with it. That's what we're going for when we release code, whether it's to have people adopt technologies we really like, or for API examples. That said, we've released things under the GPL, LGPL, GPL version 3, BSD. We default to the Apache License.
To what extent to you subsidize gurus to sit around and work on important projects?
We've got people like Jeremy Allison and Andrew Morton and some of Guido (van Rossom)'s time. He's been working pretty heavily on Google App Engine and Mondrian. It's more common that we...try to make open source a part of their job, so they're patching out to the libraries they use. We think that's more healthy than having people whose job is just working on an open-source project.
We do. There are two ways we do this. When somebody wants to bring a piece of code in from the outside world--open-source or commercial--you need to put it inside a special directory we call "third party." They're required to put in a file called readme.google (that describes) where they got that software, how it's licensed, what category that license falls under. We look for things that are obvious. There are some projects that have dubious intellectual property provenance, and we know those, and we know the people who run them, and we tend not to use those ever.
Since Google doesn't distribute a lot of software, we have it easier than companies that ship hardware and software. We have a couple situations where that does happen--the Google Search Appliance, some of the downloadable applications. Those get a little extra attention. Similarly, when we have larger projects like Google Android, we have a higher ceremony--every two weeks we get together and see if the license picture has changed.
The tracking model works really well for us. We have tools written where a program manager or a release manager can turn on a certain level of warning within the build tool and it will tell them what open-source software they have and how they have to comply with it. At that point we set up a mirror for them as they get closer to release.
So that's the first way we track things. The second way is whenever a Googler puts in a changelist now--this is something we're just starting to do--we compare it against all known open-source code on the Internet using our Code Search product. We compare the changelist that comes from your average Google engineer against that database of code and we look for intersections. When we find an intersection, we take a look and see if it's truly a copy. And if it is, we make sure it's in the right directory and that it's properly labeled. And we call up the engineer if it isn't and make sure it gets tagged properly so we can do the right thing by these licenses.
That tool is kind of in its infancy. We're trying to figure out ways to automate what it does. But it's great because it scales programmatically. Our group's goal is not to break builds or stop development. It's to enable developers to use as much open-source as possible. We think it's healthy, because then they're not writing that code, they're writing other code.
Do you vet code for patent or copyright?
No. We have legal people on our lists. We have two main lists that track these things. Open-source licensing for incoming code and open-source releasing for outgoing code. Legal has a presence there. Patents are incredibly tricky.
Is it easier to get hired at Google if you have experience maintaining your own open-source product or patch?
If you have made a name for yourself in open source, clearly it helps. If you have a healthy project in open-source, I believe it helps. One thing I see on hiring committees is when somebody has an open-source history, it's really great. You can just look at that history. Interviews are great, but they're not very deep. They're only 45 minutes long. So how can you really get a feel for if a person is good at programming, at computer science?
Or at social relations, for that matter.
Open source really reveals that incredibly quickly. You can look at their code, at their activity on mailing lists, how they deal with bugs from real people, and real user problems. That's an incredible resource.
The Summer of Code isn't really a recruiting program. If it is, it's a really expensive one. Last year we created about 2 million lines of open-source code across the 900 students who took part. Of those probably a third are going to stick around with their projects, because the rest have to go back to college.
We have a couple students who have been in the program two or three years. The whole point is to support kids over the summer so they can go and program and not get some other job that has nothing to do with computer science. It's our fourth year doing it. This year we've go 1,109 students doing it across 95 countries.
MOUNTAIN VIEW, Calif.--Google didn't invent open-source programming or pioneer the mobile-phone software market, but when it comes to its Android project, don't accuse Google of playing follow the leader.
Although the company has long used open-source software within its internal operations, Android is Google's highest-profile attempt so far to use the collaborative programming method to change how computing is done outside the company's walls.
Andy Rubin, head of Google's Android project.
(Credit: Stephen Shankland/CNET News.com)Google is hardly the first company to try using open-source software to shake up the industry. What's notable is Google's willingness to ruffle feathers in the open-source world, including those of potential allies such as Red Hat, with its approach.
Google is bucking some open-source conventions by avoiding the fashionable General Public License (GPL) to govern the software and creating the software internally before involving outsiders. At the same time, though, it's been easing gradually into the mainstream open-source fold.
"Initially their approach was almost like a proprietary product approach," said John Bruggeman, chief marketing officer of Linux seller and Android partner Wind River. "I think they have adjusted all elements of that strategy as they go. It's much more open-source friendly, more developer friendly."
And though Google's path might be somewhat different, the company has a decidedly ordinary open-source destination in mind: building a broad, cooperative community to thwart a Microsoft hegemony.
Andy Rubin, the Google engineering director leading Android, likens today's chaotic hodge-podge of mobile phone software to the early days of personal computers. In mobile phones, though, Microsoft has begun offering integrated software ranging from office applications and a Web browser at the high level down through the operating system kernel at the low level, and that full suite has a powerful appeal to phone manufacturers.
"It's a repeat of what happened in the PC industry. We want to make sure there's an alternative," Rubin said. But Google doesn't want to be the sole gateway to its software. "We wanted to make sure there's not a single source, (so) if a carrier or user or third party encountered a problem, they could fix it themselves."
Android is massive open-source project--or at least it will become one when the first phones start shipping later this year. The recent version 2.6.24 of the Linux kernel has about 8 million lines of code, but about 8.6 million lines of Android's 11 million are open-source, Rubin said.
Android components that will emerge as open-source software include Nuance's speech-recognition software and PacketVideo's music and audio decoder. Google also has been working to obtain hardware specifications to support mobile-phone chips from Qualcomm, Broadcom, and Sirf, he said. "You'll see our stuff being the first Linux on Qualcomm," Rubin said.
Closed first, then open
But that open-source release will be complex. Depending on how it manages the task, Google could face praise or scorn later this year when it unleashes that code upon the world. The hardest part is not just sharing the code, but in integrating outside developers into a project that's been growing within a company's confines.
There's nothing technically wrong with an open-source project that's solely run by a single company, but it's rarely any company's open-source goal. It's not likely to attract outside coders who want to make a name for themselves by adding important new features or corporate allies that might fund their own contributions.
Google's closed start doesn't sit well with Red Hat Chief Technology Officer Brian Stevens, whose company is among the most aggressive advocates of open-source software.
"I think that decreases their chance of success more than it increases it," Stevens said. "It's preventing the participation of many smart developers who want to get involved in the development of the Android platform...The community comes at the early inception of a product, not when you decide you're ready to ship a product."
Mike Schroepfer, Mozilla's vice president of engineering, added that in general, corporate attempts to make open-source projects out of proprietary software are often hampered by an unwillingness to share control.
"People think publishing the source code is the hard part, but the harder thing by far is having open participation in the decision-making--distributing authority outside your four walls," Schroepfer said. "Where some of these really go wrong is when people aren't empowered and their voices don't matter, they're not going to do participate."
Google won't face the challenges of full-on proprietary software going open-source, though, said Redmonk analyst Stephen O'Grady: the open-source move is part of the Android plan, not a development that arrived years later.
The open-source hand-off
Google has its reasons for the closed start.
"We want to get to the point where it's stable enough," Rubin said. Then, after the open-source change, "We want it to be thriving."
The software components that constitute Android.
(Credit: Google)The company is working on the hand-off to the outside world. Android already is a project whose development is distributed among the Open Handset Alliance members collectively backing Android, for starts, as well as among multiple international Google offices. "We're learning how to do a large-scale distributed effort," Rubin said.
The company also has a team more 10 strong working on external developer relations for Android, Rubin said. That team that will grow larger once the code is released and absorbs the Google "maintainers" in charge of Android components, such as its Dalvik virtual-machine software for running applications written in Java.
Google's team under open-source project manager Chris DiBona, combined with some from the Android project, will work with outside programmers, Rubin said. "The developers I have on core development of this, when it gets open-sourced, will move over and will be coding for the open-source tree," or code base, he said.
Google also is taking a community-centric approach to defining what Android is. Project maintainers get to accept or reject contributions, as is common in the open-source realm. What's new is that Google will offer a certification test suite that's based on those maintainers' work in order to maintain compatibility among different versions of Android.
"If it passes, then they get to use the Open Handset Alliance Android trademark name," Rubin said. "We're not saying you can't branch. We're saying you don't want to branch."
Licensing choices
Google has been criticized for not working with existing open-source projects. In addition, Sun Microsystems has expressed concern that Google's development of Dalvik could fragment the Java world so that Java software for running Android applications wouldn't work on other Java phones and vice versa.
A sample Android application, AndroidGlobalTime
(Credit: Google)But Google chose to go it alone with Dalvik and some other projects for one big reason, Rubin said: it wanted to avoid the GNU General Public License (GPL). The pioneering license that serves in effect as the manifesto of the Free Software movement requires that software projects derived from a GPL product also be released under GPL. That concept in effect requires reciprocity: if you use GPL code and distribute the resulting software, you must contribute your changes back to the GPL code base.
Google didn't want to raise that issue, uncharitably referred to as the GPL's "viral" nature, for phone makers that might want to add proprietary features as a way to differentiate, so it chose the less confining Apache License, Rubin said.
"The thing that worries me about GPL is this: suppose Samsung wants to build a phone that's different in features and functionality than (one from) LG. If everything on the phone was GPL, any applications or user interface enhancements that Samsung did, they would have to contribute back," Rubin said. "At the application layer, GPL doesn't work."
Of course, giving back is precisely one of the intents of the license, which Richard Stallman initially wrote to govern a clone of Unix that couldn't be made proprietary; many companies have embraced the GPL, including initial skeptics such as Wind River. And other embedded-computing efforts are using GPL software more widely.
"It's a pretty conservative interpretation," Bruggeman said of Google's GPL stance.
Open-source advocates long have wrestled over whether it's better to permit companies to make code proprietary, as the Apache License permits, or to compel them to keep it open, as the GPL requires. Even though Android uses the Linux kernel, which is governed by the GPL, don't expect Google's position to put an end to this debate.
For that matter, don't expect Rubin's present thoughts to be the final word. The company has shown itself willing to change.
"Here's what I think. No. 1, they're learning as they go," Bruggeman said. "No. 2, they learn really fast."
Over the years, Microsoft statements toward open-source software have ranged from derision and threats to mollification and even cautious praise.
Microsoft's Thursday announcement of a significantly more accommodating approach to open-source programmers is just the latest refinement of the company's ambivalence. At the same time that Microsoft's new arrangement opens up previously secret specifications and protocols for use in open-source software, it also insists that companies planning on distributing or using that software need a patent license.
So to put the news into historical context, here's a chronology of some of Microsoft's statements and practices regarding open-source software over the years:
On October 31, 1998, the first so-called "Halloween memo" from Microsoft suggested that some in the company saw open-source software as a major threat. "The intrinsic parallelism and free idea exchange in open-source software has benefits that are not replicable with our current licensing model and therefore present a long-term developer mindshare threat," the memo said, suggesting that one way to thwart open-source software would be to extend communication protocols with Microsoft-only changes.
In May 2001, Microsoft Senior Vice President Craig Mundie derided the business model of open-source software companies that aim to sell support rather than software licenses, likening the practice to that of failed dot-com companies. "A common trait of many of the companies that failed is that they gave away for free or at a loss the very thing they produced that was of greatest value--in the hope that somehow they'd make money selling something else," Mundie said.
In June 2001, Microsoft co-founder Bill Gates described the widely used General Public License as "Pac-Man-like," referring to the GPL's requirement that software tightly integrated with GPL components must by the license also be governed by the GPL.
In a June 2001 interview with the Chicago Sun-Times, Microsoft Chief Executive Steve Ballmer said, "Linux is a cancer that attaches itself in an intellectual property sense to everything it touches...The way the license is written (the Linux kernel uses the GPL), if you use any open-source software, you have to make the rest of your software open source."
A newer "Halloween" internal memo, based on research in 2001, warned that Microsoft's attacks on open-source software and licensing "are not effective" and are backfiring.
In an October 2002 interview, Ballmer touted Microsoft's shared-source program, which initially emulated some open-source attributes without giving programmers full freedoms. "We're learning...from the Linux world...If you take a look at the Linux world...There are many more communities in the Windows world than in the Linux world. I don't think we have mobilized that community as effectively as the Linux community has."
In June 2003, Pete Houston, Microsoft's senior director server strategy, said Microsoft had moved beyond its philosophical attacks and had begun trying to show customers the "business value" of Microsoft products. "I don't see the Linux community development model building the integrated offerings we have today," he said.
A Microsoft executive, Richard Emerson, helped to arrange an October 2003 investment of $50 million in The SCO Group shortly after it began a high-profile but largely unsuccessful attack that argued Linux violated the company's Unix intellectual property, according to the head of BayStar Capital, which made the investment.
In January 2004, Microsoft launched a "Get the Facts" ad campaign to try to show the cost advantages of Windows and other Microsoft products compared with open-source rivals.
Midway through the decade, Microsoft softened its attacks and even began launching its own open-source projects.
In June 2005, Ballmer said Microsoft isn't trying to compete with the philosophy behind Linux, only with it as a software product. "We come to work every day and we compete with products, we don't compete with movements," he said.
In June 2006, Microsoft launched a site called CodePlex to host shared-source projects.
In May 2007, Ballmer and Brad Smith, Microsoft's top lawyer, said Linux and other opens-source projects collectively violate 235 Microsoft patents. "We live in a world where we honor, and support the honoring of, intellectual property," Ballmer said in an interview with Fortune. Microsoft's open-source competitors must "play by the same rules as the rest of the business."
In September 2007, Clint Patterson, public relations director for Microsoft's Unified Communications Group, said: "The open-source development model has yet to demonstrate the ability to support profitable software businesses that can drive the coordinated research and testing necessary to sustain innovation."
In October 2007, after Red Hat Linux had declined to enter into a patent licensing-deal the way rival Novell had, Microsoft's Ballmer told an audience that customers using Red Hat Linux need to pay Microsoft for its intellectual property. "People (who) use Red Hat, at least with respect to our intellectual property, in a sense have an obligation to eventually to compensate us."
In October 2007, the Open Source Initiative grants official open-source status to two Microsoft licenses, meaning that projects governed by those licenses may be called open-source software.
Finally, here's how Ballmer described Thursday's move: "Our goal is to promote greater interoperability, opportunity, and choice for customers and developers throughout the industry by making our products more open and by sharing even more information about our technologies."
Open-Xchange is using Yahoo's acquisition of rival Zimbra last year as an invitation to tackle the U.S. market with its open-source server software for e-mail, calendars, and other collaboration tools.
"Now is the time. The vacuum has been created, and we feel the suction," said Rafael Laguna de la Vera, who took over as chief executive in January. "Yahoo is not a software company...Now, with Microsoft (trying to acquire Yahoo), I think it's over for Zimbra."
Those are bold words for a CEO of an unprofitable company with 2007 revenue of $2.5 million that has struggled for years to penetrate the crowded "collaboration" software market. But Laguna also shared other plans to elevate Open-Xchange's profile:
On Thursday, Open-Xchange plans to announce a broader release of its software as open-source under the General Public License (GPL). Coming will be installation and administration tools that previously were proprietary.
Two other non-open-source components, a connector that lets Microsoft Outlook connect to an Open-Xchange server and the Ajax-based user interface for the Web-based access to the server product, will eventually become open-source, too, within a year or two, Laguna said.
The company plans to join the Eclipse Foundation during the first half of 2008 to take advantage of the OSGI (which formerly stood for Open Services Gateway Initiative) tools to integrate software components. "We will be dual-license the server code under the Eclipse Public License," Laguna said.
Laguna plans to hire U.S. programmers and other staff to augment the company's current staff of 40. "Marketing, management, global sales, user interface usability--all will be here," he said.
Open-Xchange might raise a new round of funding to hasten these expansion efforts.
The company's current main sales approach is to sign partnerships with Internet hosting companies that can offer the software as an add-on subscription service to those registering Internet domains. Its biggest partner to date, 1&1 Internet, plans to extend its partnership to the United States within the first half of 2008, Laguna said.
The company, originally called Netline Internet Service and based in Olpe, Germany, made its way to market chiefly through a partnership with Suse Linux. It's been trying for years to stand on its own, in particular after Suse was acquired by Novell, whose GroupWise product competes.
Because of the strength of open-source rival Zimbra and its willingness to sell at low prices, though, Open-Xchange chose to concentrate its efforts in Europe, Laguna said. "You pick your battles," he said.
The overseas ambition resembles those made by Suse, where Laguna worked until its acquisition by Novell. Suse wasn't terribly successful, but Laguna thinks things will be different: Suse was thwarted by Red Hat in the Linux market, but Laguna believes Open-Xchange now can take on Zimbra.
He's not the only Suse veteran at Open-Xchange with experience trying to perform this sort of conquest. Suse's former chief, Richard Seibt, is on Open-Xchange's board, and its chief technology officer is Juergen Geck, who held that post at Suse.
The Qt components make it easier to build software that runs on many operating systems.
(Credit: Trolltech)Finnish mobile-phone giant Nokia has acquired Norway's Trolltech for about $150 million, the companies said Monday.
The Nordic merger significantly expands the possibilities of Nokia's Linux-based phone efforts. Trolltech makes open-source software and programming tools that can be used to build software on mobile phones, and Nokia has been working for years on mobile Linux devices.
In the open-source programming realm, Trolltech is known well for its Qt library of user interface components such as buttons and drop-down menus. While Qt is governed by the General Public License (GPL), the elements also may be used in proprietary programming projects. Using the components also makes it easier to build software that runs on multiple operating systems.
Indeed, Nokia--which must reckon with many operating systems already--evidently sees that advantage. "The acquisition of Trolltech will enable Nokia to accelerate its cross-platform software strategy for mobile devices and desktop applications and develop its Internet services business," the company said in a statement. "With Trolltech, Nokia and third-party developers will be able to develop applications that work in the Internet, across Nokia's device portfolio and on PCs."
Nokia also went out of its way to reassure open-source fans that it won't be dropping Trolltech's open-source ways. "Nokia embraces open-source technology and will take further the open-source development culture found in Trolltech," the company said.
- Adobe Photoshop Elements 6 for Mac to ship in second quarter 2008 - Adobe previously said "early 2008," (http://www.news.com/8301-13580_3-9783661-39.html) but now it's second quarter. Not a big deal since Mac folks get iPhoto. Why bother offering pre-order months early? Answer: to make it not look like a delay.
- More Canon 5D Mark II Rumors | Photography Bay - Some guy's Canon rep said to expect an announcement of the new low-end full-frame camera at PMA (which starts January 31, but Canon's announcement looks like January 24).
- Tighter intellectual property restirctions at iStockphoto.com - iStockphoto is tightening restrictions on permissible photos; Previously, no face, no model release required. Now, if subject could recognize him- or herself, needs a release. Also out: recognizable cars, cruise ships.
- SimCity Source Code under GPL - The original SimCity is now under GPL, called Micropolis for legal reasons and refurbished somewhat.
- Mainframe: Will Microsoft Windows be next on System z? - Back in the 1994, IBM figured out how to boot Windows on a mainframe, but legal machinations between IBM, Microsoft, and Bristol Technologies killed it. "We'll never see a day when Windows will run natively on the mainframe."
- The Online Photographer: The Arc of a Forum Exchange - An amusing parody of a typical forum. Look for the hidden original definition (now probably obsolete mostly) of a prime lens.
- Peachpit: Adobe Photoshop Lightroom Resource Center - A big collection of book chapter excerpts, videos, and other useful Lightroom training material.
- Holy moly--Nikon D3 SLRs spotted on the NFL sidelines - Canon has such a lock on pro sports photography that it's news even if just a handful of Nikons are in use.
- Shortcuts You Must Memorize - Inside Lightroom - I agree--this is a great list of very useful Lightroom keyboard shortcuts.
- PDF: Now an ISO Standard - Let's hope this will make "export to PDF" more common. It really is a useful format, despite its hassles and annoyances.
A complicated third-party arrangement means that the open-source Samba project will be able to make use of proprietary documents describing Microsoft file-sharing software.
Samba, governed by the General Public License (GPL), lets Unix or Linux servers behave like Windows machines used to share files over a network and control networked printers. But the effort has been difficult: Microsoft doesn't go out of its way to share the details of the protocols; patent infringement concerns also have appeared more than once.
On Thursday, though, the Samba team announced a deal that gets around the previous barriers. The increasingly influential Software Freedom Law Center, led by open-source legal guru Eben Moglen, established a nonprofit group called the Protocol Freedom Information Foundation. The PFIF is paying Microsoft 10,000 euros (about $14,400) for documentation that will be shared under a nondisclosure agreement (click here for a PDF of the NDA or read this Samba explanation for further details) with Samba programmers.
Those programmers are free to write code based on the documentation, though not to share the documentation itself, Samba said. And Microsoft must keep the documentation up to date.
The move is interesting for a number of reasons. For one thing, it's a concrete outcome after years of antitrust efforts that had left many Microsoft foes bitter. For another, the technological repercussions very likely will strengthen a direct Microsoft competitor. And perhaps most interesting, it illustrates the growing legal sophistication and clout of the free and open-source programming movement.
Samba leader Jeremy Allison is champing at the bit with the technical possibilities the agreement opens up for the software project.
"If you'll pardon me breaking into song: it's beginning to look a lot like Christmas," Allison said.
Among the features he expects will be added as a result of the agreement are full support for Microsoft's Active Directory, encrypted files, a better search interface, and support for "SMB2," a new version of Microsoft's Server Message Block protocol after which the Samba project took its name. SMB2 is built into Longhorn Server, which when released in 2008 will be called Windows Server 2008.
I asked Allison whether open-source code in fact reveals information in the proprietary documentation. "It does to those who can understand it. It's not revealing the actual documents, though, and that's the main thing," he said.
Why was Microsoft so willing to share the specifications now? In short, the antitrust case the European Union brought against Microsoft required the company to release interoperability information. Most recently, Microsoft agreed to share the information for a one-time fee rather than requiring a share of revenues from products--a pricing scheme that doesn't jibe well with open-source methods.
The roundabout way of getting proprietary information to an open-source project may sound abstruse, but it's actually relatively common. Companies provide information to open-source programmers under nondisclosure terms, knowing full well the coders will release open-source code that reveals at least in part how hardware works.
Indeed, one purpose of the Linux Foundation is to make sure there's an organization in place to handle NDAs. Novell programmer Greg Kroah-Hartman now runs a program that regularly does so in order to write software drivers that let Linux computers communicate with various hardware devices.
One specific case in point: Red Hat programmer David Miller has worked with Sun Microsystems to bring Linux support to its Sparc processors. "I signed an NDA with Sun that got me the documentation and allowed me to write GPL code using it, but I'm not allowed to pass on those documents to others."
What's notable about the Samba case is that it involves Microsoft, which at times has been outspoken about free and open-source software. Although the company tried to tone down earlier rhetoric that called the programming movement "un-American" and a "cancer," the company resumed the offensive this year, declaring in May that Linux and other open-source projects infringe 235 Microsoft patents. Microsoft didn't say which specific patents it believed were infringed.
The Samba agreement also specifically addresses the patent issue. Microsoft is required to make a current list of patents involved in the protocols, Samba said, letting programmers work around them.
"The patent list provides us with a bounded set of work needed to ensure non-infringement of Samba and other free-software projects that implement the protocols documented by Microsoft under this agreement," Samba said Thursday. "Any patents outside this list cannot be asserted by Microsoft against any implementation developed using the supplied documentation."
For a blow-by-blow history of Samba's attempts to get access to the Microsoft documentation, another Samba leader, Andrew Tridgell, has posted a long account at the Samba Web site.
Intel has released source code for a server software project that lets Fibre Channel communications run on a more ordinary Ethernet network.
Fibre Channel is a higher-end network technology used to connect storage systems to servers. Intel and networking giant Cisco Systems are among those working to adapt it for ordinary and ubiquitous Ethernet technology, a technology called Fibre Channel over Ethernet (FCoE), appropriately enough.
To further the project, Intel on Tuesday announced the Open-FCoE.org to house the source code. It's governed by version 2 of the General Public License.
The code itself was announced in November on the project mailing list by Robert Love, a kernel programmer and Intel employee.
Programmers behind Busybox, a collection of utilities governed by the General Public License (GPL), have settled a second lawsuit that argued a company violated the widely used free and open-source license.
This time the company that settled is Xterasys, which makes networking products, said the Software Freedom Law Center, which represented the Busybox coders.
"As a result of the settlement, Xterasys has agreed to cease all binary distribution of BusyBox until SFLC confirms it has published complete corresponding source code on its Web site. Once SFLC verifies that the complete source code is available, Xterasys' full rights to distribute BusyBox under the GPL will be reinstated," the center said on Monday. In addition, Xterasys agreed to appoint an open-source compliance officer, notify those who may have received the Busybox software from Xterasys of their GPL-granted rights, and pay the Busybox programers an undisclosed amount, SFLC said.
The Busybox programmers had sued Xterasys and High-Gain Antennas in November, not long after suing Monsoon Multimedia and not long before suing Verizon Communications. The moves collectively show that at least some are willing to be more legally assertive about GPL enforcement than in the past.
Monsoon settled its GPL lawsuit in October.
Flickr on Thursday released a new version of its tool for uploading photos to the Yahoo photo-sharing site, and made it an open-source program in the process.
Flickr Uploadr 3.0, available for Mac OS X 10.4 and 10.5 and for Windows XP and Vista is now available in source code form, too, governed by version 2 of the General Public License (GPL). Open-source software may be freely modified, copied, and shared; opening source code could let programmers modify the Uploadr tool so it works on Linux or uploads to other photo-sharing sites, for example.
Uploadr lets photographers select photos for upload, add tags, organize them into sets, and change privacy settings. Among the changes in Version 3 is the ability to set the photo order in sets and to add new photos to the upload queue while others are in the process of being transferred.
Uploadr 3.0 also inherits Flickr's multilanguage support: English, French, traditional Chinese, Korean, German, Spanish, Italian, and Portuguese.
Flickr also released a new statistics tool Thursday for pro users (pro accounts cost $25 per year but are free for those who get DSL through Yahoo-branded deals). Flickr Stats shows whence visitors came to look at your photos, either from within Flickr or outside on the Web.
Stats also shows totals for recent viewings of photos and compiles data such as how many photos have tags, geotags, and comments. Views of your photos can be sorted by viewing totals, comments, favorite status, and the ever-elusive "interestingness" ranking.





