[Mono-list] On Mono and Patents ... again

[Jonathan Pryor]

Feeding the troll...

On Wed, 2005-09-28 at 18:00 +0300, Alex Nedelcu wrote:
> OK, I know. It's a cool technology. But it comes from Microsoft.

Are you aware that Microsoft has patents on parts of CSS?  Would you
suggest not using CSS with HTML in the future because of this?

Are you aware that Microsoft contributed to the C and C++ standards, and
has patents on ways to implement optimizing C and C++ compilers?  Would
you suggest not using C and C++ because of this (as opposed to any other
reason to avoid C and C++)?

> The reason why Linux has succeeded was because it's free and because it provides
> great value unmatched by Windows. It's simply superior in many ways.

Value depends on the eye of the beholder, and for a great many people
Windows has the unmatched value, because of all the applications
available for it.

> The reason why OS/2 failed is because it provided a Win32 emulator so why
> programming for OS/2 when you can target both OS/2 and Windows.
> Problem was that Microsoft constantly changed the api and they couldn't keep up.

As Pablo Baena mentioned, OS/2 failed for a number of reasons.  A Win32
emulator wasn't one of them, because OS/2 didn't have one.  OS/2 had
Win16 support.  There is a major difference between Win16 and Win32, and
Win16 support wasn't the death knell for OS/2.  Bad management was.

> Let's start with Miguel's favorite saying:
>      "The software patent problem is not limited to Mono. Software
> patents affect everyone
>       writing software today."
> Yes, that may be true. But you are deliberately violating those
> software patents. 

It's not possible to violate patents you don't know about.  And the only
*concrete*, *actual* patent anyone has mentioned is the one on the .NET
API, which is itself laughable -- it's like trying to patent the
interface to a VCR, which the Supreme Court of the United States found
wasn't copyrightable or patentable.

It'll still likely be passed, because the patent system in the U.S. is
insane, but I doubt Microsoft will use it in a lawsuit.  (Keep in mind
that Australia allowed someone to patent the wheel, so at least the U.S.
isn't the only insane patent office around...)

> It's all in the open, everybody knows it, and you
> picked the best company as a target.
> And yeah, GNOME and Linux in general don't rely neither on WINE nor on
> Samba,

Define "rely."  Both Gnome and KDE have Samba integration in their file
choosers which is an important integration point between Windows and
Linux systems.  Without Samba support, companies would have to choose
between Windows and Linux, and I'd bet that most companies would choose
Windows.  They'd have to, because of the lack of programs for Linux
(unless you know of a good payroll program for enterprise companies).
Or they'd get NFS support for Windows, but I find that less likely.

> and Sun made sure full open source implementations of J2SE 5
> are possible. Google for Apache Harmony and it's reasons ;)

And if you did that you'd see that Sun isn't terribly happy about the
whole Apache Harmony idea, and is ambivalent (and occasionally hostile)
to the idea of an open-source Java implementation.  Yeah, that sounds
like a wonderful company to partner with as well.

At least we know where Microsoft stands, instead of the schizophrenia
shown by Sun...

> The only reply Miguel and Novell have regarding the ECMA/ISO parts is
> this (from their FAQ):
> "Jim Miller at Microsoft has made a statement on the patents covering ISO/ECMA,
> (he is one of the inventors listed in the patent)"
>     - imagine that, wow, he is one of the inventors
> 
> And here's what he says:
> "But Microsoft (and our co-sponsors, Intel and Hewlett-Packard) went
>  further and have agreed that our patents essential to implementing C#
>   and CLI will be available on a "royalty-free and otherwise RAND" basis
>  for this purpose."
> 
> So, please enlighten me how the "will be available" part is any consolation ?
> Do you trust Microsoft ? Do you expect me or anyone else to ?
> How does a promise make up for a legal document ?
> Is this letter even original ? Can you proove it ?

Please look up primissory estoppel.  It's the legal principal that
states if you make a promise, you can be later be held to that promise
even if it wasn't in writing or part of a contract.  Jim Miller is a
Microsoft employee, speaking as a Microsoft employee (not as himself),
stating that all required patents would be available royalty free.
That's a promise, and I have little doubt that if they tried to renege
on that they'd be bitch-slapped by the courts faster than you can say
"Microsoft has a monopoly in desktop operating systems."

> Also from their FAQ:
> "Basically a grant is given to anyone who want to implement those
> components for free and for any purpose."
> What a bunch of bullshit. What proof do you have ?
> To think of it, I can probably even sue you for such lies.

In the U.S., you can sue anyone for any reason.  Period.  It's not
always wonderful, it's not always desirable, but that's truth.  See also
the SCO/IBM lawsuit and anything dealing with Scientology.

That doesn't mean you'd have a case suing anyone, much less Microsoft.

> Even if it doesn't happen ... Windows programmers will not move to
> Linux, it will have the reverse effect actually. I already saw
> colleagues of mine that tried Mono, liked it and now thinking of
> moving from Java to .NET and from Linux to Windows.

You should read the reports of the recent Mono meeting at the recent
Microsoft PDC.  Many Windows developers were interested in Linux
support.  Unless you're so cynical that you believe people would say
anything when deliberately going out of their way to go to a Mono
meeting...

> Why the hell haven't you picked another platform ? Why not Java ?

In case you haven't noticed, Java sucks, isn't Free, cannot be Free, and
cannot be forked (which being Free would allow), and is instead
controlled by a single vendor which shows every sign of being
schizophrenic when it comes to Free Software (Sun).

I don't like Microsoft much, but I'm not sure about Sun either.

ECMA CLI is Free, and can be forked, courtesy of being an ECMA/ISO
standard.  (In the same way that Microsoft was free to "fork" the C++
language for C++/CLI and many other "extensions" they've made.)

As for why Java sucks, it's because of this: *decent* languages consider
themselves to be part of a larger system, integrates with that system
and allow easy use of other code (and allow themselves to be used by
other code).  Java decided to take the path of "all other code is ugly
compared to me," and deliberately tries to make it difficult to
integrate with native OS code, much less to be used by other code.

The ECMA CLI platform, on the other hand, went out of its way to permit
easy integration, such as with Platform Invocation Services.

Plus, ECMA CLI allows access to environment variables.  Java removed
that feature (it wasn't portable enough!).

In short, Java is dysfunctional and prefers a Java-centric view of the
world that many find distasteful. 

> There is also Parrot.

Which isn't complete yet, and may not be for several years.

> If that's not good enough why not inventing
> another Java wanna-be with only slight improvements and call it
> otherwise ? Why not improve on C# without calling it a .NET port ? Why
> not invent something new ?

Please, get out of your extreme world view of "ignoring evil will make
it go away."  It's not true of despots and it's not true of Software.

Reality is this: there are two primary platforms that have a lot of
backing, Java and .NET.  If you're not compatible with them, you're a
backwater platform that will never see wide use in the enterprise.  Sad
but true (Scheme never gets a chance!).  The reason is because companies
like stability, and both Java and .NET have a lot of backing and will
stick around for awhile, making them inviting platforms.  Compare this
to Perl, which while widely used is frequently being replaced by Java
(at least at my company that's the case).

Once you accept that, you have two choices: make something that will be
actually useful to a large community by being compatible with one of
them, or make something that will have a smaller community (but possibly
still successful).

Both GCJ and Mono chose to be compatible with the larger communities,
which is a boon to companies as it enlarges the ecosystem, even if the
companies in charge (Sun and Microsoft) aren't always the nicest ones
around.

Then there's the present and future.  No matter how much you or I may
like it, Windows is here, and will be here for quite some time.    The
future of Windows has already been decided, it will be based on .NET.

Consequently, any company with a brain will want to support Windows.  If
you're going to support Windows, you have basically 3 choices:

1. Write everything on whatever platform Microsoft is pushing this week.
For maximum portability that'll be Win32, but in the future it will need
to be .NET since many future improvements will only be available
on .NET.  So you either target only .NET or you have duplicate code for
each platform you want to support.

This is expensive, and thus not desirable, but will still be common.

2. Use a portable language/environment, and let someone else worry about
the issues.  Java fits this description.  It can be nice, but it means
you're perpetually stuck on a lowest-common-denominator platform and
can't make use of the latest-and-greatest Windows functionality.
Customers may not be happy, especially with the increased program
requirements.  (I speak from experience supporting a Java WebStart
application, and Java WebStart gets more support requests than the Java
program itself.)

3. Take the middle path: write for a platform that is commonly supported
across all of your target operating systems.

Note that this is what C did: you could assume a C compiler and the
standard C library (or something close to it), but each platform had its
own custom features and the onus was on the programmer to support
platform features if desirable.  This allowed "portable" programs
between Mac OS, DOS, and Windows, even if only a small part of the
programs was actually shared across those platforms.

This is what Mono allows: a common language and a common platform, the
ECMA CLI platform, where each implementation (Mono and .NET) provides
platform-specific functionality which you can optionally support (Gtk#,
System.Windows.Forms, Cocoa#...).

This can be cost effective, as you can support the latest-and-greatest
on all your target platforms (if you so desire), without needing to
completely rewrite the entire application.  It's potentially more work,
as writing decently portable code can be tricky, but it's less work than
having completely separate and distinct programs for each platform you'd
like to support.

In short, it's the path of least resistance.  As such, it's financially
a desirable path for companies to follow.

> I will tell you why .... It is easier for Novell to increase it's
> market share this way. After all, it's pretty hard this days to have a
> competition like Red Hat. It's all about the money.

You might want to look into your history better.  Mono was originally
started by Ximian, not Novell.  Novell just bought Ximian, that's all.

> As you saw already, I have good reasons and proofs for my statements
> (it's fucking obvious).

Being "fucking obvious" isn't a good reason or proof.  Proof is
something concrete; you've just made an argument, and flawed one at
that.

> It's your turn. Please provide evidence that the ECMA/ISO parts are
> "royalty free" (legal this time) and dump the non-ECMA stacks and then
> I will bow to you.

1.  We don't need you to bow to us.

2.  Dumping the non-ECMA stacks would increase the costs to all
companies wishing to maintain portability between Mono and .NET.  This
isn't desirable, and would be more likely to drive people away from Mono
instead of toward it.  Which I suppose is your actual purpose...

 - Jon