[Mono-list] RE: Is it Mono safe?

Rick Kitts rkitts@loudhouse.org
Thu, 20 May 2004 21:09:23 -0700


I really have not been at all clear. I apologize. I don't care if MSFT 
tries to kill Mono. I don't think it can. I don't care of MSFT tries to 
kill Linux. I don't think it can.

MSFT realizes it's advantages through it's ubiquity. It maintains it's 
ubiquity through unfair means. Hiding APIs, gratuitously changing 
formats and protocols and so forth. When I was running Linux on a 
laptop a few years ago it was flat out impossible to participate in my 
companies calendaring things because the Exchange calendaring protocol 
is secret. I didn't choose Linux because I hate MSFT, I chose it 
because I write code and there is no better platform for coding than 
unix. Before this realization I didn't give a whit about MSFT and 
monopolies and so forth.

I suggest that broad adoption of the CLR tends to enhance or enable 
continuing MSFT ubiquity. I suggest that MSFT has used it's ubiquity in 
such a fashion as to make them an undesirable member of the development 
world I want to live in. One in which the free flow of information is 
more valuable than making more than enough money, where the best 
solution is what is sought and not the one which sells the most this 
quarter.

Accepting this the ethical question is, should MSFT be helped? 
Rejecting this terminates the discussion. I think rejecting the premise 
entirely though is an abdication of responsibility.

I'll stop now. I didn't realize how touchy this was.

---Rick


On May 20, 2004, at 7:28 PM, Nik Derewianka wrote:

> Rick Kitts wrote:
>
>> On May 20, 2004, at 2:03 PM, Jeffrey Stedfast wrote:
>>
>>> you are confusing the issue. it's not the idea that can limit your
>>> freedom, it's the implementation that can.
>>>
>>> that said, your concerns becomes moot.
>>>
>> I'm sorry but I don't understand what you're saying.
>
> The processor heat reduction helps you and your computing industry.  
> Your useage of that IDEA does not in anyway help the Societ Govt etc.  
> Your paying the soviet union for the processors that implement that 
> idea would help the soviet govt.
>
> Likewise - C#, the idea of a multi-lingual VM, CLI, CTS etc alone are 
> good ideas (and not original to MS).  Using them to help you produce 
> better code in a shorter time does not help microsoft if you use it on 
> your own implementation.  It does help them if you exclusively use 
> only their implementation on their OS and place yourself under their 
> control.
>
> There are way too many factors for microsoft to overcome to kill mono 
> that it makes it highly unlikely that it will ever succeed.
>
> First - there is no single entity that they can shut down, they would 
> have to contest every contributors copyright in every country that 
> they come from (with different views on IP laws) and succeed in EVERY 
> SINGLE CASE for them to have a chance at stopping the distribution of 
> the CURRENT source.   Those developers would still be free to create a 
> workaround and continue after a setback - witness the SCO debacle and 
> the approach all the authors had to working around the problem.
>
> Secondly - as pathetic as the DoJ has been in doing anything remotely 
> resembling curtailing of MS's abuse of its monopoly position, it can 
> still incur scrutiny from watchdogs if it attempted to do something so 
> blatant as trying to kill competition from mono.  The EU might even 
> actually add some bite to it with a punishment.  Then there is the 
> court of public opinion - industry pundits would have a field day 
> sensationalising Microsofts blatant abuse of monopoly power (yet 
> again).
>
> Thirdly - as Miguel pointed out - unfortunately most development 
> scenarios are now patent encumbered already.
>
> At the end of the day - your taking a risk:
> is it any bigger than using any other language ??(probably not)
> would it be insurmountable to overcome any obstacles ??(probably not)
> Do you get the benefits of this technology immediately to help you and 
> your projects ?? (yes)
>
>
> Regards,
> Nik
>