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?).
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.
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.
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.
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?
-Eric.
Mike Edwards wrote:
OFBC4F72C0.3FF431F6-ON8025765D.0049B17E-8025765D.004EF4E9@uk.ibm.com"
type="cite">
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
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
|