This article could have been titled;
"Novell gets rid of Mono Customers" or "Xamarin now Mono-alone" but instead it's spun as "Novell/Xamarin Partnership around Mono". Don't you love good PR?
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.
Attachmate has no obligation to do anything. They could just discontinue MonoTouch, Mono for Android, etc, and all existing customers would be left up shit creek without a paddle.
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.
Some of the best people that worked on Mono are now working for Xamarin, including Miguel de Icaza who started it all. Getting support from Xamarin is the best kind of support you can get on Mono, MonoTouch and MonoDroid.
Mono has IP?
Yes it has. Just because a project is open-source that doesn't mean it isn't protected by IP laws.
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.
> 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).
You can mix LGPL and proprietary code. I see no reason LGPL libraries would prevent embedding Mono.
Off the top of my head, here's a few reasons why someone may dislike the LGPL:
- 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
Just because you can do something, it doesn't mean you want to.
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.
Comments
This article could have been titled; "Novell gets rid of Mono Customers" or "Xamarin now Mono-alone" but instead it's spun as "Novell/Xamarin Partnership around Mono". Don't you love good PR?
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.
Attachmate has no obligation to do anything. They could just discontinue MonoTouch, Mono for Android, etc, and all existing customers would be left up shit creek without a paddle.
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.
Some of the best people that worked on Mono are now working for Xamarin, including Miguel de Icaza who started it all. Getting support from Xamarin is the best kind of support you can get on Mono, MonoTouch and MonoDroid.
Yes it has. Just because a project is open-source that doesn't mean it isn't protected by IP laws.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.
> 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).
You can mix LGPL and proprietary code. I see no reason LGPL libraries would prevent embedding Mono.
Off the top of my head, here's a few reasons why someone may dislike the LGPL:
Just because you can do something, it doesn't mean you want to.> proprietary extensions are not possible
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
Short answer: Because lawyers cost money.
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.
> 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.