The .NET API patent, mono, and GNOME
The Mono project pushes a lot of buttons in the free software community. Patents, Microsoft, language choice, and platform choice all generate lots of heat individually, and Mono has them all. In spite of all the debate, there are still some issues that remain unresolved. There are undoubtedly some people who have been avoiding Mono just because Red Hat was; now that Fedora has it (while RHEL is still apparently up in the air) it's tough to know if Mono is safe to use or not.
I'm not a lawyer, but since everyone who has gotten advice from one (or who is one) is being tight-lipped about it, the rest of us apparently have to figure things out the best we can. I asked Red Hat Deputy General Counsel Mark Webbink about the decision to include Mono, and he replied:
"...protections available to open source developers, vendors, etc."--sounds like the patent pools that are intended to create a mutually-assured-destruction sort of scenario for anyone wanting to sue open source projects for patent infringement. These pools have been derided as PR gimmicks, but Webbink's note makes it sound like some people are willing to actually put some trust in them.
This message also makes it sound like the Fedora decision-making mechanisms are finally starting to become separate from Red Hat's. I sent a message to Greg DeKoenigsberg of the Fedora Foundation, and I got the one-sentence official line in return:
Greg also suggested that more information may be forthcoming soon.
One of the really interesting aspects of the timing is the fact that the main patent application that has been discussed in the media (the API patent application) appears close to being automatically abandoned. The API patent, if it were granted, would be a big blow to the Mono project. Many patents on various aspects of the implementation could have been worked around, but the API implementation not only makes up a significant portion of the Mono codebase (making it a big project to re-do), but is also what all software written for Mono/.NET uses. If the API becomes unusable, you can't hide a work-around in the Mono internals, because the API forms the connection between Mono and the rest of the world.
In October of last year, the patent office issued a "Non-Final Rejection" to the patent application, meaning that Microsoft can try to fix the application. Indeed, if you read the non-final rejection, there are several suggestions the patent examiner makes about how to fix problematic issues. However, there is also a big section of the rejection notice that talks about prior art in the form of two already-issued patents. Those could be harder to work around.
The rejection notice says that the deadline for reply is three months from the date of mailing, which was October 21st, 2005. It has now been almost three months, and Microsoft has not yet replied. According to the rejection notice, if there's no reply before the deadline, the application is automatically abandoned.
What does that mean? Well, ask a lawyer, I guess, but it sounds pretty good for Mono. More importantly, maybe, is what it means for GNOME. In the spring of 2004, there was a big discussion on whether to begin using Mono in the GNOME core desktop. For example, see Havoc Pennington's essay on the topic. Clearly, it would be good to start writing core functionality in something nicer than C; however, the GNOME developers are understandably reluctant to open things up too widely and end up with a large number of different languages in the core desktop. The debate didn't reach a conclusion, with Novell going one way, Red Hat going another, and the community left hanging, with little information with which to make a decision.
Since then, several useful GNOME-targeted applications have been written using Mono. With the confusion regarding whether or not Mono would end up in all the major distributions, though, those applications have undoubtedly not gotten as much support and contributors as they could have. There are also non-Mono alternatives to some of them. While competition between projects is certainly healthy and a good thing in general, one of the strengths of free software is the ability to share and cross-pollinate. If different projects use different languages, libraries, and platforms, though, that sharing becomes much more difficult. Hopefully, some clarity on Mono's risks is forthcoming, and then maybe the split can be resolved.
[The author wishes to disclose that he holds stock in Red Hat, Inc.]
| Index entries for this article | |
|---|---|
| GuestArticles | Skinner, Mitch |
Posted Jan 19, 2006 1:04 UTC (Thu)
by mitchskin (subscriber, #32405)
[Link]
Posted Jan 19, 2006 2:18 UTC (Thu)
by louie (guest, #3285)
[Link] (3 responses)
Posted Jan 19, 2006 4:21 UTC (Thu)
by mitchskin (subscriber, #32405)
[Link]
Sometimes patent applications can be abandoned and continued in a new application (in fact, the one that's about to be automatically abandoned is a continuation of an earlier abandoned application), but you have to file the continuation application before the parent becomes abandoned. In other words, they can't continue after the deadline unless they manage to revive the application. I have a hard time imagining Microsoft showing that they had an unintentional or unavoidable delay, so once the deadline passes I think the chances of them trying to revive the application are pretty low.
In some cases it's possible to try again with a whole new ("substitute") application (even after the original was abandoned), but anyone who does that loses the benefit of the original filing date. The original filing date is important because in the US you have to apply for a patent within a year of publishing the details of the invention. Since Microsoft published the .NET API more than a year ago, they wouldn't be able to start a new application now.
Again, I'm not a lawyer, and this isn't legal advice, but once the deadline passes I personally will feel a lot better about contributing to Mono or any GNOME-oriented project that uses it.
Posted Jan 19, 2006 9:48 UTC (Thu)
by khim (subscriber, #9252)
[Link]
No, it does not. The problem with litigations and lawers is that it's impossible to give general answer. - Can I be sued over this ? Journalists are not lawyers - and for good reason: they need broad brush and there are not broad brush as far as litigation is concerned...
Posted Jan 21, 2006 15:29 UTC (Sat)
by bronson (subscriber, #4806)
[Link]
The chances of finding an expert lawyer to go out on a limb like that? Slim to none. The smarter she is, the less she will speculate on areas like this that have very little precedent.
Is the story still valuable even without professional intepretation? Absolutely. It's got a lot of good information. Your "constructive criticism" in this case is misguided and unrealistic.
Posted Jan 19, 2006 2:47 UTC (Thu)
by smitty_one_each (subscriber, #28989)
[Link] (8 responses)
Possibly a subjective assertion.
Posted Jan 19, 2006 4:39 UTC (Thu)
by elanthis (guest, #6227)
[Link] (3 responses)
Posted Jan 19, 2006 10:50 UTC (Thu)
by smitty_one_each (subscriber, #28989)
[Link]
Posted Jan 19, 2006 23:01 UTC (Thu)
by bk (guest, #25617)
[Link]
Posted Jan 26, 2006 17:57 UTC (Thu)
by arcticwolf (guest, #8341)
[Link]
10 lines of Python is so much nicer than 3000 lines of C, especially when they both do the same thing and have near identical runtime efficiency (as most of the work is done in library code, written in C). And it seems pretty silly to count the library code in when you talk about 3000 lines of C but not when you talk about the 10 lines of Python, *especially* when you actually rely on the fact that all Python really does is call C code in order to be able to assert that Python does not impose a efficiency penalty...
Posted Jan 19, 2006 16:07 UTC (Thu)
by RobSeace (subscriber, #4435)
[Link]
Posted Jan 19, 2006 20:31 UTC (Thu)
by mitchskin (subscriber, #32405)
[Link] (2 responses)
At the library level, C is a good choice in a lot of contexts, but when you start writing large applications like Evolution that I think people really start to want something different. Maybe "core" was the wrong word; I thought people used it to include things like Evolution, which is how I meant it.
Posted Jan 19, 2006 23:25 UTC (Thu)
by russell (guest, #10458)
[Link] (1 responses)
Posted Jan 21, 2006 15:32 UTC (Sat)
by bronson (subscriber, #4806)
[Link]
hoooookay, if that's what you want to believe...
Posted Jan 19, 2006 3:43 UTC (Thu)
by njhurst (guest, #6022)
[Link] (9 responses)
(A standard reply to this is that there are no significant gnome or kde projects to use such high level languages making it hard to justify a leap into the dark, but this argument is somewhat self-fulfilling)
Posted Jan 19, 2006 4:27 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link] (2 responses)
Posted Jan 19, 2006 11:58 UTC (Thu)
by rwmj (subscriber, #5474)
[Link]
http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgtk.html
It works very well, and OCaml programs as just about as fast as C programs.
Rich.
Posted Jan 20, 2006 12:59 UTC (Fri)
by massimiliano (subscriber, #3048)
[Link] (4 responses)
IMHO, those languages are very nice, but not many developers understand
them (or any functional language).
You can argue that they should, but they don't, they think "imperative", and cannot see the value of closures, type inference & co, and just pretend that Haskell, Scheme and Ocaml are nothing more than useless intellectual contortions.
Mono has the potential to get the best of both worlds: C# as a language is anyway good for the "mainstream programmer", but the runtime and bytecode can easily support more evolved languages (and the existence of Nemerle and F# is a practical prooof of this). And having a common platform among languages makes things easier when you mix and match them (try using a Python library from, say, Ruby, and contrast this to using a Boo assembly from Nemerle, which is possible today).
And moreover, C# itself is evolving on the same direction...
Posted Jan 21, 2006 16:29 UTC (Sat)
by tzafrir (subscriber, #11501)
[Link] (3 responses)
Posted Jan 21, 2006 22:32 UTC (Sat)
by massimiliano (subscriber, #3048)
[Link] (2 responses)
Yes, it is, but it is too low level.
If you think of it, each one of Python, Haskell, Scheme (and others) must
implement two things: a compiler and a runtime system.
And their runtimes and compilers are all incompatible (again, try using
some Python classes from Scheme, unchanged: you can't).
In the .NET world, they should just provide a compiler, and bingo, you
have everything you need, and full interoperability.
It is the same goal of Parrot, but based on an open standard and an
already mature platform...
I hope I made my point clearer... libc is OK, but it's not enough
for this kind of goal, you need more, and the .NET ECMA specs provide
just that "more".
Posted Jan 25, 2006 2:44 UTC (Wed)
by zblaxell (subscriber, #26385)
[Link] (1 responses)
How can we expect people working on *different languages* to produce compatible runtime code, without that code eventually sucking?
The only thing magical about i386 bytecodes (which is what most of libc is made of) is that it is seriously inconvenient to change; otherwise, there would be new versions of the machine language in the CPU just as often as new compilers come out today.
Posted Jan 25, 2006 6:54 UTC (Wed)
by massimiliano (subscriber, #3048)
[Link]
How can we expect people working on *different languages* to produce compatible runtime code, without that code eventually sucking?
Fairly easy: the people interested in the languages do not
produce the runtime code, they use the exisitng one (with clear
specifications by ECMA and ISO) and produce only a compiler for
their language.
Less work for language people, and less mess for everybody else.
And BTW, their compiler does not need to be ported to any CPU
architecture, it is the runtime that provides the JIT compiler
(and also an AOT one if you want it).
Hopefully, we (runtime people) will provide a runtime that does
not suck ;-)
At least this is the .NET vision of things (which, incidentally,
is in practice also the Parrot one, even if IMHO .NET and Mono
are more mature now).
Posted Jan 26, 2006 20:44 UTC (Thu)
by renox (guest, #23785)
[Link]
It's a bit like Pascal variants, there are some many different functionnal language that none is gathering steam, so it goes nowhere.
On a side note, Scala seems nice (never used it though), that's the first functionnal language I've read about that has a syntax which doesn't suck IMHO (it's not necessarily the first of course, I don't claim to know each functionnal language).
Posted Jan 19, 2006 4:00 UTC (Thu)
by joedrew (guest, #828)
[Link] (2 responses)
Might I suggest C++?
Posted Jan 19, 2006 7:42 UTC (Thu)
by ronaldcole (guest, #1462)
[Link]
Posted Jan 19, 2006 11:06 UTC (Thu)
by ayeomans (guest, #1848)
[Link]
Posted Jan 19, 2006 12:01 UTC (Thu)
by rwmj (subscriber, #5474)
[Link] (2 responses)
Claim 1 is just for remote procedure calls, a technique which has been known and used in computing since the 70s (and probably earlier). Claim 2 is for all of client-server computing. Claim 38 (to pick one at random) covers what has been done in X11 since the mid 80s.
Rich.
Posted Jan 20, 2006 4:20 UTC (Fri)
by roelofs (guest, #2599)
[Link]
Perhaps if you were to go back and reread the article... ;-)
Greg
Posted Jan 25, 2006 2:55 UTC (Wed)
by zblaxell (subscriber, #26385)
[Link]
The usual technique is to file the most broad and comprehensive patent claims you think you can get away with, and then respond to specific points as they are raised by the examiner. If the examiner is paying attention, then you address whatever objections they raised in the most minimal way possible. Lather, rinse, pay a few legal fees, repeat until the examiner isn't paying attention any more.
I haven't figured out how to link directly to the rejection notice, but if you want to read it, go to the Patent Application Information Retrieval site, select Application Number in the "Search Method" dropdown, and enter 10/087027 in the search box. In the page that comes up, click on the "Image File Wrapper" tab. At the moment, the rejection notice is at the top of the list you get.
The .NET API patent, mono, and GNOME
Hopefully this falls into 'constructive criticism', but here goes either way. "What does that mean? Well, ask a lawyer, I guess..." Hello? Hello? You guys are journalists. I pay my subscription to LWN so that you can go out and ask these questions for me. If I wanted completely unfounded bloviations on patent law, I'd go read my own blog :)The .NET API patent, mono, and GNOME
Well AIUI, it means pretty much what it sounds like. Abandoned patent applications don't result in patents. If they miss the deadline due to an unintentional or unavoidable delay, then they can petition to get the application revived. The delay has to be for the whole period they had for replying; an unavoidable delay that crops up in the last week doesn't count.The .NET API patent, mono, and GNOME
The .NET API patent, mono, and GNOME
- Sure - it does not even matter what this actually is (see SCO).
- Ok, let's reprase: how high are the risks for my business ?
- Oh, that's different thing - let' talk about your business...
You seem to be implying that this story is almost meritless (more precisely, has as about much merit as one of your blog entries) unless Jon can find a lawyer who will offer a professional opinion on this matter.The .NET API patent, mono, and GNOME
>Clearly, it would be good to start writing core functionality in something nicer than CThe .NET API patent, mono, and GNOME
Or possibly one born of years of experience writing apps in C and writing the equivalent apps in something else, and seeing how much more efficient writing in something other than C is. 10 lines of Python is so much nicer than 3000 lines of C, especially when they both do the same thing and have near identical runtime efficiency (as most of the work is done in library code, written in C).The .NET API patent, mono, and GNOME
I love Python as well, but the words 'Clearly' and 'core' in the quotation motivated the remark.The .NET API patent, mono, and GNOME
'Near identical runtime efficiency' is true only in terms of absolute running time minus startup overhead. The 10 line Python program uses significantly more RAM (and has significant startup delay) compared to the 3000 line C program.The .NET API patent, mono, and GNOME
The .NET API patent, mono, and GNOME
10 lines of C are so much nicer than 3000 lines of Python, too - what's your point?
Also, that presumes that .Net/C# is "nicer than C", which is somethingThe .NET API patent, mono, and GNOME
I'd need some serious convincing to accept... But, I suppose it does
depend on one's definition of "nicer"... By some definitions, I suppose
you could say that Basic is "nicer" than C; but I still wouldn't want to
write any real-world code in it, either...
Okay, yes, this one was subjective. I figured that the language/VM controversy that GNOME went through in spring 2004 was fueled by people's desire for something nicer. I mean, part of the reason that Miguel was so into Mono was that writing Evolution in C was painful. And that out-of-process Bonobo components didn't perform as well as he had hoped. It's not just the language, it's also garbage collection and the type/component system that I think was part of the draw.The .NET API patent, mono, and GNOME
Is it any surprise that evolution is so buggy or difficult to write, when the authors idea of a fix is to blame the tools rather than the design. "Fixing C" is just introducing more problems, i.e. bloat, patent issues, dividing the community, etc, etc. And all for what, because they didn't want to change evolution's design.The .NET API patent, mono, and GNOME
You're saying they wrote Mono because they didn't want to refactor Evolution??The .NET API patent, mono, and GNOME
If we are looking at using a new language, why not consider far more powerful and elegant languages such as Haskell, Lisp, Ocaml or Mercury? Time and time again people discover that these languages pay off quickly, yet Gnome still argues about tired old C derivatives.The .NET API patent, mono, and GNOME
... produce some code, and we'll look at it.
You're asking other people to produce code in languages they don't know, because you like those languages. It doesn't work that way.
actually the standard reply is ...
We're producing (proprietary) apps for clients in lablgtk2, the OCaml Gtk interface:actually the standard reply is ...
The .NET API patent, mono, and GNOME
Isn't libc such a platform? Why abandon it and force Python, Haskell, Scheme etc. users to use the new platform?The .NET API patent, mono, and GNOME
The .NET API patent, mono, and GNOME
C++ compiler people (and sometimes even C compiler people) routinely fail to produce compatible runtimes between different versions of the same compiler for the same language, despite fairly strict architectural constraints. They apparently do this for performance or correctness reasons, or perhaps to implement new features.The .NET API patent, mono, and GNOME
The .NET API patent, mono, and GNOME
-I don't know Haskell but if I remember well, it doesn't have a debugger, which is a big minus.The .NET API patent, mono, and GNOME
Also I also remember a guy who tried to make a poker server in Haskell and found it easier to use Erlang.
-Many people dislike Lisp due to its syntax.
-On a more personal case: I've tried to learn Ocaml and finally rejected it due to its syntax too. It's still easier on the eyes than Lisp, but apparently it's not gathering much momentum.. Maybe I'm not the only one to dislike its syntax.
-I don't know Mercury nor Erlang and I suppose many people don't either.
But Scala is too new to base a framework like GNOME on it..
> Clearly, it would be good to start writing core functionality in something nicer than CThe .NET API patent, mono, and GNOME
What? When COBOL is practically self-documenting? ;)The .NET API patent, mono, and GNOME
And C++ also supplies backward compatibility for buffer overflows (:-)The .NET API patent, mono, and GNOME
How on earth could someone have granted such an obvious patent?The patent
How on earth could someone have granted such an obvious patent?
um...that's what "application" and "rejection" mean
"How on earth could someone have granted such an obvious patent?"The patent