Compromisso de especificação aberta da Microsoft

Publicado em: 12 de setembro de 2006 | Atualizado em: 15 de fevereiro de 2008

A Microsoft compromete-se, de forma irrevogável, a não entrar com uma reclamação contra você por criar, usar, vender, oferecer para venda, importar ou distribuir qualquer implementação desde que a referida implementação esteja em conformidade com uma Especificação Abrangida ("Implementação Abrangida"), sujeita aos termos a seguir. Esse é um compromisso pessoal, assumido pela Microsoft com você, e você reconhece como uma condição para beneficiar-se do mesmo que nenhum direito da Microsoft é recebido de fornecedores, distribuidores ou de quaisquer outros em conexão com este compromisso. Caso você ajuíze, mantenha ou voluntariamente participe em qualquer ação de infração de patente contra uma implementação da Microsoft de tal Especificação Abrangida, esse compromisso pessoal não se aplica com relação a qualquer Implementação Abrangida da mesma Especificação Abrangida feita ou usada por você. Para fins de esclarecimento, as "Reivindicações Essenciais Microsoft" são aquelas reivindicações de patentes de propriedade da Microsoft ou por ela controladas que são indispensáveis para implementar somente as partes necessárias da Especificação Abrangida que são descritas em detalhe e não apenas mencionadas em referida Especificação. As "Especificações Abrangidas" estão relacionadas abaixo.

Esta promessa não é garantia de que (i) alguma das reivindicações de patente emitidas pela Microsoft abranja uma Implementação Abrangida ou seja exeqüível, ou que (ii) uma Implementação Abrangida não infringiria patentes ou outros direitos de propriedade intelectual de eventuais terceiros. Nenhum direito, exceto aqueles expressamente estipulados neste compromisso, será considerado como outorgado, renunciado ou recebido, seja implicitamente, por exaustão, preclusão ou de algum outro modo.

Nesta página
Especificações Abrangidas (o compromisso se aplica individualmente a cada uma dessas especificações)Especificações Abrangidas (o compromisso se aplica individualmente a cada uma dessas especificações)
Perguntas Mais FreqüentesPerguntas Mais Freqüentes
Feedback de Representantes da ComunidadeFeedback de Representantes da Comunidade

Especificações Abrangidas (o compromisso se aplica individualmente a cada uma dessas especificações)

Este compromisso se aplica à versão identificada das especificações a seguir. Quaisquer novas versões de especificações anteriormente cobertas a serem acrescentadas à lista serão consideradas separadamente. Em conexão com as especificações listadas a seguir, este Compromisso também se aplica aos elementos necessários de partes opcionais de tais especificações.

Serviços da Web (Web Services)

Este compromisso se aplica a todas as versões dessas especificações, existentes na data do compromisso, 16 de outubro de 2006. Muitas dessas especificações estão passando atualmente por padronização adicional em certas organizações de normatização. Na extensão em que a Microsoft esteja participando dessas iniciativas, este compromisso também se aplicará às especificações que resultarem dessas atividades.

Perfil de Dispositivos para Web Services (DPWS)

WS-Federation PRP (Passive Requestor Profile)

Perfil de interoperabilidade do seletor de identidade v1.0

Perfil básico do WS-I

Protocolo de Web Services do shell remoto

WS-Management

SOAP

Catálogo do WS-Management

Vinculação de SOAP 1.1 para MTOM 1.0

WS-MetadataExchange

SOAP MTOM / XOP

WS-Policy

SOAP-sobre-UDP

WS-PolicyAttachment

Perfil de interoperabilidade de logon único da Web

WS-ReliableMessaging

Protocolo de intercâmbio de metadados de logon único da Web

WS-RM Policy

WS-Addressing

WS-SecureConversation

WS-AtomicTransaction

WS-Security: Vinculação do Kerberos

WS-BusinessActivity

WS-Security: Perfil de token do Kerberos

WS-Coordination

WS-Security: Perfil de token REL (linguagem de expressão de direitos)

WS-Discovery

WS-Security: Perfil de token SAML

WSDL

WS-Security: Segurança de mensagem SOAP

Extensão de vinculação WSDL 1.1 para SOAP 1.2

WS-Security: Perfil de token de nome do usuário

WS-Enumeration

WS-Security: Perfil de token do certificado X.509

WS-Eventing

WS-SecurityPolicy

WS-Federation

WS-Transfer

Perfil do solicitante ativo do WS-Federation

WS-Trust

Especificações de virtualização

Especificação de formato de imagem VHD (Virtual Hard Disk, Disco Rígido Virtual)

Segurança

RFC 4406 - Sender ID: E-Mail de autenticação

RFC 4408 - Estrutura de diretrizes do emissor: Autorização de uso de domínios no campo "Mail From"

RFC 4407 - Endereço do suposto responsável em mensagens de e-mail

RFC 4405 - Extensão do serviço SMTP para indicar o remetente responsável de uma mensagem de e-mail

Formatos de arquivo em XML do Office

Esquemas de referência XML do Office 2003

Office Open XML 1.0 – Ecma-376

Robótica

Protocolo de serviços descentralizados de software - DSSP/1.0

Início da páginaInício da página

Perguntas Mais Freqüentes

O compromisso de especificação aberta é uma forma simples e clara de garantir que o mais amplo público de desenvolvedores e clientes que trabalham com software comercial ou de código-fonte aberto possa implementar especificações através de um método de compartilhamento de ativos técnicos, mas ao mesmo tempo reconhecendo a legitimidade da propriedade intelectual.

Ouvimos opiniões de representantes da comunidade, que fizeram comentários positivos com relação à aceitabilidade dessa abordagem.

OSP geral

P: Por que a Microsoft adotou essa abordagem?

R: Era uma forma simples e clara, dentre as várias abordagens de licenciamento possíveis, de garantir ao mais amplo público de desenvolvedores e clientes que a(s) especificação(ões) poderia(m) ser usada(s) gratuita e facilmente, hoje e sempre.

P: Como funciona o Compromisso de Especificação Aberta? Tenho que fazer alguma coisa para obter o benefício desse OSP?

R: Ninguém precisa assinar, nem fazer menção a nada. Todos estão livres para implementar as especificações da forma que desejarem; não há necessidade de fazer qualquer menção ou referência à Microsoft. Todos podem usar ou implementar essas especificações com suas tecnologias, códigos, soluções etc. Deve-se concordar com as condições estipuladas para poder se beneficiar do compromisso; no entanto, não é preciso assinar um contrato de licença ou, de outra forma comunicar à Microsoft sua concordância.

P: O que é coberto e o que não é coberto pelo compromisso de especificação aberta?

R: O OSP (compromisso de especificação aberta) abrange cada uma das especificações apontadas na lista pública disponibilizada em http://www.microsoft.com/interop/osp/. O OSP se aplica a todos que estiverem criando software e/ou hardware para implementar uma ou mais dessas especificações. Pode-se optar por implementar as especificações total ou parcialmente. O OSP não se aplica a nenhum trabalho feito fora do âmbito das especificações abrangidas.

P: Se uma especificação listada tiver sido aprovada por uma organização de padronização, quais direitos de patente a Microsoft irá prover?

R: Estamos provendo acesso às reivindicações essenciais em conformidade com o âmbito de nossos compromissos com a organização em questão.

P: E se eu não implementar a especificação inteira? Terei ainda assim as proteções do OSP?

R: O OSP é aplicado independentemente de você fazer uma implementação total ou parcial. Em ambos os casos, você pode contar com nosso compromisso irrevogável. De toda forma, o OSP cobre apenas a implementação das partes das especificações que você decidir usar.

P: Esse OSP se aplica a todas as versões do padrão, inclusive revisões futuras?

R: O compromisso de especificação aberta se aplica a todas as versões existentes das especificações apontadas na lista pública disponibilizada em http://www.microsoft.com/interop/osp/, salvo exceções declaradas a respeito de uma determinada especificação (consulte, por exemplo, as notas específicas relacionadas a especificações de serviços da Web).

P: Por que o OSP não se aplica a coisas que estão apenas mencionadas na especificação?

R: É prática comum que licenças de tecnologia se concentrem nas especificidades daquilo que se encontra descrito nas especificações e excluam aquilo que, com freqüência, é chamado "tecnologias habilitadoras". Se considerássemos reivindicações de patentes como tecnologia habilitadora, poder-se-ia argumentar, em caso extremo, que são necessárias patentes de computador e sistema operacional para implementar quase toda especificação de tecnologia da informação. Jamais foram dadas, para padrões de mercado específicos, licenças de patente amplas para tecnologias mencionadas.

P: O OSP é sub-licenciável?

R: Não há necessidade de sub-licenciamento. Este compromisso se aplica diretamente a você e a qualquer um que queira utilizá-la. Portanto, seus distribuídos, clientes e fornecedores podem se beneficiar diretamente deste mesmo compromisso, tendo exatamente a mesma proteção que você.

P: O compromisso é coerente com o licenciamento de código-fonte aberto, denominado GPL? Qualquer um pode implementar as especificações sem ter que se preocupar com patentes da Microsoft?

R: O compromisso de especificação aberta é uma forma simples e clara de garantir que o mais amplo público de desenvolvedores e clientes que trabalham com software comercial ou de código-fonte aberto possa implementar as especificações abrangidas. Cabe àqueles que implementam essas tecnologias compreender os ambientes jurídicos em que operam. Isso inclui as pessoas que operam em ambiente de GPL. Como a GPL (licença pública geral) não é interpretada da mesma forma universalmente, não podemos fornecer qualquer parecer jurídico sobre como nossa linguagem se relaciona com o GPL ou outras licenças OSS; porém, tendo por base os comentários da comunidade de código-fonte aberto, acreditamos que um amplo público de desenvolvedores pode implementar as especificações.

SEGURANÇA

P: Por que vocês estão colocando a Sender ID no OSP agora?

R: Em setembro deste ano, a Microsoft anunciou uma nova abordagem da disponibilidade de especificações abertas. No momento em que anunciamos a aplicação do Compromisso de Especificação Aberta a 38 especificações de serviços da Web, e mais recentemente, neste mês, o expandimos para incluir a especificação do formato de imagem de disco rígido virtual. Nesse momento, acreditamos poder promover uma maior interoperabilidade do setor entre todas as soluções comerciais de software que utilizem autenticação de e-mail, incluindo soluções de código-fonte aberto tornando a Sender ID mais claramente disponível em todo o ecossistema da internet, incluindo clientes, parceiros, ISPs, registradores e a comunidade de desenvolvedores. Essa abordagem complementa o comprometimento mais abrangente da Microsoft de combater a disseminação de spam, práticas de phishing, malware e outras práticas indevidas relativas a e-mail, bem como interoperabilidade, que alcançado em parte habilitando pela disponibilização ao acesso à nossa tecnologia.

P: Vocês estão disponibilizando a Sender ID no OSP por terem recebido tantas críticas por sua abordagem original do licenciamento para a especificação?

R: Reconhecemos que há questões que persistem de alguns membros da comunidade de desenvolvimento sobre os termos de licenciamento da Microsoft e como esses termos podem afetar a capacidade dos desenvolvedores em implementar a Sender ID. É importante observar que já foi feito um grande progresso em autenticação de e-mail em todo o mundo com mais de 5 milhões de portadores de domínios adotando a Sender ID como uma prática recomendada atualmente. A Sender ID ajuda a proteger marcas, reduzir o spam e combater práticas indevidas de e-mail. O OSP é um modo simples e claro de renovar a confiança de um amplo público de desenvolvedores e clientes de que quaisquer patentes da Microsoft alguma vez exigidas para implementar toda ou parte da especificação poderiam ser usadas gratuita e facilmente, hoje e sempre.

P: Qual a importância do OSP para a Sender ID?

R: Estendendo o OSP para o formato de Sender ID, a Microsoft ajudará o setor a combater o spoofing e phishing por e-mail, estimulando maior interoperabilidade entre todas as soluções de software comercial para autenticação de e-mail, incluindo soluções baseadas em código-fonte aberto. Os implementadores da Estrutura de Sender ID não precisarão se preocupar em assinar uma licença a fim de implementar a tecnologia antispoofing e antiphishing. Essa abordagem também complementa o comprometimento mais amplo da Microsoft com a interoperabilidade, que alcançamos em parte permitindo o acesso à nossa tecnologia.

A Microsoft está comprometida em trabalhar com o setor e empresas de TI para ajudar a proteger os consumidores e empresas da praga das ameaças on-line. A Estrutura de Sender ID é uma especificação de autenticação que ajuda a resolver o spoofing de domínios – uma tática comum usada para a disseminação de spam, phishing, malware e outras práticas indevidas relativas a e-mail – verificando o nome do domínio a partir do qual o e-mail é enviado.

Após quase dois anos de implementação em mais de 600 milhões de usuários em todo o mundo, a Sender ID já conta com amplo suporte do setor industrial, com aproximadamente 36% de todos os e-mails legítimos enviados em todo o mundo compatíveis com a Sender ID e uma estimativa de 5,5 milhões de domínios em todo o mundo protegidos pela Sender ID. A adoção entre os citados na Fortune 500 aumentou de 7% um ano atrás para mais de 23% hoje.

A autenticação de e-mail e a capacidade de validar a identidade se tornaram essenciais diante do aumento da sofisticação e ameaças on-line sendo propagadas. Com a Sender ID, as redes emissoras e receptoras passam a dispor de uma camada adicional de segurança e proteção contra esses práticas indevidas.

A Sender ID proporciona valor comercial significativo sem custo e impacto no desempenho. As empresas de hoje, em todo o mundo, estão materializando o aprimoramento da marca e a proteção do usuário, concretizando também o aumento da capacidade de distribuição de e-mails legítimos. Com a adição da Sender ID e a reputação do emissor, é possível reduzir os falsos positivos a quase zero e reduzir os falsos negativos em mais de 80%.

P: Onde posso fazer o download das especificações da Sender ID?

A:
RFC 4406 - Sender ID: Autenticação de E-mail
RFC 4408 - Estrutura da Diretiva do Emissor: Autorização do Uso de Domínios no Campo "Mail From"
RFC 4407 - Endereço do Suposto Responsável nas Mensagens de E-mail
RFC 4405 - Extensão do Serviço SMTP para Indicação do Emissor Responsável de uma Mensagem de E-mail

Formatos de arquivo em XML do Office

P: O que vocês estão fazendo com a adição do Ecma Office Open XML ao OSP?

R: Estamos concedendo aos potenciais implementadores do Ecma Office Open XML a capacidade de se beneficiarem do CNS ou do OSP, o que escolherem. A Microsoft já declarou que oferece um CNS pacto de não promover ação judicial irrevogável para qualquer pessoa que deseje implementar os formatos. Entendemos que alguns podem preferir o novo OSP, o que gostaríamos de facilitar.

P: Por que vocês estão fazendo isso agora?

R: Em setembro, o Comitê Técnico do Ecma criou o Esboço Final dos formatos Office Open XML v1.0 de modo que podemos tratar de quaisquer questões que as pessoas possam ter com respeito a sua capacidade de usar nossos direitos de patente que venham a ser necessários para implementar o Ecma Office Open XML. Não queremos que existam quaisquer questões em aberto com relação ao acesso a reivindicações essenciais de patente da Microsoft.

P: Por que vocês estão empregando tanto o CNS quanto o OSP?

R: Alguns perguntaram se aplicaríamos o OSP ao Ecma Office Open XML. Não sabemos se alguns escolherão o OSP em vez do CNS, mas queremos que essa seja uma opção.

Início da páginaInício da página

Feedback de Representantes da Comunidade

OSP geral

“A Red Hat acredita que o texto do OSP dá flexibilidade suficiente para implementar as especificações listadas em software licenciado por licenças gratuitas ou de código-fonte aberto. Louvamos os esforços da Microsoft em ouvir os representantes da comunidade de código-fonte aberto e solicitar seus comentários sobre o texto, bem como a boa vontade da Microsoft em fazer modificações em resposta a nossos comentários”.

Mark Webbink
Vice-presidente do Conselho Geral
Red Hat, Inc.

“O compromisso de especificação aberta da Microsoft é uma evolução muito positiva. Na universidade e nas comunidades de código-fonte aberto, precisamos saber que podemos implementar especificações gratuitamente. Esse compromisso tornará mais fácil para nós a implementação de protocolos de serviços da Web e placas computacionais, bem como utilizá-los em nossas comunidades”.

RL "Bob" Morgan
Presidente, MACE (Comitê Educacional em Arquitetura Middleware)
Arquiteto de Tecnologia Sênior, Universidade de Washington

SEGURANÇA

"A extensão da Microsoft de seu Compromisso de Especificação Aberta para o Sender ID é um passo positivo para a comunidade de e-mail. Ele elimina as questões com licenciamento ao considerar os métodos de autenticação de e-mail e ajuda os remetentes e receptores de e-mail a se concentrar na tecnologia".

David Cole
Vice-presidente Sênior
Operações de Rede e Centro de Dados da AOL

"A segurança do e-mail é essencial para proteger a confiança do cliente on-line. É importante que toda a comunidade adote plataformas interoperáveis, de fácil implementação e de baixo custo para encorajar a ampla adoção de ferramentas para combater as fraudes de spoofing e phishing por e-mail. Louvamos a Microsoft nessa iniciativa de fomentar a melhoria da cooperação do setor".

Ramesh Lakshmi Ratan
Vice-presidente Executivo e Executivo-Chefe de Operações
DMA (Associação de Marketing Direto)

"Os membros da ESPC há muito reconheceram a necessidade de soluções robustas contra spam que ajudem a garantir a entrega de e-mail legítimo, e nós acolhemos positivamente o anúncio de hoje da Microsoft como outro passo positivo para a distribuição de e-mails seguros e autênticos".

Trevor Hughes
Diretor Executivo
ESPC (Coalizão de Remetentes e Provedores de E-mail)

"Como provedor líder de segurança de gateway de Internet, estamos interessados em ver os melhores produtos antispam chegarem ao mercado para aumentar a confiança e segurança no e-mail. O movimento para a especificação do Sender ID sob o OSP é um movimento importante da Microsoft, e esperamos que resulte em ampla adoção em todo o setor".

Patrick Peterson
Vice-presidente, Tecnologia
IronPort Systems Inc.

"As tecnologias de autenticação do emissor como o Sender ID são ferramentas importantes que ajudam a garantir a segurança do e-mail e, tornando o Sender ID disponível sob o OSP, a Microsoft está lidando com as necessidades de interoperabilidade de infra-estruturas heterogêneas de e-mail. Estamos satisfeitos em ver esse desenvolvimento e acreditamos ser um passo positivo no combate ao spoofing, phishing e outras categorias de mensagens indesejadas".

Eric Allman
Executivo-Chefe de Ciências
Sendmail Inc.


Início da páginaInício da página