sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] Issue 132: Sanjay's Proposal - Discussion
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: OASIS Assembly <sca-assembly@lists.oasis-open.org>
- Date: Thu, 29 Oct 2009 09:35:12 +0000
Jim,
1) Can the test suite accommodate proprietary
implementation types?
I think the answer is "yes".
It would be ideal if there were some documentation describing how
to build a version of the testcase suite for
implementation.xxx, but I don't think
the test suite itself needs any changes now.
2) License to apply to the test suite
artifacts
I think that we could use Apache 2.0
license and then make it a requirement for conformance that any runtime
which claims conformance
using a new implementation type must
also make a version of the test suite available under the same license.
So, while Apache 2.0
does not imply copyleft, we can make
it a requirement of claiming conformance.
I am very wary of GPL in a context where
the SCA runtimes are likely to be commercial implementations under commercial
licenses.
I even have a problem with GPL in relation
to Apache Tuscany ;-)
GPL would certainly involve me in long
discussions with lawyers, not something that I look forward to doing...
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:
| Jim Marino <jim.marino@gmail.com>
|
To:
| OASIS Assembly <sca-assembly@lists.oasis-open.org>
|
Date:
| 28/10/2009 18:15
|
Subject:
| Re: [sca-assembly] Issue 132: Sanjay's
Proposal - Discussion |
Hi,
I was unable to respond earlier but I wanted to say I
like Sanjay's proposal. Mike, do you feel the test suite can accommodate
the ability to support "proprietary" implementation types? My
impression is yes, although there it may require a few tweaks.
Other comments inline.
Jim
On Oct 28, 2009, at 10:24 AM, 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.
In terms of test suite code, I believe OASIS has this
same issue regardless of supporting proprietary implementation types. Specifically,
vendors will need to make implementations of RuntimeBridge (i.e. the code
that bootstraps a runtime in the test harness) publicly available. In other
words, this issue should be addressed regardless of the outcome of Issue
132.
In terms of a license, I'm not a lawyer but I do know
ASL 2.0 does not place license restrictions on derivative works so it is
probably not a good candidate. My suggestion would be to look at GPL v.3
with the GNU Classpath exception. That would place license restrictions
on derivative works but also make clear that runtime code does not fall
under those restrictions. Potentially, another clause could be added to
the license that requires the Description Document to be made publicly
available.
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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]