Seth has raised some valid points
on the patent problem, as it related to Mono.
A big problem with everyone raising potential patent
problems with Mono is not that they are wrong in any way, but
there are a few problems with it:
- Not using Mono in any shape or form is not a blank
waiver against patents. That means that even if you
choose to stick to your beloved C, Python, C++ or anything
else, for any new software you write, you are likely to
infringe on someone else's patents (or even the same ones
that Mono could potentially infringe).
- Patents can be: declared void with prior
art showing that such invention did exist in the past.
Alternatively, you can route around it by using a
different technique than the one described in the patent to
provide the same feature (or something close) to avoid
infringing on a patent.
- Most people have no idea of what a patent is, or how it
works. The actual invention is the claims bit. Not the
introduction, not the summary, not the background, not the
references and not the drawings. They help in making the
claims, but they are not the patent itself. If you want to
play patent-lawyer on Internet, you should at least
familiarize yourself with the process.
Now, it is hard to argue with the nay-sayers about
routing around the patent for two reasons: we do not
know what might be patented and valid (ie, no prior art
can be found or properly articulated) and most importantly for
any given topic we can engage in weeks of discussion on what-if
scenarios.
We do not plan on infringing patents, and if were to
infringe on patent, we will either find prior art that renders
that particular claim invalid, or rewrite the code to work in
a different form. We do not like software patents, but we
will abide by the legal rules.
If you can not think of a different way of running a C#
program than the one that exists today, you are not a very
imaginative/innovative programmer. The worst possible
scenario is not `They will stop distribution forever'. The
worst possible scenario is `They can stop distribution until
we find a workaround'.
And again, remember, the software patents problem is not
limited to the specific instance of Mono. Everything Seth
said applies equally well to every bit of our open source
stack today: do we infringe on a Microsoft patent? Do *you*
know for sure you do not? Have you performed a patent search?
On every possible bit?
Red Hat has chosen to adopt Java (despite the same
potential problems with patents) and has decided that it is in
their interest not to use C#/Mono. Like Red Hat's Seth
states: this is self inflicted damage on their part, and they
will not be able to ship any of our leading edge GPL code
(Simias, iFolder, F-Spot or any of our future development
tools).
Red Hat could either stop whining, and have their
developers work in Mono and use Mono, and help us fight bogus
patents or route around them, or they can keep posting to
their blogs more fear-mongering.
Andy Satori has posted his insight here.
If you are going to reply, I just ask you that you take a
step back, and for every instance of the word `Mono' replace
it with every major open source project today `gnu libc',
`linux kernel', `Open Office', `samba', `x11', `cairo',
`gtk+', `qt', `binutils', `gcc', gnome', `qt', `mozilla', `my
favorite file system', use your imagination.
Does your foe have a patent to it? Or someone that can be
acquired by your foe?
On Stop Energy: my policy
Most people operate in Stop
Energy mode, so I typically ignore them, and keep moving.
A small story I like to tell people: when I started writing
Gnumeric, I was very afraid of one thing: the computational
engine. How do we recalculate the value of cells when a
change happens? How do we make this perform well? How do we
do iterative computations? How do you resolve recursive
references?
All of those problems were fairly scary, and I did not have
an answer to them. I looked at all the source code I could
find for spreadsheets around that time, and none of it did
even a remotely good job: it was all pretty amateur, and none
of it really did anything remotely close to what commercial
software did.
I started work on Gnumeric nonetheless, figuring `When the
time comes, I will face that problem', and spent the next
three months making sure that Gnumeric was visually pleasant,
that it looked like Excel, and that the "feel" was right. I
tried to implement computations trivially during that time in
a couple hour hack and that failed miserably.
By the third month, I decided I would not touch a computer
until I figured out an algorithm for doing these computations,
I took a pencil and a notebook and went to write down the
steps. Surprisingly after a few hours of work I had something
that looked correct.
That same day I implemented the computational engine with
the features I wanted and it just worked!
What I like about this story, is that I could have given up
at any point since there was a large problem ahead of me: a
problem I had no answers to. And I see this with many free
software developers, students and even in normal social
situations: people stop doing things because they see a big
problem ahead of them that they can not possibly conceive
working around. My advise to every young programmer is to
start writing code and delay addressing imaginary problems
until they become real.
I like people who find and propose solutions.
The Mono team (both the community and the Novell employees
working on it) is pretty much such a group: a group solving
problems, and moving forward.
Interview with a soldier
Ran into this
interview this morning. From the Sacramento Bee.
Incidentally, watched For of War this week, McNamara at
some point says `We need to win the hearts and minds of the
Vietnamese people'.
