Sun Responds — Gently — to Novell’s OpenOffice.org FUD

krisum, From the Mono website:

"For people who need full compatibility with the Windows platform, Mono's strategy for dealing with any potential issues that might arise with ASP.NET, ADO.NET or Windows.Forms is: (1) work around the patent by using a different implementation technique that retains the API, but changes the mechanism; if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless. "

I might as well add a couple more points. (4) MS would never sue us, and you, because Novell and MS are best friends forever now (5) even if they do sue, we have lawers too!

Further more, "Not providing a patented capability would weaken the interoperability, but it would still provide the free software / open source software community with good development tools, which is the primary reason for developing Mono."

Trying my best John Cleese (Fawlty Towers) impression. So, all this time I was under the impression that Mono is going to be .Net compatible, but I was wrong. The primary reason for Mono it seems is just providing a good development tool, and if some extortion money can be had in the process, so much the better. After all, why buy red Hat when you can buy protection from MS if you buy from Novell. Ah, I see it now.

KS, You didn't blow anything out of the water. A VM is not a processor. It is an abstraction over specific hardware so developers don't need to worry about low level stuff. The keyword is abstraction, as in, it still talks to the hardware and is aware of system level/OS specific stuff. Nothing is automagic.

I don't doubt for a minute that Mono cannot run *some* .Net code. It can do so by providing a wrapper around the .Net code and by using e.g. GTK bindings. But this is not going to be 100% compatible.

For example, MS owns the patent for the ribbon component (not a part of .Net, but it can run in the .Net VM). And you have to license it from them. The terms and conditions are a 120 page document. Even the terms are confidential so you have to agree to another evaluation agreement before you can even see the terms. The catch, as stated by MS, you cannot use it to build a product that directly competes with a MS product. My point being, everything that touches MS technology is a legal minefield and the terms are not clear.

The .Net VM can run the ribbon component. Can Mono? If this is integrated into Evolution, which competes with Outlook, how is the licensing going to be handeled?

How can audio/video files be played in a Mono app? You cannot play most popular formats legally in Linux. How is licensing going to be handled for that? If I get Mono from any other source than Novell, am I covered in Novell's patent agreement? How about fonts?

The question still remains, is Mono .Net compatible? If not, then the Mono project is being disingenuous.

Quoting:Shame on you for saying not much of an issue on the server. In serverland, that's a great big "it depends"

Quoting:I suppose the same could be said about the desktop if you're doing games, but... I don't think that's really .Net's space.

It's all a great big "it depends". Because.

Quoting:Using the right platform is what matters.

The .NET/Mono framework like Java is a general purpose programming language/framework. They are both pretty efficient these days, but obviously not as efficiant as C/C++.

KernelShepard, yes I'm a programmer, been one since the early 80s.

Quoting:Why would there need to be wrappers around the Linux libraries if you're porting to Linux?

Because then I'd have to write the wrappers, and that's exactly the problem I face now. It's called code reuse, the whole point of OO, GTK# is basically a wrapper, or an interface to the GTK framework, it provides a means of invoking those classes, there's a hell of a lot of code in Mono that simply uses pInvoke to call an existing C/C++ library, rather like WINE does.

Quoting:Why lard up Linux with yet one more boggy interpreted environment?

.NET/Mono isn't an interpreted environment. It's a compiled environment, mostly it's compiled to something similar to Java's Byte Code, it can be compiled to full binary, but it's a trade off, by keeping it compiled to byte code the JIT compiler can provide other efficiencies, like Just in time code, where only the code needed for the execution path is loaded into memory.

If you object to interpreted code, you probably want to worry more about Python, Perl, PHP, Ruby, because even GAMBAS (Basic) is compiled not interpreted.

Lets face it, it's what Dino says, .NET is Microsoft, Mono re implements it for Linux/Unix etc, people hate it on principle, then try to find reasons why they should.

Quoting:You didn't blow anything out of the water. A VM is not a processor. It is an abstraction over specific hardware so developers don't need to worry about low level stuff. The keyword is abstraction, as in, it still talks to the hardware and is aware of system level/OS specific stuff. Nothing is automagic.

Please show me where I made said any of that? You made the assertion that a .NET VM had to be aware of Windows.Forms and ADO.NET (the "patented portions of .NET"), this is simply untrue and is obvious to any entry-level programmer. The Windows.Forms and ADO.NET portions of .NET are class libraries, simply building blocks to make writing applications easier. Just like gcc or the Linux kernel do not depend on Gtk+, nor does a .NET VM depend on Windows.Forms.

Quoting:I don't doubt for a minute that Mono cannot run *some* .Net code. It can do so by providing a wrapper around the .Net code and by using e.g. GTK bindings. But this is not going to be 100% compatible.

AFAICT, the Mono project's VM can handle all of the .NET bytecodes. As long as the library calls being called by the program being run are implemented (correctly), then the program will work.

Your second sentence makes no sense, so here's what I /think/ you mean (if not, please explain):

Quoting:It can do so by providing a wrapper around the .Net code

Presumably you mean to say that Mono class libraries can wrap native libraries. Yes, this is true. No doubt that Mono implements file I/O by wrapping calls to open(), read(), and write(). Gtk# wraps Gtk+. However, from what I'm told, most of the Mono class libraries are written in managed code and are not wrappers for native libraries.

Quoting:and by using e.g. GTK bindings. But this is not going to be 100% compatible.

You seem to be trying to infer that Windows.Forms wraps Gtk+? AFAICT, this is not the case.

Also, it is not necessary to write .NET applications using Windows.Forms, you can use Gtk# even in Windows.

Mono's Windows.Forms is no doubt not 100% compatible with Microsoft's, but I don't see anyone writing Windows.Forms applications specifically for Linux. Do you?

Advice: stop smashing your head into a brick wall with the Windows.Forms argument, you accomplish nothing except to show that you have no logical argument.

Quoting:For example, MS owns the patent for the ribbon component (not a part of .Net, but it can run in the .Net VM). And you have to license it from them. The terms and conditions are a 120 page document. Even the terms are confidential so you have to agree to another evaluation agreement before you can even see the terms. The catch, as stated by MS, you cannot use it to build a product that directly competes with a MS product.

As you said, Ribbon is not a part of .NET, so it's not necessary for Mono to implement their own Ribbon classes to be compatible. If you choose to use the Ribbon, your program might not run on Linux. It's just something a developer would have to take into consideration.

Quoting:My point being, everything that touches MS technology is a legal minefield and the terms are not clear.

All you proved is that implementing the Ribbon on Linux might be a "legal mine field", you didn't prove that anything else is.

Quoting:The .Net VM can run the ribbon component. Can Mono?

I would suspect that on Windows, the Mono VM could likely run .NET applications using the ribbon. On Linux, probably not.

Quoting:If this is integrated into Evolution, which competes with Outlook, how is the licensing going to be handeled?

How would I know? Is there even any talk of this happening? Or is this just another "what if" to spread FUD?

Quoting:How can audio/video files be played in a Mono app?

Banshee seems to play audio and video on Linux just fine. I think it uses GStreamer.

Quoting:You cannot play most popular formats legally in Linux.

You can if you have a license. That's what Fluendo is for (they provide licenses and codecs for the popular media formats via GStreamer plugins).

Quoting:How is licensing going to be handled for that?

Same as it is now? There's also the possibility for Novell, Canonical, Red Hat, etc to purchase the licenses for the users of their distributions. They'd have to purchase the "infinite # of users" amount, which is very expensive, but it's a possible way for it to be handled.

Another option is for the application developers to just use OGG. AFAIK, a lot of video games use OGG these days instead of MP3 because they don't have to pay a license.

Quoting:If I get Mono from any other source than Novell, am I covered in Novell's patent agreement?

As long as you stick to the ECMA/ISO specified portions of .NET, you don't need to be covered by Novell's patent agreement.

Quoting:How about fonts?

There are a lot of free truetype fonts out there. Why do you care about having Microsoft's?

AFAIK, Microsoft has provided their fonts for public use anyway, you are free to download the fonts from them -- you just can't redistribute them.

If your applications requires their fonts (why would it? makes no sense), then you could have a help screen that told users where to get them.

Quoting:The question still remains, is Mono .Net compatible? If not, then the Mono project is being disingenuous.

Yes, Mono is .NET compatible. Does it implement all of the libraries Microsoft have added on to .NET? No.

Why is the Mono project being disingenuous here? They publicly state that they do not implement all of the .NET libraries out there. They seem to only really care about the ECMA/ISO standardized libraries + whatever else they can easily do (/whatever customers request?).