License for approval

[Bruce Perens]

If someone wanted to make an extended version of the standard, with new 
features that were deliberately not in compliance with the version 
released by the UOML committee, this license would prevent the Open 
Source software from being made compliant with the new extended standard.

That's OK if - and only if - all that will be lost is the right to use 
the UOML trademark. Trademarks are the proper means for protecting the 
perception of a brand such as the UOML standard.

Obviously, the intent is to prevent the Microsoft-style "Embrace and 
Enhance". But it also stops people who are trying to continue the 
viability of the standard in the face of sincere future changes in 
user's needs. So, it ends up saying "thou shalt not innovate, whatever 
your motivation, good or bad."

It also assumes that the UOML committee will always be there to approve 
changes and produce new test suites. And of course they will all go on 
to something else.

    Thanks

    Bruce

Brian Behlendorf wrote:
>
> Let's say I were to implement an experimental new feature in a piece 
> of UOML-licensed code.  This new feature happened to cause your 
> conformance tests to report an error.  It is also a feature that I 
> intend to propose for a new version of the UOML specification.  As a 
> part of building community support for that feature, I need to 
> distribute my patch that implements it, perhaps also the whole package 
> with my new feature added. Yet, a requirement to pass your conformance 
> tests would make that impossible.  This would act as a significant 
> deterrant to innovation and public development.
>
> This and other scenarios are why it's generally better to tie 
> conformance to a standard to a trademark rather than to copyright.
>
>     Brian
>
> On Wed, 21 May 2008, alexwang at sursen.com wrote:
>> The SISSL license doesn't require the software to conform with UOML 
>> standard. This is the kernel term of this license. We expect that all 
>> software based on our project can be interoperable each other, this 
>> goal could be reached by conforming UOML standard.
>>
>> -Alex
>>
>>> Hi Ms. Shi,
>>>
>>> This is useful, but I don't see an answer the question "Why is the UOML
>>> license necessary when the similar SISSL is already available for your
>>> use?" I suspect that Russ was expecting an explanation rather than a
>>> bare statement of where the text differs. Such an explanation should
>>> also answer "Why will the UOML license be a success when the similar
>>> SISSL has failed and is abandoned by its creator?"
>>>
>>>    Thanks
>>>
>>>    Bruce
>>>
>>
>>
>>