Re:Real-world examples of tangible benefits
on
Mono Beta 2 Released
·
· Score: 1
Any plans for KDE integration, ie QT#? (whether by you, or an entirely seperate project)
There is a Qt# project, which can be used with either DotGNU or Mono.
Independent of that, in the DotGNU project, there is work underway to create a "KDE theme" for DotGNU's System.Windows.Forms.
I'm not aware of any work in Mono that is specifically designed to support KDE integration, and I'd be surprised if there was, since one of the original stated goals of the Mono project was to "help GNOME".
"This invention relates generally to computer systems, and more particularly to increasing the functionality of application buttons on a limited resource computing device."
That sentence which you quote isn't part of the "claims" of the patent. It's part of the "description" which is supposed to fulfil the function of teaching the invention. (Patents are supposed to be granted only for non-obvious inventions. The original idea of patents was to give inventors an incentive to teach the public about their inventions instead of keeping them secret. The incentive is the chance of getting a monopoly for a limited time and/or patent royalties. These patent rights are granted to the inventor in exchange for the inventor giving up the secret knowledge of the invention and making it known to the public through the "description" in the patent text. Of course, in the area of software patents, I haven't yet seen a single example where the disclosure in the "description" isn't totally worthless because it's impossible to make use of the idea and keep it secret at the same time.)
The "description" part of the patent text, and especially the introductory sentence which you quote, are irrelevant for determining the scope of the patent. For that, you have to read the claims.
Hmm... each of the claims in the patent as it was actually granted refers (explicitly or implicitly) specifically to "limited resource computing devices".
Hence general-purpose PCs and bigger embedded systems are safe from this, but small devices such as handhelds are vulnerable?
One of the things that MS promised with.NET was that it would do first-runtime compiling to native machine code optimized to each individual machine.
It would be nice if the open source community could take Mono and optimize for various chips and cards.
Mono's current codebase isn't very suitable for that. However, if you're interested in this kind of thing, have a look at the DotGNU project, specifically libjit.
If he's so scared, why not just start the.XOMOL project and create XAML for Linux?
Actually a good project in this area exists already, the MyXaml project.
From the DotGNU perspective, XAML isn't particularly scary. We can simply support and recommend (and perhaps distribute) MyXaml.
Really, from the perspective of the Free Software community, XAML isn't particularly scary. XAML may make the deployment of apps easier, and some of those apps may have been written to run only on MS platforms, but that cannot possibly be worse than the current situation with most apps for desktop computers running only on MS platforms. If indeed the IT world switches to XAML, that's not something to be scared about (except perhaps from a security perspective) because supporting XAML+.NET on free operating systems is in fact easier than supporting native "Microsoft Windows" executables.
So I come to the conclusion that while I don't know whether XAML may perhaps be scary for Novell from a business perpective, or it may be scary for Miguel personally (because the MyXaml project is independent of Mono, and Miguel has historically found it difficult to interact with independent projects in a contructive, mutually beneficial manner), but certainly XAML is not a big threat for anything that I particularly care about.
the Australian Record Industry Association yesterday released sales figures
for 2003 showing an increase of nearly 8 per cent
Is there any reason to think that this trend might be specific to the
Australian music industry (for example because P2P music sharing could
help with making making Australian music more well-known internationally),
or is it reasonable to take this as an indication that P2P music sharing
does not really undermine the commercial viability of the recording industry,
worldwide?
I'm not sure what that phrase means other than being marketing fluff.
Hmmm... I'd define "world without information boundaries" as "a world in which no-one has an economic incentive to deny you access to any information that would be useful to you for some legitimate purpose".
This doesn't rule out securing computer systems against crackers, and it doesn't rule out using cryptography for protecting the privacy of truly personal matters.
However I'd say that business practices of selling a GNU/Linux distro which contains demo versions (and no full-featured versions) of some programs are clearly in violation of this "world without information boundaries" vision. Shipping any programs without making the source code available is even worse.
Novell's vision of one Net -- a world without information boundaries
I wonder whether corporations as big as Novell can survive in a "world without
information boundaries". I'd expect that in such a world, networks of smaller
(much more nible) companies will rule.
Is there anyone keeping scores on how near each effort is to provide some real portability, especially for database apps and systems programming tools?
Alas, no. Of course this would need to be done by someone who is reasonably objective (in particular not someone who is emotionally attached to either project), but if done well such comparitive reports would certainly be valuable not only to users but also to both projects.
Growth in creative industries such as radio, television, movies, publishing, music -- and, yes, software -- is threatened when "a few powerful interests control how culture develops."
Hence, if we in the so-called "developed nations" don't fix our legal systems,
third-world countries, where "intellectual property law" cannot be enforced for
lack of a functional legal system, will become the leaders in creative
industries, including IT, right?
implementations of a PostgreSQL adaptor and ASP.Net. Will DotGNU Portable.Net support such a port in, say, one or two years from now?
Yes, definately.
That said, in the middle of FUD that post has some interesting claims, like impractible goals of DotGNU
I'm not sure what you mean with "impractible goals of DotGNU". Fundamentally I'd say that there are two types of goals: "essential goals" and "dreams". With an "essentail goal" I mean a goal which is essential for making the project a success; if we don't reach that goal, the project hasn't been fully successful. For DotGNU, "making it easy to port apps that were written for.NET so that they become truly portable with DotGNU Portable.NET" is an "essential goal" in this sense. With "dreams" on the other hand I mean the type of goal that would be great to achieve, but where it's not really essential to achieve it. I have lots of DotGNU-related dreams, probably most of them will never get realised, but some will, and I think there's nothing wrong with that.
Maybe you mean Miguel's statement "the DotGNU team wanted to invent a new virtual machine that supported Java and.NET at the same time"? That dream is not as impractible as it might appear at first.
Read this. We do have a working runtime for IL which has been designed in such a way that there no serious obstacles (besides lack of volunteers) against adding support for JVM bytecode into this same runtime engine. Miguel criticises the JVM bytecode support as "slow, untested, and very broken"; I'm not interested in debating these claims. This JVM bytecode support is not something that we publicise as a feature; rather it's a proof of concept showing that with pnet's design it is possible to implement this, and an invitation to anyone who is interested in JVM-IL interop to come on board and work out the details.
reading Rotor code
Miguel's statement "Pnet follows a different approach: read Rotor, and do a new implementation of it" is mostly FUD. The truth of the matter is that Rhys has asked Eben Moglen, who is the General Counsel of the Free Software Foundation (and also the author of the GNU GPL and LGPL) for legal advice concering the question of whether looking at Rotor code is ok, and received the following response (posted with a bit more context in the pnet FAQ):
My advice is to tell people to code where possible from the ECMA standard. Where (which is likely to be everywhere), ECMA is insufficiently descriptive to create interoperable code, it is acceptable to read the source of the Rotor implementation. Notes taken in the course of reading that source should be made in pseudocode, so that programmers do not copy snippets of the Rotor source as aides to their memory. We want every line of code in our projects to have come out of the original invention of one of our coders, having been expressed in his or her own way. Ideas abstracted from the Rotor implementation should always have been put in our programmer's own "words," because copyright protects expressions, not ideas.
It turns out most S.W.F client code relies too much on poking around "behind the scenes" way of pinvoke badness and the like that there needs to be a real Win32 implementation behind it.
This isn't true. The implementation of DotGNU Portable.NET proves that it can be implemented directly on top of X, without any need for Wine or winelib.
are there insurmountable technical barriers that would prevent compiling both Java and C# to the same bytecode?
No there aren't. DotGNU Portable.NET has a Java compiler front-end to the cscc compiler which you normally use to compile C# to IL. This Java compiler isn't currently useful (you'll need to port at least the basic class library before you can really use it) and not going forward (because the programmer who worked on it while still a student now has a job that keeps him pretty busy) but it's certainly a good starting point for anyone who wants to work on this.
Also there are no insurmountable technical barriers against the following, more tricky objectives:
Compiling both Java and C# to JVM bytecode, or to Parrot bytecode.
Executing both IL and JVM bytecode in the same VM.
These kinds of things aren't currently in active development, but it has been taken into account already during the design of the Portable.NET compiler system and run-time engine that one may eventually want to do such things.
Here are two clear examples of hostility coming directly from Mono project leader Miguel de Icaza:
This slashdot posting is one of several instances in which Miguel has publicly spread FUD against Portable.Net, attempting to cast a shadow of legal doubt on that project because it was started before the ECMA specs were published. According to our lawyer (Eben Moglen) what was done back then was perfectly legal, but even if that wouldn't be the case, it wouldn't matter because all the old code from back then has long been removed from the codebase anyway. These matters have been explained to Miguel, but in spite of that he has continued to spread this FUD. I think this is totally unacceptable. He also calls me and the other DotGNU coreteam members "kids", and makes other false statements that however are not so significant, hence I won't discuss them in detail.
In response to my last proposal of collaboration, Miguel first said he's interested but when I shared some more thoughts, he responded by attacking me, calling my view "intellectual dishonesty" and "an exercise in deception". Of course Miguel is free to have his own opinions, and Mono is free to respond with "no" to proposals of collaboration, but he could have said "no" without attacking me like that.
Suppose that one day Microsoft starts making SCO-like attacks against DotGNU and Mono. Miguel is well aware that this is a possibility, and here he has stated that "if Microsoft in fact owns patents to the technology and they require the licensing of those, we are willing to license those for the sake of our users and customers." Since this statement was made in the context of discussing the threat from the possibility of patents that MS may not be willing to license royalty-free to everyone, such buying of licenses (while compatible with the X11-style licensing that Mono is using for the affected code) would change the status of the affected code from being Free Software to it being source-available, "paid Microsoft license required" non-free software. (Novell would buy a license that allows them to distribute the code, but which probably wouldn't give others the right to distribute derivative works, hence the code would stop being Free Software). However we in the DotGNU project would not accept Microsoft's demands for patent royalties, even if that means that until the patents in question have been invalidated by a US court of law we can distribute some code only from ftp servers outside the US. In view of these different planned reactions to any demands for licensing royalties it seems quite possible that Novell would agree to make Mono non-free (probably still free as in beer, but no longer free as in freedom), while we'd have to fight the legal battle against MS without their help. In view of this possibility, I consider remarks from Miguel like those quoted above which attack the DotGNU project's legal position to be extremely hostile.
I find all this talk about GNOME possibly becoming based on Mono extremely unsettling. GNOME is part of the GNU project. The Mono project is not only not part of GNU, they're even openly hostile to the GNU efforts that they're competing with.
The only thing you need is a trusted 3rd party (GNU.org?) which have released the source for the Nexus, and have signed it.
The GNU project will never in any way directly or indirectly endorse the so-called "Digital Rights Management" (DRM) stuff which has no purpose besides making it more difficult to copy and distribute digital data.
The reason I would love DRM, is that I can go to a friends house, and use his computer, without having to worry if he has started a keylogger.
Preventing keyloggers isn't part of the job description of the implementors of DRM systems. Their job is just to (try to) kill the P2P filesharing revolution, nothing more, nothing less.
Advocates of free software claim to be advocates of freedom. If this were the case, they would only attack Microsoft on those terms. The WMP is not a freedom issue. If a customer doesn't like Windows prepackaged with WMP, there's nothing stopping that person from acquiring another OS.
If MS can leverage their strong market position in the desktop OS area to drive competing commercial producers of media players out of business, that is a freedom issue.
For example, both dotGNU and Mono have a C# compiler. Now how would a future contributor decide on which one to contribute for?
DotGNU is part of GNU, Mono isn't. So, if you'd like to support the GNU project, that is a reason to contribute to DotGNU Portable.Net
Learn from the better compiler architect. Rhys, the chief architect of DotGNU Portable.Net was an experienced compiler architect already before starting to work on Portable.Net; he's also the author of treecc, a great aspect-oriented tool for compiler construction.
Choice of implementation language: Portable.Net's compilers are implemented in C, while Mono's C# compiler is implemented in C#. If you think that working on a compiler for a language is a good way to learn that language (that was Miguel's stated reason for implementing, in C#, the C# compiler project that eventually became Mono's C# compiler), maybe you should contribute to Mono.
Do you believe in the power of large corporations? Mono is sponsored by Novell, Inc and has several people working on it full-time, and the Mono folks can afford to spend money on PR, too. That is clearly an advantage, at least for now. However, there are strong economic reasons why in the long run, platform projects that are controlled by a corporation should not be able to progress as quickly as true community projects like DotGNU or the Linux kernel. (Email me - nb AT pobox DOT com - for a draft of an economics paper on these matters.)
The threat of patent-based attacks. There are several reasons why DotGNU is less vulnerable to patent-related threats than Mono is. First of all, the difference in licensing is relevant. Mono's libraries are licensed under an X11-style license while the DotGNU project uses GPL with a linking exception, just like Classpath. Both are Free Software, both libraries can be used from proprietary software, but Mono's licensing terms are compatible with third-party demands for patent royalties, while DotGNU's licensing terms are not compatible with that. This means that when you contribute to Mono and someone has a patent and says "pay royalties!", the result is that Mono suddenly stops being Free Software. With the kind of licensing used by the DotGNU project, patent holders cannot require the payment of royalties (because that would be incompatible with the GPL) and if they say "DotGNU must not implement that at all" that'd be an antitrust violation, rendering the patent unenforcable and hence invalid. The worst that can happen to DotGNU on the patent front is that MS might say "don't use our patented APIs", but even then MS can't stop me from still distributing the code on a public ftp server since I'm in Europe, and around here patent law isn't nearly as broken as in the US. Even in the US, if those API patents are granted and MS tries to enforce them against DotGNU, it should be only a question of time until those silly API patents of Microsoft's have been desclared invalid by a US court of law. On the other hand, Mono project leader Miguel de Icaza has stated that if MS says that a paid license from MS is required for distributing Mono code implementing those patented APIs, Novell would buy such a license. This would mean that the affected parts of Mono would stop being Free Software / open source, since it would no longer permitted to freely redistribute them without buying a license from Microsoft first. In other words, if you crontribute code to Mono's library and Microsoft says "we have a patent", Novell will give in immediately and not fight for the freedom of the code that you have contributed. DotGNU on the other hand is part of GNU, and the Free Software Foundation will fight very hard to make sure that code which you contribute remains Free Software.
So now you can write C code and it compiles for.NET. Does that mean it works for MONO as well?
The answer to your question is: yes, the compiled C code is truly portable and so it works not only with the "ilrun" runtime engine of DotGNU Portable.Net but also with Mono's runtime engine and with Microsoft's.NET runtime engine and with any other runtime engine that implements the standard.
By the way, please don't think of DotGNU Portable.Net as something that merely "compiles for.NET"... the goal of our project is to compete with Microsoft's.NET platform and eventually render it obsolete similar to how GNU/Linux is currently rendering the proprietary Unix versions obsolete.
What's the point, actually? C# is not something new
You're right. C# is Java with some relatively minor changes. I think that C# is an improvement over Java, but whether the improvements are significant enough to really justify what MS has done, to fork out a new language, that is certainly debatable.
However whether C# is new or not, and whether it's an improvement or not isn't really relevant. What matters is that we need to make it easy for app developers to create portable apps which will run not only on the Microsoft Windows system but really anywhere. That's what the word "portable" in "DotGNU Portable.NET" stands for.
the developers of C# (i.e. the people developing the language, not with the language) made sure that one can easily make use of C and C++ code and binaries already in existance. You can already call all the C/C++ APIs.
Sure, but this helps only if you can assume that those compiled C and C++ binaries are already installed on the user's computer. The main point of "compile once, run anywhere" is to be able to distribute a compiled program that will run anywhere. Of course in DotGNU, we don't define "anywhere" as narrowly as the Microsoft monopolists do:
Unlike Microsoft's C compiler, whose output will only run on
i386-based Microsoft Windows systems, our compiler turns portable ANSI
C code into a truly portable executable that will run any platform that
has a CLR ("Common Language Runtime"), regardless whether the system is
32-bit or 64-bit, little-endian or big.
Or is it because of some form of hatred towards C#
No. It's because there's a lot of C code out there that people might want to use from C# and other modern languages. Throwing that C code away and re-implementing in another language would be a waste of time.
SCO's going to be shredding and I hear their email server *just* crashed and its hard drives are going to have to be replaced. All of the archive tapes have suddenly gone bad.
Even if that happens, it'll still be possible to prove that the information is the email is correct, just from looking at the money trails (not only the trails of money from MS to SCO, but also from SCO to this consultant who wrote the email to show off to the SCO execs how good he is).
So I think there's no way that the publication of this information can conceivably cause true damage. Hence I think that ESR did the right thing in publishing it.
Slashdot Mirror
There is a Qt# project, which can be used with either DotGNU or Mono.
Independent of that, in the DotGNU project, there is work underway to create a "KDE theme" for DotGNU's System.Windows.Forms.
I'm not aware of any work in Mono that is specifically designed to support KDE integration, and I'd be surprised if there was, since one of the original stated goals of the Mono project was to "help GNOME".
That sentence which you quote isn't part of the "claims" of the patent. It's part of the "description" which is supposed to fulfil the function of teaching the invention. (Patents are supposed to be granted only for non-obvious inventions. The original idea of patents was to give inventors an incentive to teach the public about their inventions instead of keeping them secret. The incentive is the chance of getting a monopoly for a limited time and/or patent royalties. These patent rights are granted to the inventor in exchange for the inventor giving up the secret knowledge of the invention and making it known to the public through the "description" in the patent text. Of course, in the area of software patents, I haven't yet seen a single example where the disclosure in the "description" isn't totally worthless because it's impossible to make use of the idea and keep it secret at the same time.)
The "description" part of the patent text, and especially the introductory sentence which you quote, are irrelevant for determining the scope of the patent. For that, you have to read the claims.
Hence general-purpose PCs and bigger embedded systems are safe from this, but small devices such as handhelds are vulnerable?
It would be nice if the open source community could take Mono and optimize for various chips and cards.
Mono's current codebase isn't very suitable for that. However, if you're interested in this kind of thing, have a look at the DotGNU project, specifically libjit.
Actually a good project in this area exists already, the MyXaml project.
From the DotGNU perspective, XAML isn't particularly scary. We can simply support and recommend (and perhaps distribute) MyXaml.
Really, from the perspective of the Free Software community, XAML isn't particularly scary. XAML may make the deployment of apps easier, and some of those apps may have been written to run only on MS platforms, but that cannot possibly be worse than the current situation with most apps for desktop computers running only on MS platforms. If indeed the IT world switches to XAML, that's not something to be scared about (except perhaps from a security perspective) because supporting XAML+.NET on free operating systems is in fact easier than supporting native "Microsoft Windows" executables.
So I come to the conclusion that while I don't know whether XAML may perhaps be scary for Novell from a business perpective, or it may be scary for Miguel personally (because the MyXaml project is independent of Mono, and Miguel has historically found it difficult to interact with independent projects in a contructive, mutually beneficial manner), but certainly XAML is not a big threat for anything that I particularly care about.
the Y-Windows system is copyleft.
Is there any reason to think that this trend might be specific to the Australian music industry (for example because P2P music sharing could help with making making Australian music more well-known internationally), or is it reasonable to take this as an indication that P2P music sharing does not really undermine the commercial viability of the recording industry, worldwide?
Hmmm... I'd define "world without information boundaries" as "a world in which no-one has an economic incentive to deny you access to any information that would be useful to you for some legitimate purpose".
This doesn't rule out securing computer systems against crackers, and it doesn't rule out using cryptography for protecting the privacy of truly personal matters.
However I'd say that business practices of selling a GNU/Linux distro which contains demo versions (and no full-featured versions) of some programs are clearly in violation of this "world without information boundaries" vision. Shipping any programs without making the source code available is even worse.
I wonder whether corporations as big as Novell can survive in a "world without information boundaries". I'd expect that in such a world, networks of smaller (much more nible) companies will rule.
Alas, no. Of course this would need to be done by someone who is reasonably objective (in particular not someone who is emotionally attached to either project), but if done well such comparitive reports would certainly be valuable not only to users but also to both projects.
Hence, if we in the so-called "developed nations" don't fix our legal systems, third-world countries, where "intellectual property law" cannot be enforced for lack of a functional legal system, will become the leaders in creative industries, including IT, right?
Yes, definately.
That said, in the middle of FUD that post has some interesting claims, like impractible goals of DotGNU
I'm not sure what you mean with "impractible goals of DotGNU". Fundamentally I'd say that there are two types of goals: "essential goals" and "dreams". With an "essentail goal" I mean a goal which is essential for making the project a success; if we don't reach that goal, the project hasn't been fully successful. For DotGNU, "making it easy to port apps that were written for .NET so that they become truly portable with DotGNU Portable.NET" is an "essential goal" in this sense. With "dreams" on the other hand I mean the type of goal that would be great to achieve, but where it's not really essential to achieve it. I have lots of DotGNU-related dreams, probably most of them will never get realised, but some will, and I think there's nothing wrong with that.
Maybe you mean Miguel's statement "the DotGNU team wanted to invent a new virtual machine that supported Java and .NET at the same time"? That dream is not as impractible as it might appear at first.
Read this. We do have a working runtime for IL which has been designed in such a way that there no serious obstacles (besides lack of volunteers) against adding support for JVM bytecode into this same runtime engine. Miguel criticises the JVM bytecode support as "slow, untested, and very broken"; I'm not interested in debating these claims. This JVM bytecode support is not something that we publicise as a feature; rather it's a proof of concept showing that with pnet's design it is possible to implement this, and an invitation to anyone who is interested in JVM-IL interop to come on board and work out the details.
reading Rotor code
Miguel's statement "Pnet follows a different approach: read Rotor, and do a new implementation of it" is mostly FUD. The truth of the matter is that Rhys has asked Eben Moglen, who is the General Counsel of the Free Software Foundation (and also the author of the GNU GPL and LGPL) for legal advice concering the question of whether looking at Rotor code is ok, and received the following response (posted with a bit more context in the pnet FAQ):
We follow this advice.This isn't true. The implementation of DotGNU Portable.NET proves that it can be implemented directly on top of X, without any need for Wine or winelib.
No there aren't. DotGNU Portable.NET has a Java compiler front-end to the cscc compiler which you normally use to compile C# to IL. This Java compiler isn't currently useful (you'll need to port at least the basic class library before you can really use it) and not going forward (because the programmer who worked on it while still a student now has a job that keeps him pretty busy) but it's certainly a good starting point for anyone who wants to work on this.
Also there are no insurmountable technical barriers against the following, more tricky objectives:
- Compiling both Java and C# to JVM bytecode, or to Parrot bytecode.
- Executing both IL and JVM bytecode in the same VM.
These kinds of things aren't currently in active development, but it has been taken into account already during the design of the Portable.NET compiler system and run-time engine that one may eventually want to do such things.Here are two clear examples of hostility coming directly from Mono project leader Miguel de Icaza:
- This slashdot posting is one of several instances in which Miguel has publicly spread FUD against Portable.Net, attempting to cast a shadow of legal doubt on that project because it was started before the ECMA specs were published. According to our lawyer (Eben Moglen) what was done back then was perfectly legal, but even if that wouldn't be the case, it wouldn't matter because all the old code from back then has long been removed from the codebase anyway. These matters have been explained to Miguel, but in spite of that he has continued to spread this FUD. I think this is totally unacceptable. He also calls me and the other DotGNU coreteam members "kids", and makes other false statements that however are not so significant, hence I won't discuss them in detail.
- In response to my last proposal of collaboration, Miguel first said he's interested but when I shared some more thoughts, he responded by attacking me, calling my view "intellectual dishonesty" and "an exercise in deception". Of course Miguel is free to have his own opinions, and Mono is free to respond with "no" to proposals of collaboration, but he could have said "no" without attacking me like that.
Suppose that one day Microsoft starts making SCO-like attacks against DotGNU and Mono. Miguel is well aware that this is a possibility, and here he has stated that "if Microsoft in fact owns patents to the technology and they require the licensing of those, we are willing to license those for the sake of our users and customers." Since this statement was made in the context of discussing the threat from the possibility of patents that MS may not be willing to license royalty-free to everyone, such buying of licenses (while compatible with the X11-style licensing that Mono is using for the affected code) would change the status of the affected code from being Free Software to it being source-available, "paid Microsoft license required" non-free software. (Novell would buy a license that allows them to distribute the code, but which probably wouldn't give others the right to distribute derivative works, hence the code would stop being Free Software). However we in the DotGNU project would not accept Microsoft's demands for patent royalties, even if that means that until the patents in question have been invalidated by a US court of law we can distribute some code only from ftp servers outside the US. In view of these different planned reactions to any demands for licensing royalties it seems quite possible that Novell would agree to make Mono non-free (probably still free as in beer, but no longer free as in freedom), while we'd have to fight the legal battle against MS without their help. In view of this possibility, I consider remarks from Miguel like those quoted above which attack the DotGNU project's legal position to be extremely hostile.I find all this talk about GNOME possibly becoming based on Mono extremely unsettling. GNOME is part of the GNU project. The Mono project is not only not part of GNU, they're even openly hostile to the GNU efforts that they're competing with.
The GNU project will never in any way directly or indirectly endorse the so-called "Digital Rights Management" (DRM) stuff which has no purpose besides making it more difficult to copy and distribute digital data.
The reason I would love DRM, is that I can go to a friends house, and use his computer, without having to worry if he has started a keylogger.
Preventing keyloggers isn't part of the job description of the implementors of DRM systems. Their job is just to (try to) kill the P2P filesharing revolution, nothing more, nothing less.
Didn't you RTFA? The topic is Portable.Net which works on more platforms than Mono does.
If MS can leverage their strong market position in the desktop OS area to drive competing commercial producers of media players out of business, that is a freedom issue.
The answer to your question is: yes, the compiled C code is truly portable and so it works not only with the "ilrun" runtime engine of DotGNU Portable.Net but also with Mono's runtime engine and with Microsoft's .NET runtime engine and with any other runtime engine that implements the standard.
By the way, please don't think of DotGNU Portable.Net as something that merely "compiles for .NET"... the goal of our project is to compete with Microsoft's .NET platform and eventually render it obsolete similar to how GNU/Linux is currently rendering the proprietary Unix versions obsolete.
You're right. C# is Java with some relatively minor changes. I think that C# is an improvement over Java, but whether the improvements are significant enough to really justify what MS has done, to fork out a new language, that is certainly debatable.
However whether C# is new or not, and whether it's an improvement or not isn't really relevant. What matters is that we need to make it easy for app developers to create portable apps which will run not only on the Microsoft Windows system but really anywhere. That's what the word "portable" in "DotGNU Portable.NET" stands for.
Sure, but this helps only if you can assume that those compiled C and C++ binaries are already installed on the user's computer. The main point of "compile once, run anywhere" is to be able to distribute a compiled program that will run anywhere. Of course in DotGNU, we don't define "anywhere" as narrowly as the Microsoft monopolists do:
Unlike Microsoft's C compiler, whose output will only run on i386-based Microsoft Windows systems, our compiler turns portable ANSI C code into a truly portable executable that will run any platform that has a CLR ("Common Language Runtime"), regardless whether the system is 32-bit or 64-bit, little-endian or big.
Or is it because of some form of hatred towards C#
No. It's because there's a lot of C code out there that people might want to use from C# and other modern languages. Throwing that C code away and re-implementing in another language would be a waste of time.
Has anyone analysed Microsoft EULAs to determine what legal risks they expose you to if MS ever gets as deparate as SCO is today?
Even if that happens, it'll still be possible to prove that the information is the email is correct, just from looking at the money trails (not only the trails of money from MS to SCO, but also from SCO to this consultant who wrote the email to show off to the SCO execs how good he is).
So I think there's no way that the publication of this information can conceivably cause true damage. Hence I think that ESR did the right thing in publishing it.