Return-Path: 
 <legal-discuss-return-6831-apmail-legal-discuss-archive=apache.org@apache.org>
X-Original-To: apmail-legal-discuss-archive@www.apache.org
Delivered-To: apmail-legal-discuss-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 5D72176A6
	for <apmail-legal-discuss-archive@www.apache.org>;
 Tue, 15 Nov 2011 13:58:09 +0000 (UTC)
Received: (qmail 87862 invoked by uid 500); 15 Nov 2011 13:58:09 -0000
Delivered-To: apmail-legal-discuss-archive@apache.org
Received: (qmail 87501 invoked by uid 500); 15 Nov 2011 13:58:08 -0000
Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:legal-discuss-help@apache.org>
List-Unsubscribe: <mailto:legal-discuss-unsubscribe@apache.org>
List-Post: <mailto:legal-discuss@apache.org>
Reply-To: legal-discuss@apache.org
List-Id: <legal-discuss.apache.org>
Delivered-To: mailing list legal-discuss@apache.org
Received: (qmail 87494 invoked by uid 99); 15 Nov 2011 13:58:08 -0000
Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Nov 2011 13:58:08 +0000
Received: from localhost (HELO mail-vw0-f50.google.com) (127.0.0.1)
  (smtp-auth username robweir, mechanism plain)
  by minotaur.apache.org (qpsmtpd/0.29) with ESMTP;
 Tue, 15 Nov 2011 13:58:08 +0000
Received: by vws9 with SMTP id 9so7534420vws.23
        for <legal-discuss@apache.org>; Tue, 15 Nov 2011 05:58:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.34.207 with SMTP id b15mr42915870vdj.19.1321365487381; Tue,
 15 Nov 2011 05:58:07 -0800 (PST)
Received: by 10.220.218.139 with HTTP; Tue, 15 Nov 2011 05:58:05 -0800 (PST)
In-Reply-To: <4EC25D14.9050702@apache.org>
References: 
 <CAP-ksogA9Y-tbwHRkyJ4cNvwuKfaFsu4xJgYX_iudaG7tgzAPw@mail.gmail.com>
	<4EBD0CF2.8090601@apache.org>
	<CAP-ksoh4GPFwjB7z8F=br10b_84c7x4O-5HzEgaExTXwvyD2Yg@mail.gmail.com>
	<4EC25D14.9050702@apache.org>
Date: Tue, 15 Nov 2011 08:58:05 -0500
Message-ID: 
 <CAP-ksojJVR2Jcc43H_+5C-3wtao1aaD-ZGd5VXt18_pw9UpDFA@mail.gmail.com>
Subject: Re: License classification: Schema files for OASIS Open Document
 Format (ODF) standard
From: Rob Weir <robweir@apache.org>
To: legal-discuss@apache.org
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 15, 2011 at 7:37 AM, Robert Burrell Donkin
<rdonkin@apache.org> wrote:
<snip>
>
> IMHO there is tension in http://www.apache.org/legal/resolved.html
> between http://www.apache.org/legal/resolved.html#category-b and
> http://www.apache.org/legal/resolved.html#no-modification
>

Yes.   Although there is a natural sympathy between open standards and
open source, a standard is not source code, and an open standard is
not open source.

Open standards are typically based on granting the following permissions:

1) Permission freely to read and redistribute the standard.  (As
opposed to, say, ISO standards which require payment to acquire a copy
of a standard and which then do not allow redistribution).

2) Sometimes (but not always) permission to create derivative works
for translation, etc. But I'm not aware of any standards body that
encourages user to modify the standard in an incompatible way outside
of the committee process.  So the "right to fork" generally does not
exist with standards.

3) An IPR statement that generally encourages royalty free
implementation of the standard, typically by having participants in
the standardization process agree to make their patent claims
available to implementors of the standard, often with an reciprocity
clause (if you sue us, we can sue you).

We should also note that standards are evolving and becoming more
technically sophisticated.  It is common now for standards to embed
within them machine readable definitions.  Sure, it has always been
the case that you might have s snippet of BNF or similar in the spec.
But now we're seeing lengthy XML schemas,  source code, and other
definitions.  For example, OOXML, contains in the spec the definitions
of dozens of drawing shapes, defined in terms of DrawingML vector
markup. Anyone who wants to create a compatible application will need
to use these definitions.  That is the intent of including them in the
spec, to improve interoperability.

The other thing that is different about standards compared to code is
how standards are embedded in legislation and regulation.  Although it
would be improper in most countries for legislation or regulation to
require a vendor's specific software application, it is very common to
require the use of a specific standard.  So one of the keys to public
sector procurement is the support of applicable open standards.   For
open source, including Apache open source products, to thrive in this
area, we obviously need strong support of open standards.  And this
certainly has been the tradition.  We need a way to continue this
tradition, even as standards are increasing in sophistication.


> IMHO Apache should resolve this tension by applying a common exception
> (Category-S, say) clause to both weak-copyleft and no-modification. I'll
> raise this separately.
>

Maybe allow no-modification inclusion of standards which are open
(free, redistributable and royalty free)?

> Robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org