OScon: are licenses important?

by Andy Oram

Related link: http://www.oreillynet.com/oscon2003/

I experienced déjà vu twice during Tim
this morning. I remembered that many years ago he was asked, along
with a number of other leaders in computing, whether Unix had produced
a "killer app." Tim replied with aplomb that the Internet was Unix's
killer app, but most people reacted with shrugs or giggles. I think
this was an earlier stage of the same paradigm shift Tim is talking
about these days.

At this point, the big "applications" changing people's lives are
services such as Amazon.com, Google, and Yahoo. These are data-heavy;
the way they work is less important than the data.they offer. Because
of the centrality of the data, they require constant updating, which
in turn requires people. The application does not stand on its own.

I will leave a summary of Tim's keynote to others, but I must spend a
moment on his dismissive attitude toward open source licenses. Tim
built his case carefully, pointing out that Usenet created the
original far-flung community of collaborating programmers, followed on
by the Internet. Infrastructure, therefore did more to create an
environment conducive to free software development than licenses. In
fact, he said, Larry Wall's patch program did as much as any license.

Tim wrapped up his argument by pointing out that ASP.NET grew within
Microsoft through a process very much like Open Source development,
and summarized, "You put networking in place and you put developers
together, and you get open-source-like behavior, regardless of the
licenses in effect."

Well, that was my second déjà vu.
Counterposing technological environment versus licenses recalled Larry
Lessig's two types of code. The code developed by programmers creates
or restricts opportunities as much as legal code--but legal code is
not obsolete. For instance, digital rights management and the DMCA
mutually support each other.

And free software has not become quite popular enough for us to know
what the effects of different licenses may be. I imagine that a lot of
companies are salivating over Linux. In the absence of the GPL, what
protects it from being embraced and extended? Branding would be a
strong factor predisposing users to choose "real Linux" (branding
protects Apache somewhat from being exploited, even though it has a
loose BSD-style license) but we can't be sure it's enough, especially
with the pressures in embedded system space.

Tim's talk was the start of another long day. With the start of the
keynotes and sessions, OSCon was in full force. Noise and bustle from
the loaded exhibit hall spilled out, and streams of people moved in
every direction. The excitement was contagious. Some other events I
attended included:

  • The

    An Open Source Tool Framework for the Enterprise

    keynote by Paul Buck of IBM, which was a history and promotional talk
    on Eclipse. One strength of Eclipse, which has made Open Source
    history by emerging as an immensely popular IDE, is that it was
    designed to have a small core and offer most features as
    extensions. This provides a framework that the community can easily
    plug into to produce more extensions.

  • Applied Ant

    by Erik Hatcher. He showed the elegant integration between Ant and
    several other environments, such as:

    • Code generation for EJB.

    • XML validation (which permits one to identify invalid XML before
      running the application), XSL transforms, and the retrieval of text
      and attributes from XML files.

    • WSDL integration using Axis.

  • A Guided Tour of the MySQL Source Code

    by Zak Greant and Monty Widenius. Mostly a discussion of how to find
    one's way around the directories and files of code, a subtext of this
    presentation could be titled "Reasonable ways to code a large
    program." Among the very balanced decisions made by the team were:

    • Using C++ for server, but avoiding heavyweight, non-C features such as
      exceptions and the STL.

    • Using virtual layers so that all platform-specific code is hidden in
      low layers. This removes the need for ugly and hard-to-maintain ifdefs.

    • Use a robust source control system. MySQL AB, like the Linux
      developers, uses Bitkeeper, which Zak said is much easier than CVS
      when large numbers of files change at once.

    • Keep an ever-evolving internals document.

    I didn't stay for the whole talk, but I was amazed that after all
    these years each large project is still creating its own string

  • Microsoft Office Files Exposed

    by Simon St.Laurent. The upcoming release of MS Office will use XML as
    its storage format, but it's a rough "1.0 release." Probably none of
    the important details will remain the same by the time Microsoft
    settles down. (And, according to Simon, they figure out what to use it
    for. I suppose allowing free software programmers to extract data from
    Office is not a Microsoft marketing goal.)

  • How to use XML Security Standards in Real World

    by Aleksey Sanin. He explained why the standards are useful (for
    instance, SSL does not let you encrypt arbitrary portions of documents
    or attach multiple signatures from different people), introduced the
    arcane XML Canonicalization, Digital Signature, and Encryption specs,
    summarized some toolkits with actual code examples, and warned about
    basic precautions to take. Surprisingly, many implementations don't do
    such basic things as checking whether the person is signing something
    reasonable or that the right person is offering the right signature
    and is the right source for a key.