[UOML] License for approval

[Brian Behlendorf]

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