Havoc's Blog

Joining the club promoting the O’Reilly
conference, see my
talk on D‑BUS. Also, rml
stole my title! But I
plan to go listen to him anyway, and perhaps buy him some beers.

D‑BUS development looks like it’s moving again, at least a bit:
Michael Meeks, Jon Trowbridge, Olivier Andrieu, Thomas Leonard and
others on the lists. Also, we’re hoping to assign some of the new Red
Hat guys in this direction. With all this help it might even get done
for GNOME 2.8, could happen if everyone keeps at it.

(This post was originally found at http://log.ometer.com/2004–04.html#13.2)

James
Gosling claims that there’s a patent grant for Java, but he does
not understand the issues fully. Here is what he says:

There has been a big debate about implementation languages in the
Gnome world. It’s been all over the map, but one point of concern has
been a set of formless dreads about the usability of the Java language
specification. We’ve been very clear about this, but it seems like few
have read the spec: if you look in the frontmatter, it contains an
explicit statement that anyone is free to implement the
specification. It goes much farther than most other specification
documents: it actually includes a patent rights grant.

Here
is the Java specification license. I am not a lawyer, but to me
this says that you only get the patent grant if you pass the
compatibility suite. The terms of the GPL used in the existing open
source codebase prohibit this compatibility requirement. If you have
this requirement on your Java implementation, and you link for example
gnome-panel to Java, then the result is not distributable under the
terms of the gnome-panel license. Because gnome-panel has hundreds of
copyright holders, we can’t change the gnome-panel license, even if we
wanted to.

It’s also worth noting that the only working open source
implementation of Java (i.e. Classpath) is partial, and thus would not
pass the compatibility suite. Without a usable open source
implementation, we have a showstopper for using Java in GNOME, because
we can’t use the proprietary implementations. This leaves us having
to wait for a complete implementation before we can start using Java
at all. Surely it would be better if we could use some core subset
immediately, as that would at least go down the Java path instead of
an entirely different direction such as .NET cloning. Classpath does
have full Java compatibility as an explicit goal, they just aren’t
finished yet.

I think a lot of people feel that the open source world is being
unreasonable in insisting on open source for all dependencies. Aside
from the practical issue that we can’t relicense due to the sheer
number of copyright holders, to me this is like saying a company is
unreasonable for insisting on making a profit. It’s simply the premise
of the GNOME organization that we’re building an open source
desktop. That’s the whole point of the undertaking; otherwise we’d use
Windows or Mac or BeOS. If you don’t stick to the premise of the
organization, you don’t have a reason to exist; in this case we’d
simply become what we’re trying to replace.

For GNOME specifically, the project was founded as an
alternative to KDE back when Qt was proprietary — a situation
exactly analagous to a dependency on proprietary Java. So it
would be exceptionally strange if we added a proprietary dependency
after founding a project specifically to avoid having proprietary
dependencies!

Of course, you could say that compatibility is the same sort of
founding principle with respect to Java, and perhaps it’s equally out
of the question for Java to add extra risk of incompatibility. But
perhaps there are creative solutions, or ways to make that risk
inconsequential.

I’d be interested in the arguments for and against Sun enforcing
compatibility via trademarks, rather than licenses and patents. That’s
how Red Hat Enterprise Linux works and it works very well. Overall I
think it would be fascinating to be inside Sun and be able to fully
understand all the issues surrounding Java licensing.

In the meantime though, to me it looks increasingly like we need to go
down the road of Python, XPCOM/UNO, GObject introspection, and other
half measures; hopefully stay out of the .NET clone trap; and maybe in
time create an open alternative to .NET and Java both. It’s a shame
however, because Linux and Java are natural allies that could both be
more successful in combination.

(This post was originally found at http://log.ometer.com/2004–04.html#13)

Of course I have to agree with Luis
that sticking as close to trunk as possible is best — that’s one of
the big reasons we switched to the 6‑month time-based releases, to
keep “what the developers are working on” and “what users are using”
as in-sync is possible.

If you want to see wasted effort, have a look at the enormous
backport-fest in the vendor kernels… the kernel project is really
pretty broken in this respect. With GNOME, even if people ship 2.6
rather than 2.8 it’s not that bad. Or not as bad as the GNOME
1.4 days when we spent a year trying to get people to stop piling
patches on 1.4 and finish 2.0. 😉

I think the main reason much of XD2 didn’t make it upstream was that
it was done behind closed doors without buy-in and much of it was done
in a pretty hacky way (for understandable reasons). If we instead take
the approach of first making the change in 2.8 in an
upstream-acceptable way and then backporting to 2.6, then we know
stuff won’t be lost.

It’s a little bit dangerous to have people planning to ship 2.8 when
2.8 is released well into the OS freeze cycle; what happens is that if
2.8 is for any reason delayed, you can’t back down to 2.6 during a
freeze, and you would be forced to ship a 2.7 beta (or put a big
unexpected delay late in the OS release cycle, which may not be an
option in a still server-driven world). GNOME is safer than any other
project I know of to do this with, but it’s still a little scary.

This whole discussion may be opaque to others: context is, Luis and I
were discussing earlier whether to base the next OS releases on 2.6 or
2.8. Red Hat hasn’t really decided yet.

BTW, I agree 100% that the foundation should hire people to do admin
work; it just pains me to see Jonathan and Owen spending a bunch of
time on that. Hiring developers is different.

(This post was originally found at http://log.ometer.com/2004–04.html#9)

Four new desktop developers joined Red Hat in the last week; keeping
me busy.

One of the slides at my linux.conf.au
talk on the desktop was Commercial Involvement Will Grow, and I
had these bullet points:

• Companies have contributed relatively little to the desktop so far; perhaps a tenth of what’s been contributed on the server
• This will raise organizational and political challenges for the
  developer community
• We have to keep projects healthy, friendly, and unfragmented
• At the same time, more developers (often) get more done

The issue comes up all the time, here are some examples large and small:

• The X excitement: XFree86 left with
  little support, corporate-looking X.org site, commercial (and
  Debian) love-in for X.org and David
  Dawes comments
• The Mono and Java debate is heavily tied up with commercial
  interests (and even more so now that Sun and Microsoft
  are
  perhaps allies?)
• Luis’s
  comments on interaction design at companies
• Benjamin
  Otte on commercial interests in GNOME
• 
  JBoss guy wants to “own” open source projects, pretty weird

Just a sampling. It’s not new to have this issue; many of us “old
timers” are still battle-scarred from the days when Eazel and Ximian
first appeared, and the GNOME Foundation
was largely motivated by the desire to control and limit commercial
interests.

There aren’t any easy answers. No matter what organizational structure
you build, companies have a couple of inherent power advantages over
independent developers.

• Nearly all users obtain the software from a company; if you lose
  the companies your userbase looks like this.
• Companies have a block of developers moving in a single direction, so
  as long as the changes meet the criteria to go upstream, that
  direction tends to have a lot of pull (on the “show me the code”
  principle that makes open source go).

Companies in turn though are in large part required to follow
customer, partner, and legal requirements, and are not free to do
anything they choose to do. Sometimes the people most actively against
company-advocated directions are those who are happy with a
UNIX-geeks-only sort of project and dislike moving in directions with
broader appeal.

Because the GNOME
Mission Statement defines the project goal to create a
platform “for the general public,” working with companies to find out
what customers want, get wide distribution, and offer support becomes
more or less essential. But “working with” should be on the right
terms, in a way that preserves the nature of the project.

Honestly I think GNOME has the commercial relationship more right than
the vast majority of open source projects. One thing that tends to
happen though, and also happens in the kernel world, is that
independent contributors are regularly hired by companies. I’m hoping
that as GNOME grows the number of companies doing hiring like
this will grow as well, as it has for kernel. Because companies tend
to disagree with each other, this reduces the influence of each one.

A model I’m not a fan of is the Mozilla Foundation or old-style X
Window System model, where a nonprofit organization employs
developers. To me it’s better to have companies employ people
directly, because it’s more transparent where the influence is coming
from, and as corporate interests become irrelevant their influence
naturally disappears. Companies are also more directly responsible to
customers, which is generally a good thing for the software, with the
occasional exception of customers with out-there special-case demands.

One thing that helps avoid conflict is to clearly state the goals of a
project, so that everyone involved knows it up front. It’s tough for
incompatible “visions” to exist in a single project; for example,
GNOME had a lot of growing pains deciding that a project goal was
usability for regular people. Very often a “companies vs. volunteers”
conflict is really a “what is the project about” conflict. If you have
some goals up front, nobody can complain about them later.

Luis’s
post gets at one of the most important priorities: to be sure
discussions of project direction are public. Including both small and
large issues. So I hope we’ll be able to do interaction design “in the
open.” The Mono/Java argument is a real mess in this respect — we
discussed it some in public, but it turns out all the relevant facts
aren’t public. :-/ What one does at that point I don’t know.

I suppose this log entry has no conclusion, I was just thinking about
the topic. I do hope GNOME’s results speak for themselves in many
ways, showing that we do at least some things right.

(This post was originally found at http://log.ometer.com/2004–04.html#8)

More
text on how usability will never happen in free software.

That article is spot-on when it talks about how usability is more than
adding some easy config tools on top of an existing system. I also
love the accurate point that technical users don’t like the broken bits
either.

But after two years I continue to
believe that the causes of poor free software design are not
intrinsic to the license.

Serious commercial support for the desktop is just starting up, in
about the same place commercial support for the server was 3–4 years
ago. Though we may expect the desktop to ramp up more quickly, primed
by the server.

At Red Hat, we’re building the desktop team around a top-down
design-first approach, driven by professional interaction
designers. We’ll see how it works out. It will take some time before
the first results are visible.

(This post was originally found at http://log.ometer.com/2004–04.html#2)

Bad Bush.

Gave a short talk about the desktop at the Red Hat World Tour event
near MIT yesterday; lots of people showed up for the talks, including
Richard Stallman.

(This post was originally found at http://log.ometer.com/2004–03.html#30)

Since people are asking about the AFL again,
here is the story. The idea of the license is to be an X/BSD-type
license written in proper best-practice legalese (see below). There’s
a patent clause right now that was well-intentioned but kind of
broken; a revision to address the patent concern is supposed to be in
the works, and we’re waiting for the new version to relicense D‑BUS
under it.

Here is some explanatory text that once came with the license, it’s in
dbus/COPYING also:

The following is intended to describe the essential differences
between the Academic Free License (AFL) version 1.0 and other open
source licenses:
The Academic Free License is similar to the BSD, MIT, UoI/NCSA and Apache
licenses in many respects but it is intended to solve a few problems with
those licenses.
* The AFL is written so as to make it clear what software is being
licensed (by the inclusion of a statement following the copyright notice
in the software). This way, the license functions better than a template
license. The BSD, MIT and UoI/NCSA licenses apply to unidentified software.
* The AFL contains a complete copyright grant to the software. The BSD
and Apache licenses are vague and incomplete in that respect.
* The AFL contains a complete patent grant to the software. The BSD, MIT,
UoI/NCSA and Apache licenses rely on an implied patent license and contain
no explicit patent grant.
* The AFL makes it clear that no trademark rights are granted to the
licensor's trademarks. The Apache license contains such a provision, but the
BSD, MIT and UoI/NCSA licenses do not.
* The AFL includes the warranty by the licensor that it either owns the
copyright or that it is distributing the software under a license. None of
the other licenses contain that warranty. All other warranties are disclaimed,
as is the case for the other licenses.
* The AFL is itself copyrighted (with the right granted to copy and distribute
without modification). This ensures that the owner of the copyright to the
license will control changes. The Apache license contains a copyright notice,
but the BSD, MIT and UoI/NCSA licenses do not.

(This post was originally found at http://log.ometer.com/2004–03.html#26)

Been getting more and more email on the subject of Java, Mono, C++,
etc.; not clear I can ever reply to all the points raised 😉 I still
don’t think anyone has addressed my #1 worry however, as I tried to
point out in my last blog post: forking and fragmentation are the
outcome if current trends continue. Debating which course of
action is better in an absolute sense is pretty pointless unless that
debate results in a direction with sufficiently broad support.

Put very bluntly, do we think Sun will ship a desktop with Mono no
matter how long we discuss and advocate it? Though less clear-cut, do
we think IBM (for example) will? Or from the other side, do you think
GNOME or Mozilla or for that matter Red Hat or Debian will accept a
proprietary JDK dependency, no matter how long it’s discussed? I just
don’t see these positions changing. And if we then push on without
consensus, we are going to have a hell of a fiasco — at least if you
judge our success in part by how many users we have.

The Linux desktop has maybe 2% marketshare; it’s not time yet to start
shedding allies.

Here’s a question: would we rather wait indefinitely to get
consensus and legal clarity on the most controversial courses of
action, or go ahead and move forward on a compromise course of
action? Are we looking to ensure the perfect solution with
indefinite delay, or can we find a 90%-as-good solution we can use
right away?

Some quick summary thoughts on technical and legal issues, though
again as I keep repeating, we have a higher-order problem that
rightness-in-absolute-terms matters nothing without real-life
consensus.

Technical: I agree that C# has some incremental improvements
over Java. But the two systems are essentially similar, and when you
compare them to C instead of to each other, they look much more alike
than different. Cross-language in Java can certainly be done (cf. Jython for example) and can be
improved with existing technology such as CNI or UNO. There’s no
reason it’s hard to do a P/Invoke equivalent for Java, either.
This stuff could even go in the Java spec eventually.

Legal: This topic is huge, but a quick thought I have had. We’re
talking as if Mono and Java have entirely distinct sets of patents
that apply to them; but the technologies are quite similar. It’s
possible (though I’m speculating) that the patents overlap
heavily. (Though the overlap isn’t quite symmetrical, since Java
predates C#.) And for that matter many large companies probably happen
to have patents that apply. At some point Stick with C/C++
looks pretty attractive.

Another angle on the law: a problem with legal issues is that none of
us are lawyers, and generally it’s not possible to post or republish
legal advice if we receive it. Because the legal matters are a
complex risk analysis, not black and white, to me what it comes down
to is whether those who have something to lose, and have gotten legal
advice, are willing to ship a particular piece of software.

As a number of mails I’ve received argue, we should remember that
sticking with C++ or Python or the like is an option. We don’t
have to buy into anything more — and may be unable to,
because legal experts will have final say.

At the same time, what really interests me is the possibility of
getting enough consensus today to start using a managed
language. Right now the community seems to be in “wait and see” mode
while companies are in multiple, incompatible “full speed ahead”
modes.

(This post was originally found at http://log.ometer.com/2004–03.html#21.5)

I’m trying to imagine the target demographic for this
product.

(This post was originally found at http://log.ometer.com/2004–03.html#21.4)

Miguel summarizes my argument as “we need to pick Java to avoid
fragmentation,” I’d put it more generally “we need to pick a viable
compromise,” again my attempt to summarize options people have brought
up:

• Stick to C/C++ for the forseeable future; possibly enhanced
  by UNO or XPCOM or equivalent.
• Build a third language and platform set based on Parrot, Perl, Python, and other
  open source technologies.
• Open source Java subset as I proposed.
• C# plus GNU Classpath — Java platform with C#/Mono
  syntax/VM.
• C# plus third platform — C#/Mono syntax/VM plus a new open
  source platform.
• C# and IKVM — choice of syntax, running on Mono, with
  either GNU Classpath or a new open source platform.

Why do we “need to pick”? Because until we pick something we are
picking Stick to C/C++ by default, but not really acknowledging
it; and so in fact have been holding off on technologies such as UNO
and XPCOM that could improve C/C++ on the grounds that we might in
principle move to a managed language instead. If Java and Mono are
clearly not going to get consensus, let’s seriously consider PyGTK and
XPCOM.

i.e. right now we’re just waiting indefinitely for I’m not sure what -
is there something we can go ahead and do?

Regarding cross-platform development: I think we need an open source
abstraction layer. Using Microsoft APIs directly isn’t the way to do
this. Longhorn does not force you to write the entire app in
C#, it forces you to invoke the CLR-based APIs at some level; which
can be done indirectly, in the “Windows backend” of a portable
platform.

(This post was originally found at http://log.ometer.com/2004–03.html#21.3)