Re: [sca-assembly] Issue 132: Sanjay's Proposal - Discussion

[Mike Edwards <mike_edwards@uk.ibm.com>]

Eric,

Comments inline...

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

From:	Eric Johnson <eric@tibco.com>
To:	Mike Edwards/UK/IBM@IBMGB
Cc:	sca-assembly@lists.oasis-open.org
Date:	28/10/2009 21:03
Subject:	Re: [sca-assembly] Issue 132: Sanjay's Proposal - Discussion

---

My thoughts:

As to the "Description Document", this seems to me like a perfect
fit for the Creative Commons licenses (http://creativecommons.org
- perhaps we have to enumerate the acceptable ones?).  I don't know
if you have to demand URL addressability, because people will laugh at
you if it isn't (does a document exist if I cannot download it from the
web?).

<mje>
CreativeCommons is one approach, I agree
</mje>

I don't think you want to say that is available to "read without charge",
because "charge" is very difficult to pin down.  People
might want to read it on paper - who pays for the printing?  What
if the document happens to be large - who pays for the bandwidth? 
If it is freely copyable based on the license, then vendors attempts to
charge (unreasonably) for the original copy downloaded from their site,
they will immediately be undermined by annoyed people posting the document
elsewhere.

<mje>
Yes, tricky, but I am concerned in case anyone
has to sign up to anything before they can see this document.
"Charge" is relevant I think -
asking people to pay simply to see a copy online is what I don't want to
see.
Some organizations do this.
</mje>

Here's a slightly trickier question - what's the point of the description
document?  I gather the aim is to document the implementation type,
not to make it possible for anyone else to also implement said implementation
type?  Because if it is the latter, then we'd need some language that
specifically indicates some sort of patent conveyance, in addition to having
the freedom to simply copy the document describing the technology.

<mje>
Go look at our SCA OASIS specs - the Notices
section ;-)
There are limited terms expressed there concerning
IPR licensing.

Separately, I am not sure that we can insist
on the implementation type being open for anyone to implement.
I would encourage the creation of documents
that are open for implementation by anyone - and for commonly
available languages, this would be the best.
 But that may not be the case for some specialized languages
used only in restrictive environments (I'm
thinking of some of the Siemens scenarios here)
</mje>

As to the software test suite, I think we should consider separately the
license of the Assembly-TC provided test suite, and the one that we want
to require be delivered by the vendor in this scenario.  I think the
appropriate license for the vendor provided "proof of interoperability"
is almost certainly Apache 2.0 (http://www.apache.org/licenses/LICENSE-2.0.html). 
Why?

• Apache license includes a clause related to patents, one which is not found in either the LGPL or GPL v2 license.  I further cannot see any significant (legitimate) patents being required for  a test suite, so this shouldn't be a high hurdle.
• Any GPLv3 (which does have a patents clause) based test-suite would then include code that would then be difficult to incorporate in other circumstances other than with other GPL licensed code.  For example, the test suite might reveal code useful code that companies might want to incorporate into their own test suites, or that might work in the official SCA Assembly test suite, or that help to interoperate with the implementation type provided by the vendor, and so on....
• The goal of the license on the test suite is not to encourage contribution back to the vendor of any changes to the test suite, as LGPL or GPL would do.  Rather, it is for everyone else to be comfortable running and modifying the test suite to fit the test suite into environments that it wasn't originally written for.

We probably
also want to be clear that we don't want to prevent dual licensing of either
the description document or the corresponding test suite.  That way,
if a vendor wants to release the test suite also under a license that better
fits their business model, whether that be a full GPL license, or a completely
proprietary one, that should be OK.

<mje>
I agree with you on these points.
On the third bullet, the reason for considering
GPL style licensing is that it forces the modified test suite artifacts
to be made available publicly and freely.
However, we can as an alternative merely
state the free availability is a requirement for claiming conformance
</mje>

One last point - I'm uncomfortable with one aspect of this - a vendor gets
to write a description document, but we've not laid out any clear criteria
here for what would be minimally acceptable.  Do we think we can?

<mje>
That is one concern with Sanjay's approach.

I think that we can describe what a Description
Document must contain - it is only a question of how much work this would
be.
We could write and publish such a document.
</mje>

-Eric.

Mike Edwards wrote: 

Folks, 

We had an interesting but short discussion of this proposal on our TC call
yesterday.  I'd like to follow up on that discussion.

I think that the main points that have been made about this proposal concern
the term "publicly available" that is used in relation to
both the Description Document for the new implementation type and in relation
to the Modified Assembly Test Suite that uses the 
new implementation type for all of its low-level implementation artifacts.

There was also a point made about any limitations with respect to functionality
that a new implementation type might have and 
how these might be handled. 


1) "Public Availability" of the Description Document and the
Test Suite 

This has been at the heart of my concerns relating to relaxing the current
requirements. 

With everything published as OASIS, we are assured of the kind of public
availability that we desire.  Once we move away from
that, things get harder to pin down. 

Remember that the reason for making these stipulations is to allow for
the "court of public opinion" to be used as a
method of policing any claim made for conformance.  Only by having
the materials on which the claim is based openly 
available to anyone will it really be possible for this mechanism to work.

"Public Availability" of the Description Document.  This
I think is tough to organise.  My thought is that we want the capability
for 
anyone to obtain a copy of the Description Document without being tangled
up in needing to agree any restrictive license terms.
We could stipulate that the Description Document: 
- must be available on a public website 
- must be available for anyone to read without charge
- must be available on license terms which are equivalent to the OASIS
license for the SCA Assembly specification, or which are more permissive
However, I recognise that this is not so easy to specify in a way which
can guarantee the kind of open access that we might
desire. 

Regarding the Test Suite code, we could attach a form of open source license
to the current Assembly test suite artifacts which
requires publication of any modified test suite under the same license
(eg GPL or LGPL).  This might seem heavy handed but
it would give certainty about the availability of the code of a modified
test suite.  The alternative would be to choose a less
onerous license (eg Apache 2.0) but then require that the modified test
suite is made available under that same license in order
for the implementation type to qualify as "conforming" to SCA
Assembly.   

I note that in either case, we must be clear that there is absolutely no
requirement for the SCA runtime relating to the implementation
type to be made available - the terms applying to the runtime itself can
be whatever (commercial) terms the company concerned 
might choose. 



2) Handling of Limitations of Functionality of a new Implementation Type

This is a tough question, since we have not really faced an implementation
type which has restrictions. 

The problem I forsee is that if (say) we had an implementation type that
could not provide SCA properties, then there is a set
of the Assembly testcases that such an implementation type would inevitably
fail.  The failures imply that the runtime using that
implementation type as its (only) implementation type would not be able
to claim conformance to SCA Assembly. 

I am not sure that we are ready to deal with this at the moment.  I
think that we shall have to wait until we are presented with an
implementation type with restrictions.  At that point, we can properly
assess the restrictions and I think that the best idea would
be to create a "profile" - define a set of function that applies
to that style of implementation and a subset of the Assembly test
suite that it would have to pass.  This is for some future version
of the test suite.  I think we should ignore it for the present and
require that all the test suite is passed. 



Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

From:	"Patil, Sanjay" <sanjay.patil@sap.com>
To:	<sca-assembly@lists.oasis-open.org>
Date:	21/10/2009 00:56
Subject:	[sca-assembly] Issue 132: Proposal

---

With the current conformance
criteria for SCA Runtime (section 13.2 of the SCA Assembly specification),
it is not possible
for vendors to claim
conformance with
SCA by using runtimes
that support
only proprietary
SCA implementation
types (and do
not support any
of the OpenCSA defined
standard implementation types).
I think it is in the interest of
the OpenCSA
member companies
to promote a
broader adoption
of the SCA standard and not introduce
any hurdles that are not absolutely necessary. As it was apparent
(at least to me)
from the
discussion on today’s
(10/20) SCA Assembly TC’s conference
call, we are ourselves
not fully convinced that the
current conformance criteria is
necessary. It seems
that we are ready
to maintain the status quo of the current conformance criteria
primarily because
the alternative of
defining a well thought
out and commonly agreed upon solution
along with all the right legalese is going to be challenging and time consuming.
While I agree with
this concern, I don’t think maintaining the status quo
provides us the right
path forward.

If we must come up with a quick solution, I would propose that we take the route of relaxing the conformance requirements and make the SCA standard more accessible (from a conformance perspective) now -- in its very first release. As part of a future release, we can then think about how to set up a level playing field by imposing the same IP terms for both the OpenCSA defined implementation types and the vendor defined implementation types.

Please see below for my proposal for resolving the Issue 132. The language of the proposal many need some tweaking but I hope that it has sufficient clarity to be considered as a formal proposal.

Thanks,

Sanjay

Proposal:

Resolve the Issue 132 by replacing the current text of Section 13.2 (SCA Runtime) with the following (which essentially removes the item 4 and updates the item 3 of the current text) :

An implementation that claims to conform to the requirements of an SCA Runtime defined in this specification MUST meet the following conditions:

1.      The implementation MUST comply with all statements in Appendix C: Conformance Items related to an SCA Runtime, notably all MUST statements have to be implemented.

2.      The implementation MUST conform to the SCA Policy Framework v1.1 Specification [Policy].

3.      The implementation MUST support at least one implementation type standardized by the OpenCSA Member Section or comply with the following rules for at least one of the other implementation types:

a.      The implementation type is defined in compliance with the SCA Assembly Extension Model (Section 10 of the SCA Assembly Specification).

b.      A document describing the mapping of the constructs defined in the SCA Assembly specification with those of the implementation type is made publicly available. Such a document should help in understanding how SCA components can be developed using the implementation type, how these components can be configured and assembled together (as instances of Components in SCA compositions). To get an idea about the purpose and scope of such a document that describes the implementation type, see the Client and Implementation specifications for the implementation types standardized by the OpenCSA Member section.

c.      An adapted version of the SCA Assembly Test Suite for testing the implementation type is created and is made publicly available.

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU