Open Source Licenses and Embrace-Extend-Extinguish

[Rod Dixon]

>>
>> I've worked on a few protocols and document standards over the  
>> years. One thing I've noticed is the tendency of certain players to  
>> either partially support an Internet standard, or add features to  
>> it making it no longer cross-platform. There are too many examples  
>> to list.
>>
>> My question is:  are there any copyright licenses that are open,  
>> but have features designed to combat these practices?

Like Dracula, the "embrace-extend-extinguish" model works best in the  
dark (closed-source), not in the light of open source (where it is  
easier to remove the "bad" extensions from a codebase). When an open  
standard is successfully implemented/expressed as copyrightable  
software, one of the most effective ways to combat attempts to kill  
the open standard is to keep the source code open. Use a license with  
a strong copyleft provision, and you should be fine. No software  
distribution license or software development method will guarantee the  
outcome you desire since (for better or worse) end-users occasionally  
accept "extensions" that take away choices.


Rod Dixon, J.D., LL.M.
roddixon at cyberspaces.org

>>
>>
>> I am interested in licensing a copyright for a protocol. This  
>> protocol is fairly simple, and is designed to be extensible. I  
>> would like to say:
>>
>> ____________________
>>
>> If you use this protocol you must support _all_ features of a major  
>> version.  You may extend the protocol as much as you like provided  
>> your extensions live in this namespace which has been provided for  
>> that purpose. Any implimentation that does not meet these criteria,  
>> will have its license revoked. This copyright is collectively owned  
>> by those who have published software which is in compliance with  
>> these license terms.
>> ____________________
>>
>> My point here, is that people who support and develop free software  
>> and open standards should have some litigious reciprocity available  
>> against vendors who don't play nice. Malicious vendors should be  
>> responsible to everybody they screw, not just the original authors.
>>
>> So anything out there like that?
>> Opinions? Comments?
>>
>> Thanks in advance!
>> Matthew Sibley
>> msibley at itoperators.com
>>
>>
>>
>
>