Just as I finished a list of .NET 3.5 FCL classes not covered by ECMA 335. Oh well, maybe it will be useful for some other purposes.
http://mono-nono.com/bbpress/topic/detailed-count-of-net-35-covered-by-ecma-335

To my mind, in the sphere of developer tools, they haven’t done much wrong as yet. Sure, that could change. I’m giving them the benefit of the doubt. Innocent until proven guilty, no?

I understand why you feel as you do about clean-room implementation, but that’s mostly a matter of ingenuity if it is possible to work around it (see here), and a matter of interoperability if it is not. Unless something comes up, I don’t think that I’ll worry too much about it, since none of the non-covered namespaces are essential.

On the other hand, if patent problems do arise, I think that I (and others) would become much warier about using the .Net platform. One doesn’t want to code for new features (e.g. LINQ-to-XML), and then have some stupid legal crud slow down a port! Depending on the seriousness of anything that arises, I may well decide to abandon the platform. That would be sad :/.

“Reimplementation of existing libraries is not necessary.”

By far, this is the least correct statement you have made yet. Please refer to patent section in mono faq:
“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.”
http://mono-project.com/License

Notice #2 choice of mono team is to drop the piece of code infringing a patent. That would leave the burden of reimplementing that piece of library with the user.

“If a new library comes out that is not covered by the CP, a clean-room implementation may be necessary. This is perfectly legal, and the library would have to be implemented in any case. Where’s the problem with this?”

Clean room implementation does not shield you from patent claims. Any new library not covered by the CP would be a subject to the same issues as current libraries not covered by CP.

_________________________________________________________

As for wiki link, it contains a link to an incomplete list of FCL namespaces. I’ll write a script to compare the list of libraries covered by ECMA 335 and a list of namespaces of .NET 3.5 SDK.

Why did you pick CLR compatibility. I was talking about .net compatibility, and as you have put it: mono “is a CLR + tools + libraries”.
I keep talking about the entire stack, but you insist on picking CLR.

Alright. We agree that the CLR will remain, and there are no legal issues with it, so there are no problems there. Mono’s tools have been independently created, and there are no problems there. The core libraries will remain (see: estoppel, ECMA process), so there are no problems there.

So, tell me: what’s still bugging you that hasn’t been covered?

Explain me how is legal translation to older MSIL or java is 100% reliable and 100% automated when you have to reimplement some libraries to make that translation possible?

See above. Reimplementation of existing libraries is not necessary.

(I’ll repeat that). Reimplementation of existing libraries is not necessary.

Such libraries are also 100% legal. If a new library comes out that is not covered by the CP, a clean-room implementation may be necessary. This is perfectly legal, and the library would have to be implemented in any case. Where’s the problem with this?

http://en.wikipedia.org/wiki/.NET_Framework
You can find further links on that page with a list of assemblies.

No such list exists on that page; and note that ECMA includes much more than just the BCL (e.g., the System.Environment namespace). There are dozens of links leaving the page. Can you be more explicit? Where is this list of non-covered assemblies to which you refer?

“Absolutely, and I still claim that. This completely solves the CLR compatibility issue.”

Why did you pick CLR compatibility. I was talking about .net compatibility, and as you have put it: mono “is a CLR + tools + libraries”.
I keep talking about the entire stack, but you insist on picking CLR. Are you reading a manual on straw man argument or something?

Explain me how is legal translation to older MSIL or java is 100% reliable and 100% automated when you have to reimplement some libraries to make that translation possible?

__________________________________________________________

On an unrelated topic: you make it sound as if the evidence you require does not exists or impossible to find, when in fact it’s a common subject of pro-anti-mono arguments.

But if you feel the need for diving into a side argument (you seem to do that a lot, my guess is to avoid the real issue)…
Here is a quote from wikipedia:
“The Framework Class Library (FCL) is a superset of the BCL classes and refers to the entire class library that ships with .NET Framework. It includes an expanded set of libraries, including WinForms, ADO.NET, ASP.NET, Language Integrated Query, Windows Presentation Foundation, Windows Communication Foundation among others. The FCL is much larger in scope than standard libraries for languages like C++, and comparable in scope to the standard libraries of Java.”
http://en.wikipedia.org/wiki/.NET_Framework
You can find further links on that page with a list of assemblies.

“Lex: you are bordering on being a troll.”

Richard: you are past the borderline of contradicting yourself, so you start flaming.

You were claiming that any mono project can be recompiled (i’m sorry, TRANSLATED) into java or older MSIL to avoid legal issues, and that it can be done with 100% reliability and 100% automation. COST FREE (yes, you were claiming that too)! Click – done.

Absolutely, and I still claim that. This completely solves the CLR compatibility issue.

So now you are saying that indeed, some libraries may have to be reimplemented. But this is not 100% automation and not cost free.

Now? You act as though this is news to you. I have addressed this in comments #34 (“If the feature [...] avoidance of patent issues”), #41 (“this is called [...] are good at it”) and #45 (“this is why [...] worse at the game”). Library compatibility is a completely separate issue to CLR/runtime compatibility. To other readers of this post: is there something that I’m failing to explain to Lex? Perhaps one of you could do a better job? I’m all out of ways to make this simpler to understand.

Lex: you are bordering on being a troll.

For the answer what libraries in .net are patented and not covered by CP I suggest you lobby to Microsoft.

No, I don’t think that I will. You made the claim, now back it up or retract it. The onus is not on me to provide evidence for your claims. Whenever I have made a claim, I have provided evidence for it, and referred you to neutral parties if you had doubt. It’s time that you did the same.

You were claiming that any mono project can be recompiled (i’m sorry, TRANSLATED) into java or older MSIL to avoid legal issues, and that it can be done with 100% reliability and 100% automation. COST FREE (yes, you were claiming that too)! Click – done.

So now you are saying that indeed, some libraries may have to be reimplemented. But this is not 100% automation and not cost free.

And you are still silent on “100% reliability”? Oh well…

For “evidence” you have requested I suggest you refer to patent section in mono faq: http://mono-project.com/License
For the answer what libraries in .net are patented and not covered by CP I suggest you lobby to Microsoft.

You make accusations; let’s see if you have the evidence to back those accusations up!

Let’s take a mono library that is not covered by ECMA and is not a subject to patent protection.

Name such a library. System.Data, System.Web we know of; these are trivial (in fact, System.Web is effectively being done away with in favour of MVC); any others?

The big problem is that most .net libraries are not a part of ECMA.

… “most”? Big claims. What percentage are we talking about? Can you give me the assembly names?

Your answer consistently seems to be – recompile them to another bytecode.

No. That is my answer to a future incompatible CLR. That is not my answer to the problem of libraries; if you think that it is, quote any point at which I say that. My answer is “this is why such libraries would have to be reimplemented”, to quote myself in comment #45. My answer to the legal “issues” that might arise from this strategy are documented at the end of comment #34.