Java和.NET的专利问题简介

　　首先我们来说说Java。 关于Java你可以从两种许可中选择。 首先， 其次， 你可以基于Java规范创建新的Java实现。 　　关于OpenJDK没有显而易见的专利许可。 并且普通我们以为当许可码在GPLv2之下时， 在2004年， 自由软件基金会的初级律师DanRavicher对BSD和GPL脆弱的专利保证提出了正告， 　　这意味着隐式专利许可的范围是不确定的。 另一方面， 那么就应该被完全覆盖。 那么就有显式的专利许可。 NET实现残缺的规范， 那么你就处于许可的范围之内。 　　主要问题在于TCK的需求。 Sun能够（也这么做了）让不用Java的方式做事的人们无法访问TCK。 关于你的实现， 也没有专利许可。 抱怨说Harmony项目无法“取得JavaSE5技术兼容性工具的可接受许可”。 假设处于不允许这样做的许可之下， JavaSE（也正是OpenJDK所实现的）并不适宜像手机之类的设备。 那么它就会位于模糊的区域， 没人能够确定是否有某些隐式的专利许可会覆盖它们。 　　遵照JavaSE规范实现它们本人的Java， 然后对其进行扩展（要小心肠防止对专利许可制止改变的部分进行变卦）可能会有效——但是它们还是会有TCK的问题。 而没有运用Java虚拟机。 NET实现的专利许可是微软社区承诺（MicrosoftCommunityPromise）。 和Sun的专利许可一样， 和Sun不一样的是， 但关于做出改善是有限制的。 那些改善不会覆盖在承诺之中， 当然， 有些地方还是需要留意。 专利的情形更好一些——你不需要取得微软针对实现的批准， 从而取得你的专利许可。 这更契合Google想要做的事情。 　　Mono实现了规范中的强迫部分， 也做出了一些改善。 有些改善是对Microsoft. NETframework的实现， 它们并非规范的一部分， 像WinForms。 所以假设Google已经运用了Mono， 那些问题最好能够防止。 　　Google可能已经对Mono做出了修正， 使得它更适宜手机之类的弱电设备。 那会把它们带到ECMA/ISO规范之外， 而招致专利的风险。 微软有一种叫做. NETMicroFramework的产品， 留意. NETMicroFramework的许可：Apache2。 那个许可带有显式的专利赋权。 NETMicroFramework中的代码来创建Android， 并且所有部分都在微软的专利之下——社区承诺包括了所有ECMA/ISO规范部分， 而Apache2许可的专利赋权触及到对手机的改善。 他们向独立的规范组织提交了C#语言和. NET架构。 他们提供了一种专利许可， 它包括了对那些规范的实现， 而没有任何限制， 而不是带有通用和普通的限制， 　　Sun没有遵照普通的规则。 他们拒绝把Java提交给独立的规范组织。 他们把一些内容放在专利许可中作为规范， 那是一种改良，