Microsoft Puts C# and the CLI Under "Community Promise" 465
FishWithAHammer writes "Peter Galli of Microsoft posted a blog entry on Port25 today, regarding the explicit placement of C# and the Common Language Infrastructure (the ECMA standard that underpins .NET) under their Community Promise: 'It is important to note that, under the Community Promise, anyone can freely implement these specifications with their technology, code, and solutions. You do not need to sign a license agreement, or otherwise communicate to Microsoft how you will implement the specifications. ... Under the Community Promise, Microsoft provides assurance that it will not assert its Necessary Claims against anyone who makes, uses, sells, offers for sale, imports, or distributes any Covered Implementation under any type of development or distribution model, including open-source licensing models such as the LGPL or GPL.'"
Adds reader anshulajain: "Understandably, Miguel De Icaza is jumping with joy."
promise doesn't extent downstream (Score:4, Informative)
Sounds promising... (Score:3, Informative)
It sounds promising, and it may end up meaning Stallman was wrong all along and that it was safe to implement .Net/C# (which GNU have done anyway). It's be useful to have somewhere slightly more authoritative to hear it from (like Microsoft themselves) but at least people don't need to worry about "arrrghh, it's a patent trap" and can get on with "hurrah! I can focus on coding for the desktop in a decent language rather than having low-level memory concerns etc".
Not that I ever cared anyway. Stick to the registered standard definition of C# and Microsoft couldn't exactly kill off Mono anyway, as they'd probably have ended up breaching the "fair and non-discriminatory" part of the patent licensing or been forced to give Mono a free license anyway.
It's about time (Score:5, Informative)
Now Microsoft is estopped from going after people using c# and .net technologies.
This is the answer I've wanted from Miguel ever since the Novell brouhaha.
Promissory estoppel serves as a "consideration substitute" in contract law that renders certain promises otherwise lacking in consideration binding and enforceable. In such cases, the promisee's reliance is treated as an independent and sufficient basis for enforcing the promise. Promissory estoppel can be viewed as a legal device that prohibits the promissor from denying the existence of a contract for lack of consideration.
http://www.lawnix.com/cases/promissory-estoppel.html [lawnix.com]
No more FUD (Score:1, Informative)
FYI, this IS legally binding (Score:5, Informative)
"Q: Is this Community Promise legally binding on Microsoft and will it be available in the future to me and to others?
.NET but not covered by the standard (like Winforms)
A: Yes, the CP is legally binding upon Microsoft. The CP is a unilateral promise from Microsoft and in these circumstances unilateral promises may be enforced against the party making such a promise. Because the CP states that the promise is irrevocable, it may not be withdrawn by Microsoft. The CP is, and will be, available to everyone now and in the future for the specifications to which it applies. As stated in the CP, the only time Microsoft can withdraw its promise against a specific person or company for a specific Covered Specification is if that person or company brings (or voluntarily participates in) a patent infringement lawsuit against Microsoft regarding Microsoft's implementation of the same Covered Specification. This type of "suspension" clause is common industry practice."
tl;dr they can't sue you, ever, unless you sue them over patents.
Also, Mono contains
1) parts that are covered by the ECMA standard (C# and the CLI)
2) original namespaces (like Mono.Simd)
3) open-sourced Microsoft stuff (like ASP.NET, under the OSI-approved MS-PL license)
4) parts that are in
which is why Miguel de Icaza says they'll be splitting their distribution up into now definitely safe (1 and 2) and potentially dodgy (3 and 4) packages, which is what already happens on Ubuntu for instance.
Seriously, who the fuck cares? (Score:3, Informative)
Why do people think C# is some new amazing language? Clearly MS took Java and gave it a MS framework.
If you would just use java you probably wouldn't have this fear of MS trying to undermine the OSS movement. When a multi-billion dollar company other than google tries to "help" OSS, you can only be suspicious.
http://www.javacamp.org/javavscsharp/getStarted.html [javacamp.org]
Re:No Really Definite Confirmation of This Yet (Score:5, Informative)
Re:promise doesn't extent downstream (Score:3, Informative)
It does not apply to 'partial implementations' either.
From the FAQ
Q: What if I don't implement the entire specification? Will I still get the protections under the CP?
A: The CP applies only if the implementation conforms fully to required portions of the specification. Partial implementations are not covered.
Re:No Really Definite Confirmation of This Yet (Score:5, Informative)
If you want a GUI on Windows, or using the Windows libraries, sure.
GTK# [mono-project.com] is entirely developed by the Mono project, and requires none of the aforementioned Microsoft parts. That means applications like Tomboy [gnome.org] and Banshee [banshee-project.org] should now be fully RMS-friendly.
Mono is more than just 'running Windows applications on Linux'. There is a large ecosystem of utilities developed with it, because (a) a properly object-oriented language with native bindings is much better than the C-with-Gobject alternative, and (b) Java was not Free at the time.
Re:No Really Definite Confirmation of This Yet (Score:2, Informative)
Re:Seriously, who the fuck cares? (Score:2, Informative)
Re:No more FUD (Score:5, Informative)
Re:No Really Definite Confirmation of This Yet (Score:5, Informative)
If you install libgdi+, Winforms works just find on FreeBSD.
As for looks that's a matter of taste, I never minded how Windows looks, but Gnome never really suited me. With libgdi+, winforms tend to look a lot like plain old Windows.
Re:promise doesn't extent downstream (Score:3, Informative)
The 'community promise' does not extend to commercial downstream recipients of open source MONO applications !
I think that is incorrect. Quoting from the community promise itself (linked in article)
Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation, to the extent it conforms to one of the Covered Specifications, and is compliant with all of the required parts of the mandatory provisions of that specification
It includes "using". So I do not receive the rights from the distributor of a MONO application, but I, as a user, am directly granted the right to use it from the microsoft community promise.
The fact that you have to conform to the standards is however a real restriction. It makes some sense, to avoid someone else playing an embrace-extend-hijack on them, like they tried with Java... however this also means that if I invent my own language+runtime D# that infringes on some microsoft C# patents this does not protect me.
Re:No Really Definite Confirmation of This Yet (Score:4, Informative)
According to a comment by Miguel on his blog,
Re:Implementations in progress appear not covered (Score:1, Informative)
Re:No Really Definite Confirmation of This Yet (Score:4, Informative)
You're right, but the most common criticism of Mono before this announcement was that free software distributed with Linux carried a patent risk. The Winforms stuff is still a goal of the Mono project, but there is no reason for Linux distributions to install it. The non-ECMA parts of Mono are still very useful for companies migrating existing Windows legacy apps to Linux, but nobody would write a new free application with Winforms starting from scratch (GTK# is a lot better).
So the Windows.Forms and other Microsoft APIs move to a separate 'Mono-non-ECMA' package, which can be treated a bit like Wine: you wouldn't really want to install it by default or develop against it, but it can be invaluable if you have existing Windows software you want to run.
Re:It's about time (Score:3, Informative)
So what you're saying is that it's a really well disguised trap?
Note that what Microsoft is stopped from doing has no bearing on what they can fund other companies to do on their behalf [cnet.com].
There's no legal basis for any third party to sue .NET implementers, you say? Well, gosh darn, I guess there's no way that Microsoft could fund them to file a bullshit case that drags on for year after year after year, tying up court time, costing the defendants millions in fees, and eating away at the hearts of souls of good men like a cancer [groklaw.net]. Is there?
Re:No Really Definite Confirmation of This Yet (Score:4, Informative)
Almost. I present to you, the Mono Project FAQ:
(my emphasis)
That was the main concern of RMS: that the attraction to the project was the promise of cross-platform .NET development, but that such development is ultimately encumbered by patented technologies.
-dZ.
Promissory estoppel ftw (Score:5, Informative)
The lawyers amongst us are leaping for joy. I happen to be a law convert. So ill try and explain why we're happy!
Promissory estoppel is a legal defence (a so called shield). When a party (A) intending legal relations promises not to assert their strict legal rights, and another party (B) moves to rely upon this promise, that party (A) is estopped from enforcing their rights (against B) by way way of promissory estoppel.
It goes something like this: Now MS has promised not to enforce their C#-rights , and people rely on this promise, such as start development/deploying C# applications because of this promise, if the case came to court, MS's argument would be estopped by a defence of promissory estoppel.
It's a little more complicated. For instance it must be inequitable for B if A reneges on their promise (fairly clear if they suffer a disadvantage or loss as 'one who comes into equity must come with clean hands'), the promise must be clear and unequivocal (I'd say yes), there must be a change in reliance on the promise (yes), and it is a shield not a cause of action (in other words, we can't sue MS for revoking the promise, we can simply aovid being sued).
However, things get a little confusing. MS have declared that this promise is unilateral, in other words, it is a promise to the world without the need for a formal agreement. Such things are valid in the eyes of the law, and enforced by the fact promissory estoppel acts as an equitable remedy - there is no need for consideration, a key ingreediant to the traditional offer/acceptance/consideration contractual model.
Promissory estoppel is a common law principle. It's basis in England is from Lord Denning's High Court decision in High Trees.
Law bit:
In High Trees, due to WW2, the claimant ("High Trees") agreed to reduce rent for a block of flats. After the war, the claimant brought action seeking the past and future rent. Lord Denning said "When a promise is made that is intended to be acted upon, and is acted upon, you are estopped from going back on it."
In High Trees Denning referred, not to a previous case of Foakes v Beer (about the part payment of debt), but Hughes v Metropolitan Railway to establish his basis for promissory estoppel. In Hughes, it was held that the opening of negotiations for sale of a property had an implied promise not to enforce an outstanding notice of repair that would forfeit the respondents lease.
Key to the criticism over Denning's decision is that Hughes only suspended rights, whereas High Trees may extinguish them. This position has recently been approved in the UK by the House of Lords in Tool Metal Manufacturing Co. Ltd - the promisor may revive rights by formal notice, unless it is impossible for the promisee to resume his original position.
Is it impossible to resume the original position prior to this agreement? We're talking about computers here. The agreement has come now, not several years ago. Consider Mono as it is now, as the original position. This is such a contentious area when you consider MS can revoke the promise, creating ambiguity, and because under Coombes v Coombes promissory estoppel is not a cause of action, the Mono community cannot sue MS to enforce this promise!
Matt
Mono is now free to follow it's own path. (Score:3, Informative)
Thinking about it, the Community Promise is a huge win for Mono.
The Patent Trap was always a concern when I used Mono. I knew the external libraries ado.net, asp.net and winforms were "tainted" but was always unsure about the "core" on Mono itself.
Now that the "core" of Mono seems to be free from the patent threat from Microsoft Mono can take a new "patentless" path and develop equivalent versions of the libraries not mentioned in the Community Promise.
You won't be able to run Windows .net stuff (legally/safely) on Linux but you would be able to run Linux .net stuff on Windows.
GTK# seems to be a mature gui frontend the only major missing part is .ADO library for data access (unless something is already out there).
Mono does not *have to* follow Microsoft's upgrade treadmill and keep up-to-date compatibility with the latest version of .net instead concentrate on delivering applications on other systems - Linux, non-windows arm-based processors and macs.
In the end Mono could embrace, extend and extinquish Microsoft's own implementation.
Re:Sounds promising... (Score:5, Informative)
Before that, he deprecated Java like he’s doing with Mono now.
Re:Seriously, who the fuck cares? (Score:5, Informative)
I find it pretty amazing when you mention this to most C# programmers, they'll go on about how different C# is from Java.
"They" do? Really! Funny, as a C# programmer who has fairly extensive experience with Java, I've never said any such thing. Maybe you should try *not* stereotyping large groups of people, eh?
For the record, C# is really Java polished up. It provided generics and a foreach loop first, implements type-safe function pointers, lambdas (the absence of lambdas in Java always annoyed the hell out of me), a much better native call interface, and a few minor but handy language features (eg, safe ref and out parameters, using blocks, etc). And I very much prefer the native GUI of C# applications (although the nasty boilerplate necessary to build them makes a GUI builder absolutely required).
On the API side, they're about equivalent, though both have their warts... although, I must confess, some of the problems in the .NET API are a bit baffling (date handling in .NET 2.0, for example, is unbelievably primitive... there is simply no facility for doing arbitrary time zone conversions... seriously, what the hell?).
But anyone who argues that C# is basically the same as Java doesn't understand how some of those features can make a programmer's life *much* easier. Are they necessary? No, of course not. But they certainly are handy (honestly, without proper anonymous closures, I feel crippled as a programmer... as a tool for building clean, reusable, modular code, they're simply invaluable).
And as an aside, while I realize that Java is starting to take on a lot of these features, keep in mind, it probably never would have if it weren't for the competition that C# and .NET are offering. So, in the end, the Java fans out there can thank Microsoft for Java finally moving forward and gaining some of it's new, modern features (can we say "generics"?).
Re:This makes no real difference! (Score:2, Informative)
"...We introduce instructions newdata, lddata, stdata, castdata, isdata and switchdata to create and manipulate classunion values..." (emphasis mine).
All of those operations have been superseded by ECMA-335 4th edition. [ecma-international.org] Which per the CP would be open for implementation. However, that doesn't exclude the possibility that more operations could be added without submitting to ECMA. However, the ones that you have cited are a non-issue.
Cheers.
Re:Seriously, who the fuck cares? (Score:3, Informative)
C++ programmers and Java programmers can all feel quite at home after only a short time in C#. It was designed that way. Saying that, coming to it only knowing C/C++, it didn't take much longer for me to develop an initial familiarity with Java. In fact, pretty much by definition, and for obvious reasons of programmer portability, most strongly typed, high-level programming languages are remarkably similar.
The only thing Java and C++ had in common were the C syntax and the object orientation.
In (the original) Java, compared to C++:
- Code is meant to be byte-compiled;
- There is no preprocessor;
- There are no pointers, and no pointers to function in particular;
- No explicit memory management is possible, and there are no destructors;
- You cannot declare isolated functions/procedures;
- There is no distinction between class declaration and class implementation;
- Multiple inheritance is forbidden;
- There are no templates;
- Many of the more "academic" access modifiers are missing;
- There is full reflection of types and code;
- There is a mapping between the file system and the code namespace;
- Even the basic types change: there are no signed integers.
Notice how almost all of these points apply to C# as well.
So C++ and Java are two completely different languages. A Java developer *can* be comfortable with C++, because he can build himself something vaguely similar to a Java environment by selectively using a subset of the features of C++, and relying on a good external development platform like Qt. But the other way around is not true.
On the other hand, C# and Java are *very* similar: the most striking evidence of that is the fact that the whole Java syntax can be closely mapped to C# equivalents. C# brings additional features such as delegates, properties, operator overloading and output variables, but these are a little more than syntactic sugar if we consider that the overall design and the language philosophy are completely copied from Java.
Even the standard library, and its organization, are strikingly similar to Java's ones (and have nothing to do with the C++ ones).
To say that C# is identical to Java, though, is bollocks.
Initially C# was almost a Java ripoff, with minor feature additions. But after that, the languages evolved separately.
In particular, Java abandoned its elegant and simple design, trying in its turn to steal some of the features that were eventually added to C#, and as a result it became an ugly hircocervus upsetting both some of the old users, who had to learn new concepts, and many of the new users, who found that the new features were crippled because of backward compatibility. It'll probably get even uglier when new paradigm-changing features such as closures will be added.
But C#, too, is suffering from the kitchen-sink syndrome now.
There are some pretty significant differences, and in many cases I prefer C#'s implementation.
I find Java's syntax more self-documenting, for example for the absence of properties and operator overloading. But Java has some rough edges because of backward compatibility.
.javapp, one could even mix old code and new code without problems. That would remove the only weak point Java has when compared to C#.
I don’t understand why Sun does not introduce a new version of Java retaining bytecode backward compatibility but *without* source-level compatibility. By giving the source files a new extension, say
Re:This makes no real difference! (Score:5, Informative)
That was a research paper on ILX from 2001.
The research work from ILX was folded into .NET 2.0 and is part of ECMA 4th edition.
All of the instructions that you listed are deprecated, they never really made it into .NET, their much improved, polished and battle field tested versions did. And they are the foundation for C#'s generics support and Don Syme's F# compiler, both which run just fine in Mono today.
Re:No Really Definite Confirmation of This Yet (Score:5, Informative)
Writing GUI-based GTK# applications does not require any libraries not covered by this promise. There are FOSS database access libraries available for Mono that interface with MySQL etc. without needing ADO.NET. In fact, none of the high profile C# complex(!) applications for Linux like FSpot, Banshee or Tomboy require any libraries not covered. And Mono is separating the source code into two parts in a future release so that you can run the libraries in doubt at your own discretion and risk. You're the one who's missing it, not everyone else. Here is a figure for clear delineation. http://primates.ximian.com/~miguel/tmp/two-stacks.png [ximian.com]
facts are different (Score:4, Informative)
Even for a Linux enthusiast, the Visual Studio/Winforms stack is much more tempting for ambitious projects.
All Mono desktop applications that ship with Ubuntu are based on Gtk#. Winforms isn't even usually installed.
I'm a Windows developer by day and a Linux user by night, and I've got probably half and half MonoDevelop and Visual Studio projects at home. Pick the best tool for the job, they say.
VisualStudio and Winforms are proprietary and simply aren't a choice for Linux desktop applications (even if they didn't suck).
Re:No Really Definite Confirmation of This Yet (Score:3, Informative)
If you look closely at the announcement, you'll see that there are two separate promises, one for CLI spec, one for the language spec.
get real (Score:4, Informative)
Java has less "patent liability" than Mono.
Sun has lots of patents on lots of aspects of Java. The only area where you *may* be safe is if you use Sun's own implementations.
I know that these .net libraries have been implemented in Mono but would we have to write new open-source libraries to replace thier functionality and remain "patent-threat" free?
Most people who develop with Mono develop using standard Linux libraries, libraries that are free of any hint of Microsoft patents. That's one of the things that makes Mono so attractive.
prefer Mono - especially Banshee ... Without the other libraries I fear Mono is hamstrung.
Banshee, like almost all Mono desktop apps, is based on Gtk#, not Winforms.
What are the overheads of both the Java and Mono virtual machines running at the same time? Would we be better getting behind just one environment and using that.
IKVM runs Java inside a CLR. It also neatly avoids Sun's patents.
Re:Seriously, who the fuck cares? (Score:3, Informative)
Unsigned numeric types. Delegates. Structs (stack-allocated complex data types that are passed by value). LINQ. The option of explicit memory management. No stupid restrictions like only one public class per file. Partial classes. Operator overloading (not always good, but occasionally just damn sensible). There's plenty more...
You can pretty much run a find-replace over Java and get legitimate C#. The reverse is not true. C# >= Java.
Re:It's about time (Score:5, Informative)
The idea of embracing and extending is an old one. First, you offer to work with someone. Then, you slip in nonstandard extensions that aren't as widely available, but convince people they are an improvement. Then, you either pull out compatibility with the old standard or count on enough people using your new, non-standard version that people using the open version are left behind.
Microsoft has tried this with TCP/IP, name services (WINS rather than DNS), network protocols (NetBEUI), office suites (MS Office was once capable of opening and saving the formats of suites which were then more popular, but thanks to preloads and trial versions dropped support for the competition's file formats once it was the market leader), filesystems (it's still suing over variations of FAT), and even the joint development of operating systems (a cross-license and joint development agreement between Microsoft and IBM for Windows and OS/2 ran out just before Microsoft unleashed Windows 95, which was gratuitously incompatible with the Windows APIs in OS/2).
Re:It's about time (Score:3, Informative)
C# is a language. There's no point in forking that, because it's completely covered by the promise. Same goes for the runtime (CLR).
What's not covered are all the libraries, and there, as I pointed out already, the "forks" are going on in form of various Mono.* libraries, and Gtk#/Gnome# stuff. Which is actually used to write decent Gnome apps.
They also work on WinForms, ADO.NET, ASP.NET etc because there is some interest in that as well, but it mostly doesn't intersect with people who use Gtk#.
Re:Is C# / Mono + libraries really *that* good? (Score:3, Informative)
Sounds closer to the power I get with Python whilst still offering me the potential for efficient JIT and arguably better structuring / type-checking at development-time (though I have used tools that help with this issue in Python).
It's a fairly close assessment. Of course, dynamic languages offer a lot of power that no statically typed language could possibly offer (just consider the possibility of defining classes and methods inside "if" in Python); and C# is definitely a static language, even though it will get opt-in duck typing [microsoft.com] soon, mostly to improve interop with dynamic languages (such as IronPython).
If you want to take a look specifically at the features I've listed (and you're generally proficient with C++/Java language family), here are the links covering them specifically:
Re:It's about time (Score:4, Informative)
It isn't paranoia if they've done it to you more than once already to think they might do it again. And yes, I can name the "they" -- Microsoft. It's more than one person, after all. A corporation by definition is a "conspiracy", although not necessarily with the negative connotations that word carries. It's always one group of people working together for a common goal which furthers the interests of their group above and before the interests of others. Perhaps when looking for conspiracy nuts you find them easily when corporations are being discussed, but that doesn't mean anyone's actually paranoid.