License for approval

[Bruce Perens]

Alex Wang wrote:
> You are right that one of our intent is to prevent the Microsoft-style
> "Embrace and Enhance". UOML is open standard for document interoperation, it
> will break down the monoplization of Microsoft, we must do our best to
> prevent the destroy from Microsoft.
>   
Well, I sympathize, but what you propose to do can easily be bypassed by 
Microsoft. If Microsoft ever wishes to "embrace and enhance" the UOML 
standard, they can develop their own software instead of using software 
under the proposed license. Thus, the proposed license could end up 
hurting the good guys more than the bad guys.
> The No.1 reason is that UOML is a document interoperation
> standard, thus any incompliance will due to fail of interoperation, even
> though it is a powerful, useful and valuable extension. The only way to
> extend standard is to develope a new version of standard according to open
> standard rule.
>   
Consider what would happen if I were trying to develop a new feature for 
submission to the UOML committee. I would first develop a test 
implementation using the UOML Open Source software, so that I could test 
my idea and prove that it works. And I would distribute it to other 
interested people who would test it. But the UOML license would prevent 
this.

Now, if the license allowed that sort of work, but did not allow me to 
call the result UOML until the committee approved it, that would make 
more sense.

We don't like "Embrace and Enhance", but we want to fight it without 
hurting people who are not part of the fight.

    Thanks

    Bruce
> Thanks.
>
> -Alex
>
> -----Original Message-----
> From: Bruce Perens [mailto:bruce at perens.com] 
> Sent: Sunday, May 25, 2008 1:02 AM
> To: Brian Behlendorf
> Cc: dlwang at sursen.com; allison_shi; liumingjuan;
> license-review at opensource.org
> Subject: Re: License for approval
>
>
> 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
>
>
>