3 ms·

I hate to bring this up but, as I have been spending more time hacking on open source Mono projects I can't help but ask what the legal future for Mono is curre

I hate to bring this up but, as I have been spending more time hacking on open source Mono projects I can't help but ask what the legal future for Mono is currently (last I heard they where working on splitting out the possibly patented code). Does anyone have any input on this?

icey 16y ago
It's a pretty valid question. The mono homepage has some info that may be useful: http://www.mono-project.com/MonoConcerns http://www.mono-project.com/MonoConcerns
xpaulbettsx 16y ago
It's mostly a settled issue, I wouldn't worry about it.
tzs 16y ago
The are three cases. 1. Code in Mono that implements things covered by EMCA/ISO standards. These have about the same legal risk as any other EMCA/ISO programming languages and libraries. 2. Code in Mono that covers Windows-specific things, like WinForms. This is your highest risk area, although even in these areas the risk is probably pretty low. That's because Microsoft patents would cover the particular way Microsoft did these things. Mono's independent cloning of the functionality is likely to have done them a different way. If you want to be maximally safe, don't use these parts of Mono. Use GTK#, for instance, for your GUI stuff. (That runs on Windows, BTW, if you want your Mono app to run on Windows). 3. Code in Mono that covers things not in the ECMA/ISO standard, but not specific to Windows. This would cover things like libraries developed after the current rev of the standard, and such. Most of these provide functionality that exists in most other language ecosystems, such as Python, Ruby, Perl, and so on. If Microsoft has patents in these areas, they are as likely to cover Python, Ruby, etc., as they are to cover Mono. Microsoft has been known to encourage the Mono developers. That greatly weakens any case they would have against Mono. Bottom line: it's about legally as risky as the other languages and ecosystems that would be its competitors, especially if you stay away from things like WinForms. If you would feel legally comfortable doing something in Ruby or Python or Perl, doing the same thing in Mono should be fine.

icey 16y ago

It's a pretty valid question. The mono homepage has some info that may be useful: http://www.mono-project.com/MonoConcerns http://www.mono-project.com/MonoConcerns

xpaulbettsx 16y ago

It's mostly a settled issue, I wouldn't worry about it.

tzs 16y ago

The are three cases. 1. Code in Mono that implements things covered by EMCA/ISO standards. These have about the same legal risk as any other EMCA/ISO programming languages and libraries. 2. Code in Mono that covers Windows-specific things, like WinForms. This is your highest risk area, although even in these areas the risk is probably pretty low. That's because Microsoft patents would cover the particular way Microsoft did these things. Mono's independent cloning of the functionality is likely to have done them a different way. If you want to be maximally safe, don't use these parts of Mono. Use GTK#, for instance, for your GUI stuff. (That runs on Windows, BTW, if you want your Mono app to run on Windows). 3. Code in Mono that covers things not in the ECMA/ISO standard, but not specific to Windows. This would cover things like libraries developed after the current rev of the standard, and such. Most of these provide functionality that exists in most other language ecosystems, such as Python, Ruby, Perl, and so on. If Microsoft has patents in these areas, they are as likely to cover Python, Ruby, etc., as they are to cover Mono. Microsoft has been known to encourage the Mono developers. That greatly weakens any case they would have against Mono. Bottom line: it's about legally as risky as the other languages and ecosystems that would be its competitors, especially if you stay away from things like WinForms. If you would feel legally comfortable doing something in Ruby or Python or Perl, doing the same thing in Mono should be fine.