[UOML] License for approval

[Wang Donglin]

Brian, Bruce and other license review team member,

Thanks for your kindly help. Your experience is a good education to us.
Regarding requirement of standard compliance, It seems that strict
requirement is necessary for interoperation(e.g. Java), or every one can add
new feature for their own requirement, and that will kill interoperation
standard. This requirement is the life of this kind of standard. The case of
test new feature is not so important, and we can try to define some rule to
meet this requirement, such as distinguishing it from normal software
releasing, give it a loose condition. I beleive we can find a way to
properly distinguish them.
Sorry for my poor English. Any misunderstanding, contact me please.

-Alex
-----Original Message-----
From: Brian Behlendorf [mailto:brian at hyperreal.org] 
Sent: Sunday, May 25, 2008 4:39 AM
To: Wang Donglin
Cc: 'allison_shi'; 'liumingjuan'; license-review at opensource.org
Subject: Re: [UOML] License for approval


On Sun, 25 May 2008, Wang Donglin wrote:
> Thanks for your thought, which is very helpful.
> Regarding the case you supposed, I think we can solve it by giving up 
> requirement to under-development software, until it is released to 
> public user.

I might not know ahead of time who else is interested in the new feature I 
am working on.  So, I have to release it publicly, so that I have a chance 
of attracting those other contributors to my work.  It is certainly 
possible to have a private development community who tosses a source code 
tarball over the wall with an open source license, but I've never heard of 
a project that can do that successfully.

> Trademark is not a good choice for our case. UOML is a new standard, 
> has not been recognized by end user. Not use UOML trademark is not a 
> big loss. Trademark can't prevent verdor to develope their own 
> software based on open source contribution, not conform with UOML 
> standard while don't use UOML trademark.

Like Bruce, I sympathize with your goal of producing lots of 
standards-conformant software.  I presume you have other goals as well - 
widespread adoption of your software by end-users, rapid innovation of 
UOML tools to keep up with the other competitors in the space, and perhaps 
even incorporation of UOML parsing/rendering/editing technologies into 
other commercial products.  Even if the UOML license were to be certified 
as an OSI-Approved Open Source license, it is my opinion that it would 
disincent innovators and commercial providers from adopting the 
technology; and so it might fulfill one goal at the expense of possibly 
all others.

These days, a more direct route to a widespread and consistantly 
implemented common standard is a reference implementation, production 
quality, under a very liberal Open Source license.  For example, no one 
wastes any time debating the conformance of the Python interpreter to the 
definition of the Python language - the implementation is the standard. 
Where it deviates from its own documentation, either the code is fixed or 
the documentation is fixed.  The same energy and money that would have 
been invested in a standards body is instead invested in coding. 
Standards documents are just pseudocode anyways.  ODF and OpenOffice is a 
close comparable situation; ODF wouldn't have had a chance if OOo hadn't 
production quality.

 	Brian
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
>
>
>