spf-discuss
[Top] [All Lists]

RE: MASG Protocol Guidelines

2004-12-14 14:47:10
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Mark 
Shewmaker
Sent: Saturday, December 11, 2004 4:05 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] MASG Protocol Guidelines


On Sat, 2004-12-11 at 15:46, Scott Kitterman wrote:
On Sat, 11 Dec 2004 14:04:17 -0500 Mark Shewmaker 
<mark(_at_)primefactor(_dot_)com>
wrote:
1.  Protocols must not require the use of any licenses
   which would have the effect of noticeably slowing deployment,
   or have the effect of making implementation noticeably  more
   difficult.

It would be equally problematic if proprietary implementations were
prohibited.  Solutions need to be open to all.

Solutions that are effectively not open to proprietary implementations
would then slow (proprietary) deployment and make implementation more
difficult.

Non-Open Source implementors probably won't have so much of a problem
with patent licenses that require reciprocal licensing or some sort of
don't-sue-me-and-I-won't-sue-you type terms, but even these types of
restrictions can sometimes be incompatible with the OSD.

That's my reasoning for a more general description combined with a more
specific and Open Source related addendum.

I wanted to cover both bases, but there's probably a better way to word
all this.  (Any alternative wording suggestions?  :-)  )

OK. When I read it, I didn't read it that way...

How about:

Specifically, the protocol must not require the use of any licenses which
would mean that resulting implementations would necessarily be incompatible
with the licenses of major mail programs (e.g. MTAs, MUAs, spam filters,
etc.).  This includes both Free/Open systems and proprietary systems.
E-mail technology must be open to all implementors.  This may require
multiple licensing in some cases.

In the case of Free/Open software, protocols must not be incompatible with
the Free Software Foundation's Free Software Definition, Software in the
Public Interest's Debian Free Software Guidelines, the Open Source
Initiative's Open Source Definition, or incompatible with either the latest
version of the Free Software Foundations's GNU Public License (GPL) or the
Apache Software Foundation's Apache License.

For proprietary implementations, this would preclude protocols licensed
exclusively on GPL like terms.

Scott Kitterman


<Prev in Thread] Current Thread [Next in Thread>