<html><body>Thanks Everyone! <br><br>I looked at the SISSL, and I like it. Suprised it isn't more popular in fact. <br><br>Micheal, you make a lot of great points. I have to consider the differences between practices and doctrine here. While technically my proposed license concept could get you in trouble for beta-testing and bugs, in practice I can't really see this happening. The difference between proprieterization and a bug at a network protocol level can be expressed in terms of marketshare for a given distro. Big market = propreterizing, Small market = bug. And for the gray area, fair warning aught to do the trick. <br><br>Regarding protocols being copyrightable, I'm pretty sure they can be. They are just formats after all. Formats like DVD and GIF (or was it jpeg?) are legendary for their IP issues. So can a format holder dictate what the format is used for? It doesn't matter. They only need to dictate that the format is consistent. Can damages be caused by inconsistency of format? Absolutely. So their probably is some precedents here, I'm just too lazy to look them up at the moment :-) <br><br>Thanks again! <br>Matthew Sibley <br><br><br>
<blockquote webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px;">
-------- Original Message --------<br>
Subject: Re: Open Source Licenses and Embrace-Extend-Extinguish<br>
From: Michael Poole <mdpoole@troilus.org><br>
Date: Wed, February 13, 2008 2:42 pm<br>
To: license-discuss@opensource.org<br>
<br>
<a href="http://email.secureserver.net/pcompose.php#Compose" onclick="Popup.composeWindow('pcompose.php?sendto=msibley%40itoperators.com'); return false;">msibley<b></b>@itoperators.com</a> writes:<br>
<br>
> My point here, is that people who support and develop free software and open<br>
> standards should have some litigious reciprocity available against vendors who<br>
> don't play nice. Malicious vendors should be responsible to everybody they<br>
> screw, not just the original authors.<br>
><br>
> So anything out there like that?<br>
> Opinions? Comments?<br>
<br>
Off hand, and based partly on many previous discussions of that<br>
essential question, there are at least five major problems:<br>
<br>
1. If enforceable, this would violate criterion 6 of the Open Source<br>
Definition (no discrimination against fields of endeavor).<br>
<br>
2. It would make it impossible for anyone to release an in-progress<br>
version of software that supports the standard, which is a common<br>
practice among open source developers.<br>
<br>
3. It would not stop extend-and-extinguish tactics like those used in<br>
some directory services -- where a vendor's server implements<br>
proprietary extensions in the proper name space and the vendor's<br>
clients effectively require those extensions.<br>
<br>
4. It leaves anyone who releases buggy software (and that's everyone)<br>
at risk of legal action if their bugs alter the program's behavior<br>
with respect to the protocol implementation.<br>
<br>
5. It would probably not be enforceable at all for a redistributable<br>
standard: the copyright license on the protocol definition would not<br>
impose obligations on those who implement the protocol.<br>
<br>
Perhaps the most feasible compromise is to publish a test suite for<br>
both sides of the protocol and require any software to pass that<br>
before it may implement extensions to the protocol. This would<br>
resolve #2 and #3, and maybe #4, from the list above. I believe this<br>
is roughly the approach that Sun tried with Java. They obviously did<br>
not care about #1 at the time, and used non-copyright licenses to<br>
address #5.<br>
<br>
Michael Poole<br>
</blockquote></body></html>