Novell and Xamarin Partnership around Mono
tirania.org
tirania.org
Xamarin gets IP -- meaning they don't have to do a clean-room, source-compatible reimplementation of MonoTouch and Mono for Android, and all the risks that go with that -- in exchange for taking on the support of Novell's existing customers. Customers they probably want anyway.
Novell/SUSE gets to get out of the Mono business altogether, which is probably good for them seeing as they laid off the entire engineering staff.
The Mono community gets some clarification about the stewardship of the project. Novell contributed a lot of resources (bug tracker, mailing list and wiki hosting, etc.) and now Xamarin is on the hook for that stuff. It helps clarify the future of the project.
That said I think this goes beyond IP for Xamarin. As you said they get the existing customers but they're also available to new customers a few months earlier. Mobile development is growing blazingly fast right now and even a months delay can mean someone decides to go with another product.
With the major financing that companies like Appcelerator have gotten Xamarin needs all the advantages it can get.
With Xamarin the Mono folks have some skin in the game beyond a paycheck and their own passion. Even if Miguel were to walk away -- something I find unlikely -- there is a business now that depends upon its success and not some neglected division within a rudderless company.
The idea of a safety net for projects like these is just an illusion. There's never a safety net. You've just got to take things as they come and have a backup plan.
Surely both "partners" are supposed to do something? I don't see Novell lifting a finger here except to abandon their existing Mono customers, get rid of all Mono IP (Mono has IP?) and in every way shape and form wash their hands of the whole thing.
That's good for Xamarin I guess - and kudo's to them if they can make it all work. I'm not sure this is a "win" for Mono - but I guess it's the best of a bad situation.
So the fact that they have signed an agreement that gives Xamarin a perpetual license to all the intellectual property of Mono, MonoTouch, Mono for Android, Mono for Visual Studio, etc, is fantastic for any existing customers which use these products.
This outcome is the best possible outcome given the circumstances.
Mono has IP?
In Mono's case only Novell/Attachmate were able to dual license the runtime libraries, otherwise licensed under LGPL, making it unsuitable for the demands of companies wanting to embed Mono in games (just an example).
Also, MonoTouch and MonoDroid are commercial products and Xamarin had no right to distribute or use in any way any source code or binaries from those projects; meaning they had to start from scratch in producing alternatives which would have been in a gray area, not to mention waisted effort.
You can mix LGPL and proprietary code. I see no reason LGPL libraries would prevent embedding Mono.
- proprietary extensions are not possible
- dynamic linking is mandatory
- the whole hassle of including any tools or data
for recompiling said LGPL library and
reproducing the executable
- the patents grant is implicit rather than explicit
Create a second library that links to the LGPL one and extends its behavior.
> dynamic linking is mandatory
It's also good practice most of the time.
> the whole hassle of including any tools or data for recompiling said LGPL library and
Only if you change it. If you didn't change it, you can just redistribute the tarball you used.
> the patents grant is implicit rather than explicit
It's still there.
> Just because you can do something, it doesn't mean you want to.
I get it you don't want it, but, just because you don't want it doesn't mean you can't
LGPL code is not magically perfect. I've modified most third party libs I've used. If those are LGPL, I have to make sure those changes get back to the public. I either have to put messages on the game screen about where to get the code, or I have to ship the code on the disc. This is simply not going to happen in most corp environments without extensive lawyer say-so. As an independent, github make fulfilling this obligation a lot easier and I've used it for that purpose.
However there is a second problem. In some situations (iOS for example, but there are others with broken build pipelines) a separate "Library" does not work. The code must be compiled in directly. Is it now no longer a library for legal purposes? If not, then the whole product is now covered by GPL. Fuck. That is just not something that can be risked. Sorry.
So instead I only use software that is "Free" as in "Freedom to do what I want with it", like BSD, MIT or Apache.
As a developer, I sure enjoy the freedoms BSD and MIT grant me. If I held a lot of patents, I wouldn't be so happy with Apache.
OTOH, as a user, I appreciate the rights *GPL software gives me.
BSD vs. GPL is a user rights vs. developer rights thing. You use your license as a tool to achieve the balance you intend to reach.
BTW, the way Canonical used the AGPL with Launchpad is brilliant. I never imagined that license could be that useful.
It is. It creates a lot of potential targets for the mother of all patent lawsuits (IIRC, the community promise only covers the ECMA standard). Don't forget that, when Microsoft exits a market, it still owns a lot of patents in that space and can thus act like an NPE.
> they will discover that Mono is inferior to "real" .Net.
OTOH, it runs on far superior OSs ;-)
Would it be if it succeeded grabbing market share from Windows? Definitely.
I fail to see your reasoning equaling "something didn't happen" with "something can't ever happen and you are a lunatic for believing it can".
And I know I get downvoted every time I point this out. Reminding people Microsoft never plays nice only makes me unpopular, but it doesn't make me wrong.
No "srs bsns" enterprise .NET developers care about Mono. But the vast, vast majority of their stuff would, if necessary, run on Linux via Mono without much trouble--because most people just don't use the complex stuff that Mono doesn't support.
I use Mono for my current project (a cross-platform game library) because it, unlike everything else aside from C/C++, is capable of effectively targeting OS X, Linux, Android, and iOS. .NET gives me Windows, Xbox 360, and WP7.
- Wrote a brief (4 hours perhaps) Windows Forms app that did some math. Ran it on Mono. To Mono's credit, it did run. But to my horror, it actually computed incorrect results.
- I used a popular UI widget library for .Net. Turns out though most of it was written in C#, it had a number of Windows-only DLL imports, and could not run on Mono.
- At the time, ASP.net support was barely functional, if it existed at all. To be fair, I'm not sure if this is still the case or not.
Further, I will offer this additional argument. It is widely known that Java's promise of "write once, run anywhere" is a joke. Not that cross-platform Java can't be done (in fact it can), but it does take deliberate effort to ensure cross-platform support. And this is Java, which has official support for Linux (i.e., the JVM code on Linux is basically the same JVM code on Windows).
Contrast the Java situation with MS .Net, which does not have official support for Linux, but does have the option of Mono on Linux. MS .Net and Mono are two totally separate environments built out of separate code-bases. In this situation you are almost guaranteed to run into major migration headaches, if not outright barriers.
Now perhaps you are running from Mono from the start; well of course that is going to work. My original point isn't that Mono doesn't work when running code actually targeted to it; that may well be the case. My point is that Mono gives traditional .Net developers the false belief that they can run their Windows-targeted .Net code on Linux easily. For most, or at least many, that is simply not the case.
To be fair, at least for desktop apps, we are down to three platforms now. If it runs on Linux, Mac and Windows, you are about 100% covered. The days of having dozens of vendor-specific Java runtimes around are pretty much over. And as much as I like my IBM RS/6000 workstation, I wouldn't try to run Eclipse on it.
Or was it nine lives? Ah, nevermind.