Inteview with Miguel De Icaza

Talking with the GNOME creator about its origins and purpose.

Miguel De Icaza is the creator of the GNOME desktop environment. Below, Aleksey Dolya interviews Miguel about the process of creating GNOME and what he's up to these days.

Aleksey Dolya: Miguel, could you tell us a little about yourself?

Miguel de Icaza: I currently work for Ximian, a software company that my friend Nat and I started in 1999. Ximian has been an extremely fun adventure, and and we are glad that we did it. I was raised in Mexico, both my parents were scientists (my father a physicist and my mother a biologist). Mexico is a third-world country, so open-source basically was a great educational tool for me. Otherwise, I never would have got access to this high level technology. Also, my support group in Mexico helped me to become a better programmer.

AD: The word de in your surname points to your noble roots, doesn't it?

MdI: Which is a shame in human history. Class differences are wrong.

AD: Could tell us about the idea behind creating GNOME?

B>MdI: We wanted to make Linux succeed on the desktop. It was and is fairly successful as a server platform, and it really shines there. But, we did not want to see free software limited to the server market. We wanted end users to be able to get this system and have the same freedoms and potential that those using Linux for a server operating system were enjoying.

KDE was an inspirational project, but at the time, the Qt toolkit on which KDE was built was a proprietary toolkit. It was a disgrace that everyone in the community had worked so hard to create a fully open-source [desktop] (a legacy to all humanity) that we would give up in the end because of the lack of a free toolkit. So GNOME was started to make sure that we had a fully free system, and it was based on the most advanced C toolkit available at the time: the toolkit built by Peter Mathis and Spencer Kimball for their most excellent GIMP imaging software. Part of the background to create free software, and ensuring that things were fully free, came from my involvement with Linux on the SPARC, which I helped develop. Around that time the x86 was not very fast, and we were running Linux/SPARC, Linux/ALPHA and Linux/SGI. But the downside was that proprietary applications coming out for Linux on the x86 just did not run on our higher end computers. And there was not much that could be done about it, as we did not have the source code.

AD: What tools did you use to create GNOME? How was that process?

MdI: C Compilers, editors, debuggers. The usual: people in the GNOME community built a number of tools for debugging and improving the system, like Owen Taylor's grandiose memprof tool.

AD: How do find today's popularity of GNOME?

MdI: I am very pleased with it.

AD: Could you compare KDE and GNOME? At first glance, they seem different only in interfaces and themes, but the functionality is the same.

MdI: I do not run KDE, so it is hard for me to compare. People tell me that GNOME is faster and uses less memory, but that is just what people report.

AD: GNOME is an industry standard. How did it happen, and why?

MdI: GNOME and another project, called Harmony, in a way made Trolltech revisit the license of Qt. And Qt became free software, but with a twist: the libraries were GPL libraries. Hence, it was possible to create free software with it (under the GPL), but anything else required a commercial license for Qt. Many vendors have a problem with shipping a system that requires a royalty to be paid on a per-developer basis. That is why GNOME is interesting: our libraries for creating applications are royalty-free. Also, I think the GNOME community is fascinating and has created some great software and some great extensions. A big influence on GNOME, I feel, was the artists and people who had a general inclination for computer graphics (coming from The GIMP background), so this made for a pleasant platform. I think that both GNOME and KDE have been able to innovate in many areas. Today, we try to cooperate on some fronts; on other [fronts], we both play catch-up to the latest feature added by the other team.

AD: Do you know Matthias Ettrich, the KDE creator? What kind of relationship do you have with him?

MdI: Yes, I have met him a few times. But, we have not really spoken too much.

AD: Where do you work now, and what are you doing?

MdI: I work at Ximian, but my focus has changed from doing GNOME development to working on a project called Mono. Mono is an open-source implementation of the .NET Framework, a development platform that I really like. A lot of the effort that has gone into Mono has been put there mainly to help GNOME become a better platform--my merging these two worlds. And, those of us working on the project would love to see more Mono-based desktop applications out there.

AD: What are you future plans?

MdI: Mono.

B>AD: Why do you like the .NET Framework? Do you really think that new platform will be useful for UNIX OSes?

MdI: This can be better answered by this old post.

B>AD: Will Mono consist of only the .NET Framework, or you are working on the development tools too?

MdI: Some development tools, but no IDE. We suggest that people who are interested in an IDE use SharpDevelop from Eclipse.

AD: What is your favorite Linux distribution?

MdI: I have no favorite distribution.

Aleksey Dolya is a Russian C/C++ programmer interested in network security and software protection.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Inteview with Miguel De Icaza

Anonymous's picture

Bottom line is, the GNOME Foundation (http://foundation.gnome.org) will decide what kinds of technologies, open standards based or closed (http://www.sun.com/executives/realitycheck/reality-031303.html), be a part of the GNOME Project.

The GNOME Foundation

Anonymous's picture

The foundation and its board have absolutely no say over what technologies GNOME will adopt. The closest it has come to that level of involvement is to query to the status of the release team. Technical decisions are decided using the standard methods of opensource :

1) open discussion (flamefests) on lists or irc.

or

2) Someone going off and writing code sufficently good that others use it.

Please avoid repeating inaccuracies.

Re: The GNOME Foundation

Anonymous's picture

The GNOME Foundation will work to further the goal of the GNOME project: to create a computing platform for use by the general public that is completely free software.

To achieve this goal, the Foundation will coordinate releases of GNOME and determine which projects are part of GNOME. The Foundation will act as an official voice for the GNOME project, providing a means of communication with the press and with commercial and noncommercial organizations interested in GNOME software. The foundation may produce educational materials and documentation to help the public learn about GNOME software. In addition, it may sponsor GNOME-related technical conferences, and represent GNOME at relevant conferences sponsored by others, help create technical standards for the project and promote the use and development of GNOME software.

(http://foundation.gnome.org/charter.html)

Re: Inteview with Miguel De Icaza

Anonymous's picture

"MdI: I do not run KDE, so it is hard for me to compare. People tell me that GNOME is faster and uses less memory, but that is just what people report."

Most of the people I know report KDE to run faster and use less memory than GNOME, probably because most of the people I know do not run GNOME.

Re: Inteview with Miguel De Icaza

Anonymous's picture

Most of the people I know report KDE to run faster and use less memory than GNOME, probably because most of the people I know do not run GNOME.

Funny how they can compare how fast Gnome runs compared to KDE if they don't run it...

Re: Inteview with Miguel De Icaza

Anonymous's picture

I run GNOME for the most part, with an occasional KDE session now and then, and in my estimation they both suck up way to many resources. I've got an older system, but I used to be able to play Quake II on the internet with it, and now it's not fast enough to redraw the desktop without visible delays? Hmm....

The go-mono FAQ does NOT answer the issues

NZheretic's picture

(Reposted to front on request)
Miguel, you continue to point to a FAQ that does not actually answer the issues I have repeatedly raised, read in full...
From the go-mono site FAQ: Patents

Question 125: Could patents be used to completely disable Mono (either submarine patents filed now, or changes made by Microsoft specifically to create patent problems)?No. First, its basic functional capabilities have pre-existed too long to be held up by patents.

BUT what Microsoft has done is patented the operational functionality under, what Microsoft consider their own API. For example United States Patent Application #20030028685, covers .NET APIs that allow actions related to accessing the network, handling XML, and managing data from multiple sources.

The basic components of Mono are technologically equivalent to Sun's Java technology, which has been around for years.

Although there is prior art examples of individual technologies such as the JVM etc, Microsoft patents such as the one mentioned, define and claim the interoperation of the components, in such a way that any re-implementations will be sure to be covered by the patents. Any development from a .NET clone will effectively be tainted because of its origin. There is NO way to work-around the issue, no amount of renaming the API calls or reimplementing the methords used will invalidate the patents.


Mono will also implement multi-language and multi-architecture support, but there are previous technologies such as UCSD p-code and ANDF that also support multiple languages using a common intermediate language. The libraries are similar to other language's libraries, so again, they're too similar to be patentable in large measure.

This is correct, hence the reason for Microsoft patents such as the one mentioned, that define and claim the interoperation of the components using XML etc.

However, if Microsoft does patent some technology, then our plan is to either (1) work around it, (2) chop out patented pieces, (3) find prior art that would render the patent useless. 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.

SCO has recently launched an IP lawsuit against IBM on the most tenuous of evidence and hearsay, based on "tainted" origins of a very small part of the Linux Kernel source, do you really expect Microsoft NOT to do the same, sometime in the near future?

There is also a statement from Jim Miller at Microsoft, one of the inventors listed in the patent: here

Follow the same Thread on the mail list and Derek Ferguson asks

When you say "our patents essential to implementing C# and CLI," though,
aren't you specifically excluding namespaces (such as
System.Windows.Forms) which are not a part of the ECMA CLI specification
but which are being implemented by other organizations, such as Mono and
DotGNU? I think that this is what CNET's article was getting at -- what
is the status of the API's that aren't currently a part of the ECMA
standard, but which *are* a part of the CLR? Did MS, Intel, and HP's
pronouncement apply to these, or are they still left in -- at best --
legal limbo?

to whch
Jim Miller at Microsoft replies

It seems pretty clear and simple to me, but maybe I'm missing something.
Microsoft has a commercial product, the CLR, and we treat it as we do
any commercial product. It is covered by patents, copyrights, trade
secrets, trade marks, whatever the lawyers dream up next.

Hence any commercial products that competes with Microsoft using the .NET API remains at risk.

Then there's a standardization effort that covers a specific pair of
technologies, whose scope is stated and agreed by the appropriate
standards organization. Microsoft participates in many such efforts,
and abides by the IP rules appropriate to those organization. In this
case, we're participating in ECMA and ISO, and following their rules.

So I guess I don't see any "legal limbo." What's standardized is
clearly stated in the Standard itself. If it's standardized, you know
the rules. If it's not standardized, you know the rules. What's
unclear?

To which Rhys Weatherley ask the same question many have asked

There is a "legal limbo", but a subtle one.

The Standard is very minimal, especially in the class library definition (only
300 classes compared with the thousands in the .NET Framework SDK). If
everything outside the Standard is covered by the patent, then anyone who
implements the royalty-free parts will end up with a fairly useless system.

To get a useful system, it is essential to implement more than the Standard
specifies. But then we get into the grey area of "is it really covered by
the patent?" Since the Win32 GUI API has existed for ages, the C# wrapper
for it (System.Windows.Forms) could be argued to be unpatentable as it is a
simple transformation on an existing invention. Similarly with other API's
outside the Standard.

I certainly wouldn't want to be the one to try to make that argument in court,
but it is an argument that could be made. This is the "legal limbo".
Outside the standard, API's have to be analysed on a class by class basis for
patent infringement. Other implementations can try their luck, but we are
taking a big risk.

Microsoft's CEOs have given no "green light" for comercial usage of any .NET API re-implentations. Any implentation outside of the standard will surely taint the whole Mono project.


For Linux desktop use, we only need the ECMA components, and things that we have developed (like Gtk#).

... And also the ablity to comunicate back and forth with clients and peers using SOAP and XML Patents such as United States Patent Application #20020059425 "Distributed computing services platform" which covers the design and inter-operation of .NET based implementations, would also likely be infringed even if you do use Gtk# on the client platform.Miguel you continue to point to a FAQ that does not actually answer the MOST FREQUENTLY ASKED QUESTION! Once again this is not your or the Mono developers fault, Microsoft could solve this fear and ambiguity, by just formally granting MONO and other open sourced projects the right to fully re-implement all of .NET, even the parts not submitted to ISO/EMCA standard. That Microsoft choose not to do so, should leave no-one in doubt of their future intentions.

Re: The go-mono FAQ does NOT answer the issues

Anonymous's picture

The longer Microsoft wait, the tougher it is going to be for them to get rid of Mono (and DotGNU?) - so why are they waiting, if they're that keen on getting rid of it? It's not like they don't know about it.

Why the wait? Ask Microsoft or better yet the DOJ. What risk?

NZheretic's picture

Anonymous wrote: "The longer Microsoft wait, the tougher it is going to be for them to get rid of Mono (and DotGNU?) - so why are they waiting, if they're that keen on getting rid of it? It's not like they don't know about it."
Who knows the Minds of the CEOs at Redmond? But there is enough evidence to provide a very clear estimation...
For a start, Microsoft have still been been in major negotiations with the DOJ over the Antitrust-Remedy Communications Protocol Program, that with the API licensing Client Middleware API documentation, is supposed to open up the Microsoft platform to more competition. It would hardly be a good look for Microsoft to be stomping on the Mono and DotGNU .NET clones for IP infringement when trying to appear more open to competition.Once the above isuse is settled and things have calmed down, Microsoft can use similar licensing terms, which are incompatable with the GPL/LGPL license or Free based implementation to effectivily kill Mono
Secondly, Microsoft salesdroids and advocates in forums have been pointing to Mono whenever the issues of either vendor-lock or platform availability when comparing .NET to Java ( ie John Carroll ).In either case, the problem is that Linux is now a serous theat to Microsoft, both in the server role and to a lesser extent as a desktop platform. Steve Ballmer recently flew half way around the world to stop Linux's adoption in Munich's local govenment. Linux and even Ximan's GNOME is now a serious contender for govenmental and large organization deployment. I can hear the grinding of teeth from Redmond. Will Microsoft wait much longer? Or will Microsoft wait until Mono is intergrated into GNOME and maybe KDE, and then use the same "tainted" argument as SCO is using with IBM? Consider how much money is involved with Microsoft corperation's 80% NET Profit from both it's OS and Application Divisions current desktop Monopoly. To Microsoft's CEOs, it's just business, plain and simple, and we all know how long it take to drag any antitrust issues though the system
The Question then becomes: Should we risk either Linux,GNOME or even KDE's future on being in any way dependent on or tainted by a .NET clone?

Re: Inteview with Miguel De Icaza

Anonymous's picture

We suggest that people who are interested in an IDE use SharpDevelop

SharDevelop only runs on Windows, which I believe is not open-source !

Re: Inteview with Miguel De Icaza

Anonymous's picture

SharpDevelop only runs on windows at the moment because mono is not mature enough to be able to run it (more work needed on class libraries - SWF) but as far as I know work is underway so that version 1.0 will run on both windows and linux

The patent issue.

Anonymous's picture

NZHeretic keeps posting this standard template everytime he sees the word Mono. You would think he would have given up and read the Mono FAQ that addresses his question.

Miguel

The go-mono FAQ does NOT answer the issues

NZheretic's picture

From the go-mono site FAQ: Patents

Question 125: Could patents be used to completely disable Mono (either submarine patents filed now, or changes made by Microsoft specifically to create patent problems)?

No. First, its basic functional capabilities have pre-existed too long to be held up by patents.

BUT what Microsoft has done is patented the operational functionality under, what Microsoft consider their own API. For example United States Patent Application #20030028685, covers .NET APIs that allow actions related to accessing the network, handling XML, and managing data from multiple sources.

The basic components of Mono are technologically equivalent to Sun's Java technology, which has been around for years.

Although there is prior art examples of individual technologies such as the JVM etc, Microsoft patents such as the one mentioned, define and claim the interoperation of the components, in such a way that any re-implementations will be sure to be covered by the patents. Any development from a .NET clone will effectively be tainted because of its origin. There is NO way to work-around the issue, no amount of renaming the API calls or reimplementing the methords used will invalidate the patents.


Mono will also implement multi-language and multi-architecture support, but there are previous technologies such as UCSD p-code and ANDF that also support multiple languages using a common intermediate language. The libraries are similar to other language's libraries, so again, they're too similar to be patentable in large measure.

This is correct, hence the reason for Microsoft patents such as the one mentioned, that define and claim the interoperation of the components using XML etc.

However, if Microsoft does patent some technology, then our plan is to either (1) work around it, (2) chop out patented pieces, (3) find prior art that would render the patent useless. 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.

SCO has recently launched an IP lawsuit against IBM on the most tenuous of evidence and hearsay, based on "tainted" origins of a very small part of the Linux Kernel source, do you really expect Microsoft NOT to do the same, sometime in the near future?

There is also a statement from Jim Miller at Microsoft, one of the inventors listed in the patent: here

Follow the same Thread on the mail list and Derek Ferguson asks

When you say "our patents essential to implementing C# and CLI," though,
aren't you specifically excluding namespaces (such as
System.Windows.Forms) which are not a part of the ECMA CLI specification
but which are being implemented by other organizations, such as Mono and
DotGNU? I think that this is what CNET's article was getting at -- what
is the status of the API's that aren't currently a part of the ECMA
standard, but which *are* a part of the CLR? Did MS, Intel, and HP's
pronouncement apply to these, or are they still left in -- at best --
legal limbo?

to whch
Jim Miller at Microsoft replies

It seems pretty clear and simple to me, but maybe I'm missing something.
Microsoft has a commercial product, the CLR, and we treat it as we do
any commercial product. It is covered by patents, copyrights, trade
secrets, trade marks, whatever the lawyers dream up next.

Hence any commercial products that competes with Microsoft using the .NET API remains at risk.

Then there's a standardization effort that covers a specific pair of
technologies, whose scope is stated and agreed by the appropriate
standards organization. Microsoft participates in many such efforts,
and abides by the IP rules appropriate to those organization. In this
case, we're participating in ECMA and ISO, and following their rules.

So I guess I don't see any "legal limbo." What's standardized is
clearly stated in the Standard itself. If it's standardized, you know
the rules. If it's not standardized, you know the rules. What's
unclear?

To which Rhys Weatherley ask the same question many have asked

There is a "legal limbo", but a subtle one.

The Standard is very minimal, especially in the class library definition (only
300 classes compared with the thousands in the .NET Framework SDK). If
everything outside the Standard is covered by the patent, then anyone who
implements the royalty-free parts will end up with a fairly useless system.

To get a useful system, it is essential to implement more than the Standard
specifies. But then we get into the grey area of "is it really covered by
the patent?" Since the Win32 GUI API has existed for ages, the C# wrapper
for it (System.Windows.Forms) could be argued to be unpatentable as it is a
simple transformation on an existing invention. Similarly with other API's
outside the Standard.

I certainly wouldn't want to be the one to try to make that argument in court,
but it is an argument that could be made. This is the "legal limbo".
Outside the standard, API's have to be analysed on a class by class basis for
patent infringement. Other implementations can try their luck, but we are
taking a big risk.

Microsoft's CEOs have given no "green light" for comercial usage of any .NET API re-implentations. Any implentation outside of the standard will surely taint the whole Mono project.


For Linux desktop use, we only need the ECMA components, and things that we have developed (like Gtk#).

... And also the ablity to comunicate back and forth with clients and peers using SOAP and XML Patents such as United States Patent Application #20020059425 "Distributed computing services platform" which covers the design and inter-operation of .NET based implementations, would also likely be infringed even if you do use Gtk# on the client platform.Miguel you continue to point to a FAQ that does not actually answer the MOST FREQUENTLY ASKED QUESTION! Once again this is not your or the Mono developers fault, Microsoft could solve this fear and ambiguity, by just formally granting MONO and other open sourced projects the right to fully re-implement all of .NET, even the parts not submitted to ISO/EMCA standard. That Microsoft choose not to do so, should leave no-one in doubt of their future intentions.

Re: The go-mono FAQ does NOT answer the issues

Anonymous's picture

And you continue to not read the answer.

Would the patent "completely disable mono"? No, of course not.

Everything covered by the ECMA standard is public, and that is where most of the innovation is.

The value in Mono (which you can read in `www.go-mono.com/rationale.html') came from a number of sources: mostly the ECMA components.

Being compatible with Microsoft is *nice* but not a live or die situation. There are two possible scenarios in case that the patents was enforced:

* We would disable compilation of the pieces that violate a patent in countries where the patent is valid.

* Users would be able to turn it on in countries where the patent is invalid, or if they own a license to the patented technology.

Same that is done witih freetype.

Miguel.

What functionality remaining? Patents Neuter Mono

NZheretic's picture

While everything covered by the ECMA standard is public, the ECMA standard only covers 295 core classes. Any new class implentations or added functionality, even those not a direct clone of Microsoft's .NET classes, that impose upon the functionality of of Microsoft's .NET patents, put the developers and deployers of Mono at risk.Remember, Microsoft is getting the .NET patents, even when there is prior-art, by tying the functionality used to the .NET platform.The US Patent Office is a year behind in it's proccessing of patent applications, new applications such as United States Patent Application 20030028685 covering the .NET API for network and webapplications are just appearing.
Microsoft is also filing patent applications at European Patent Office (EPO)
as well. Even If Mono exludes patented functionality on a regional basis, it will make Mono completely useless as an portable platform.Until Sun opened up it's standards under the new JCP, similar concerns were rightly voiced over open source reimplementations of Java's J2SE,J2ME and J2EE. That is no longer the case, for the new JCP requires that all contributers to Java standards grant royalty-free license for all patents required to implement the standard.

Re: The go-mono FAQ does NOT answer the issues

Anonymous's picture

Hey guys, it's Steve Ballmer!

Hey, fattie!

Dogging Miguel De Icaza with the legality of Mono

NZheretic's picture

Miguel de Icaza, and the other Mono developers still COMPLETELY FAIL to address the issue of the legality of most of the copied .NET Framework.Their efforts in coding are commendable, but they are putting everyone who develops or deploys Mono at SEROUS RISK!

Microsoft could solve this fear and ambiguity, by just formally granting MONO and other open sourced projects the right to fully re-implement all of .NET, even the parts not submitted to ISO/EMCA standard. That Microsoft choose not to do so, should leave no-one in doubt of their future intentions.

Microsoft's CEOs have made it "patently" clear that they intend to restrict competing .Net implementations by cultivating Microsoft's patents. Patents such as United States Patent Application #20020059425 "Distributed computing services platform" which covers the design and inter-operation of .NET based implementations and United States Patent Application #20030028685, covering .NET APIs that allow actions related to accessing the network, handling XML, and managing data from multiple sources.

Mono also implements parts of .NET that have NOT been submitted to ECMA and ISO standards. Those parts of Mono lack even the protection for IP infringement with re-implementation that ISO documentation licensing implies.

Although there is prior art examples of individual technologies such as the JVM etc, Microsoft patents such as the one mentioned, define and claim the interoperation of the components, in such a way that any re-implementations will be sure to be covered by the patents. There is NO way to work-around the issue, no amount of renaming the API calls or reimplementing the methords used will invalidate the patents.

This remains true even for the Microsoft specs submited to standard. Both EMCA and ISO documentation only requires RAND licensing, which does not infer fair or uniform licensing terms.

In comparison, Sun has granted the Apache and all open source developers FULL access to the specs, test kits and granted the full rights to develop competing products under the JSPA . Sun has also fully pened up the Java development standards process under the new Java Community Process (JCP) . Even to the point of granting full open source re-implentations of J2EE such as JBoss the opportunity to license a set of testing tools to see if JBoss software adheres to the Sun-sanctioned Java 2 Enterprise Edition (J2EE) specification.

There those that claim that .NET is open to re-implementation, but until Microsoft make a simliar public legal declaration to Sun's JSPA, any .NET re-implementation represents a pending legal mindfield.

Just sticking your fingers in your ears and yelling "NAR-NAR I can't hear you!", is NO defense.

SCO has recently launched an IP lawsuit against IBM on the most tenuous of evidence and hearsay, based on "tainted" origins of a very small part of the Linux Kernel source, do you really expect Microsoft NOT to do the same, sometime in the near future?
In late 1998, an internal Microsoft stratgegy document about the "opensource threat" leaked out which suggested using software patents alongside with proprietary standards in order to crush competition from free software such as Apache and Linux. In 2000, Microsoft forced a free sofware project to abandon support for its patented video streaming format ASF. In 2001/07, in the midst of an ongoing campaign against free software, Craig Mundie, a leading MS executive challenged opensource companies to keep clear of Microsoft patents or else "Get your money and let's go to court!". In 2002 Steve Ballmer, CEO of Microsoft, declared that Microsoft's new standard DotNet was protected by patents and free implementations would not be allowed. In 2003 Microsoft published patent license terms for CIFS which disallow the use or reimplementation by GPL licensed software. In late 2002, Microsoft began dissuade corproporate customers from introducing GNU/Linux by pointing out that if they use free software nobody would protect them from being sued for patent infringement.
Until Sun opened up it's standards under the new JCP, similar concerns were rightly voiced over open source reimplementations of Java's J2SE,J2ME and J2EE. That is no longer the case, for the new JCP requires that all contributers to Java standards grant royalty-free license for all patents required to implement the standard.

When will Microsoft do the same?

Patents irrelevant to Mono

Anonymous's picture

The patents apply only to networking aspects of .NET, not any of the C# compiler, JIT, CLR or anything else that Mono has done or plans to do. All of that has long histories of prior art. So Mono has no patent problems.

Re: Dogging Miguel De Icaza with the legality of Mono

Anonymous's picture

The fact is that those are United States patent applications. So most of the rest of the world is free from them.

Ximian, on the other hand is a company with its HQ in the USA, which is a problem for them.

So, why don't they move they HQ to this city? Barcelona is beautiful this time of the year...

;-)

Re: Dogging Miguel De Icaza with the legality of Mono

Anonymous's picture

So long as Microsoft can make a buck off of it and thwart their competition, maintaining their hold as a monopolistic software publisher...never.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix