[UOML] License for approval

[Lawrence Rosen]

Wang Donglin wrote:
> 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.

This is not a problem of coming up with the right wording. I don't think you
have a language problem with your license. The issue is that you're trying
to do something with an open source copyright license that isn't consistent
with the OSD. Once you give someone the right to create derivative works,
you can't (in an open source license) say "except for certain kinds of
derivative works...."

Open source copyright licenses cannot be used to prevent people from making
any modifications to the software that they want. They may be obliged to
provide notices of their changes, or to remove trademarks and certification
marks that no longer apply to the modified software, or sometimes even to
publish the source code of their changes, but they can't be prevented from
varying from your compliance standards. Their changes may cause their
software to infringe patents, or may violate some other contractual or legal
limitation that they've accepted to obey and for which they are liable, but
the open source part of all this is *free for anyone to modify however they
choose for any purpose*. 

There are many reasons why the open source community doesn't allow industry
standards to dominate our freedom to modify software. Brian's earlier email
gave some good ones. I hope you can reconcile your particular Java standard
with that form of openness, or you will be unlikely to find allies in the
open source community.

/Larry


> -----Original Message-----
> From: Wang Donglin [mailto:dlwang at sursen.com]
> Sent: Sunday, May 25, 2008 12:32 AM
> To: license-review at opensource.org
> Cc: 'allison_shi'; 'liumingjuan'
> Subject: RE: [UOML] License for approval
> 
> 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
> >
> >
> >