Mono Developer Meeting

by John Sequeira

Related link: http://primates.ximian.com/~miguel/MonoMeet.html



I was really glad I was able to make it to the mono conference on Friday. There were a lot of interesting folks to meet among the attendees and the Novell hosts, and I learned a lot about mono's prospects that changed my thinking about the project.


The issue at the top of my mind was patents, and I was immensely happy that Miguel addressed the situation both to our table and the room of attendees. He said that he was highly motivated to get mono into Red Hat, and that Red Hat would not allow mono in unless it had gone through a patent review. Miguel and Novell legal staff are currently conducting a formal patent review of mono, and the team had already split up the components of mono into separate ECMA-based and non-ECMA components (WinForms, ADO.NET, etc) to clearly define what RedHat and others could make use of.


Importantly, Miguel also said that Ximian had a letter from Microsoft, Intel and HP stating that they would offer *royalty-free* RAND licensing to the ECMA-submitted components of .NET. [Aside: He said they were kicking around catchy names like 'polio' or 'cholera' to distinguish the free and non-free stacks] I told Miguel he should publicize the letter more because it was such a relief to me, but he said it would be premature to promote this before the patent review was complete in case other infringement was uncovered.


So it looks like there will be a useful and useable amount of mono that is as free of IP issues as any software, which I hadn't believed prior to attending the meeting. That is the current state of pre-1.0 mono, but what about the future? Miguel admitted that Longhorn and Whidbey and essentially any and all future Microsoft releases could be based on non-free IP. At every release the focus of Microsoft's tools that provide a compelling Linux development environment could break or prevent mono-compatibility the same way Microsoft's J++ broke Java compatibility by replacing JavaBeans, RMI,and JNI with COM, DCOM, Direct/J. At that point, you would face the choice of either forking the API's or forking over some royalty payments.


While this uncertainty looms in the future, mono is mature enough that Ximian can begin to execute on their ironic game plan: embrace and extend. Although mono exists to make life easier for Windows developers looking to migrate to alternate platforms, at some point they will need to stop chasing tail-lights and create their own ecosystem of compelling code and tools. The rest of the meeting included presentions of current initiatives advancing towards this goal. I had to head out early, and so missed all the non-Miguel presentations, but I had enough time to grill the developers of what I suspect will be the first big win of the Novell-Ximian-mono combo. For that you'll have to wait until my next post.


Does mono have a chance? What's your pick for the first big mono win?


3 Comments

nzheretic
2004-03-11 15:47:50
As one of critics of t
nzheretic
2004-03-11 17:38:30
As a critic of the Mono patent position...
As a long time critic of the Mono projects position on the Microsoft patents, I am relieved that after more than a year since the patent issues were raised, Miguel and Novell legal staff are currently conducting a formal patent review of mono.


But even if the project is split into two distinct partitions of ECMA-based and non-ECMA components, how easy is it going to be for the third part developers adding components to the ECMA-based partition to know that he is not treading on Microsoft's patents by implementing functionality defined in Microsoft's .NET patents?


nzheretic
2004-03-11 18:06:10
Being green does not necessarily mean patent free
For example, in the graphic from the patents section of the Mono FAQ...
http://primates.ximian.com/~miguel/tmp/map.png


XmlRpc.NET and RelaxNG will likely confict with Microsoft's patent application 20020059425 : Distributed computing services platform.


Although there is prior art examples of individual technologies such as the JVM etc, Microsoft patents such as the one mentioned, define and claim the interoperation of the components and their .NET platform.


There is NO way to work-around the issue, no amount of renaming the API calls or reimplementing the methords used will invalidate the patents.