(BDumb question that every programmer will ask:
(B
(BCan't someone decide what the "open standards" are and summarise/publish (Bthis information outside of OASIS and IETF?
(B
(Bopensource.org?
(Bfsf?
(Bgroklaw?
(B
(BI dunno who :) This list maybe.
(B
(BHen
(B
(BOn Thu, 24 Feb 2005, Lawrence Rosen wrote:
(B
(B> I heartily concur with Brian's approach. It is a sane response to a problem
(B> caused by an unfortunate OASIS patent policy. The same is true for IETF
(B> standards, by the way.
(B>
(B> Someday, if we insist upon it, OASIS and IETF will tell everyone which of
(B> their standards are "open standards" and which are not. Then the Apache
(B> Foundation wouldn't have to do that analysis for itself. Just imagine the
(B> confusion if our customers had to analyze all the upstream licenses for
(B> stuff we incorporate into Apache code. To the extent possible, we should do
(B> that analysis for them and warn them where necessary.
(B>
(B> /Larry
(B>
(B> Lawrence Rosen
(B> Rosenlaw & Einschlag, technology law offices (www.rosenlaw.com)
(B> 3001 King Ranch Road, Ukiah, CA 95482
(B> 707-485-1242 �� fax: 707-485-1243
(B> Author of ��Open Source Licensing: Software Freedom
(B> and Intellectual Property Law�� (Prentice Hall 2004)
(B>
(B>
(B>> -----Original Message-----
(B>> From: Brian Behlendorf [mailto:[EMAIL PROTECTED]
(B>> Sent: Thursday, February 24, 2005 8:23 AM
(B>> To: [EMAIL PROTECTED]
(B>> Subject: patent licenses on OASIS standards
(B>>
(B>>
(B>> It is the intent of the ASF to distribute its software under the Apache
(B>> Software License, and nothing but. We go to great lengths to accomplish
(B>> this, such as ensuring the right contributor agreements and carefully
(B>> reviewing the licenses on other software we incorporate into ASF
(B>> codebases. We believe the easygoing terms allow for the broadest possible
(B>> use of the code, and in doing so give the greatest chance to building
(B>> healthy and large development communities. We also believe that the
(B>> simplicity of being able to say "here's the AL, it describes all the
(B>> requirements you must fulfill in order to use, copy, modify, etc" is
(B>> important. Third-party copyright notices may require that folks retain
(B>> information about copyright lineage, but can't impose additional
(B>> restrictions.
(B>>
(B>> We fought hard for this approach within the JCP - not accepting a
(B>> requirement, for example, that we only be allowed to release strictly
(B>> conformant implementations, but accepting the provision that we can't use
(B>> the related trademarks except on implementations that pass the relevant
(B>> TCKs.
(B>>
(B>> The IETF's policy in 1994, as captured in RFC 1602 section 5.4.2,
(B>> http://www.ietf.org/rfc/rfc1602.txt, took an out-of-sight, out-of-mind
(B>> approach to the problem - simple and elegant but also not realistic given
(B>> the rampant software patenting that has happened the last 15 years. The
(B>> W3C and OASIS standards groups have had to address the issue; the W3C
(B>> after much deliberation arrived at a Royalty-Free default for all
(B>> standards (there may be exceptions, I don't claim perfect knowlege).
(B>>
(B>> OASIS recently issued a statement allowing for two "modes" for any given
(B>> working group: Royalty-Free (though there may be other stipulations), and
(B>> Reasonable and Non-Discriminatory (RAND). While an improvement over what
(B>> came before, RAND licensing would not allow for Apache-licensed
(B>> implementations. It even appears that the RF licenses on many OASIS
(B>> standards in existance today that would require us to add requirements to
(B>> the Apache License for particular packages upon our end-users.
(B>>
(B>> To be on the up-and-up, and make good on our promise to Apache software
(B>> recipients that our software is legally free and clear for them to use as
(B>> they expect, we should take a look at the OASIS standards we implement
(B>> today. We should make sure that the patent notices that participants in
(B>> OASIS have attached to these standards are RF, and not RAND.
(B>>
(B>> We should also determine whether the RF licenses presents other
(B>> requirements that we'll need to pass along to our own licensees. We may
(B>> need to compromise on our ideal, that the AL represents the entire license
(B>> for the code, if we feel it's important as an organization to implement
(B>> OASIS-defined specifications. It's tempting and easy to be dogmatic and
(B>> say "no implementations of standards with any encumbrances, period", but
(B>> keeping the Internet an open playing field by being the reference
(B>> implementation and the best implementation of next-gen protocols may be a
(B>> stronger ideal. Though, we should not allow any requirements (such as
(B>> only applying to conformant applications) that would be impossible to
(B>> fulfill with an OSI-compliant license.
(B>>
(B>> Dims has collected a list together of the projects and the OASIS standards
(B>> they implement, at:
(B>>
(B>> http://wiki.apache.org/general/ReviewsNeeded
(B>>
(B>> Comments? At the end of this process it would be nice to be able to make
(B>> a public statement about standards, IP, and Apache; but we need to get our
(B>> own house cleaned and decide what our own policy should be before doing
(B>> so.
(B>>
(B>> Brian
(B>>
(B>>
(B>> ---------------------------------------------------------------------
(B>> DISCLAIMER: Discussions on this list are informational and educational
(B>> only, are not privileged and do not constitute legal advice.
(B>> ---------------------------------------------------------------------
(B>> To unsubscribe, e-mail: [EMAIL PROTECTED]
(B>> For additional commands, e-mail: [EMAIL PROTECTED]
(B>
(B>
(B> ---------------------------------------------------------------------
(B> DISCLAIMER: Discussions on this list are informational and educational
(B> only, are not privileged and do not constitute legal advice.
(B> ---------------------------------------------------------------------
(B> To unsubscribe, e-mail: [EMAIL PROTECTED]
(B> For additional commands, e-mail: [EMAIL PROTECTED]
(B>
--------------------------------------------------------------------- DISCLAIMER: Discussions on this list are informational and educational only, are not privileged and do not constitute legal advice. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
