Hi Kieran,
On the subject of Contributors License Agreement, I just wanted to
make sure we're talking about the same thing (for my peace of
mind :-) ). SCA_SDO has two licenses, one which covers people using
the project (this is just the standard Apache 2 license and is linked
to in the code copyright statements), and one which covers people
contributing code to the project. The second license is there to
ensure that anyone contributing code and intellectual property has the
right to do so. This is in place to protect contributors and users of
the project (see Apache, Zend Framework and eZ Component for other
projects which use CLAs).
The Contributors License Agreement is as follows and can be found in
the downloadable package. The process is to send a completed copy to
the email address mentioned in the agreement. If you choose to
complete and send the agreement, please could you copy me on the note
so I know where we are :-) . Let me know if you have any questions
about this (BTW: I'm still trying to find out about the project name
change - SDO changed to SCA_SDO).
Is this the license you were referring too?
SDO for PHP: Individual Contributor License Agreement ("Agreement")
Thank you for your interest in the SDO for PHP Project, a project that
IBM has
contributed to and is moving forward with the open source community.
In order to
clarify the intellectual property license granted with Contributions
from any
person or entity, the SDO for PHP project requires all contributors to
submit an
individual Contributor License Agreement ("CLA"), indicating their
agreement to
the license terms below. This Agreement is for your protection as a
Contributor, as well as for the protection of the Project and its
users as a
whole; in particular, it is not intended that this Agreement should
change any
of your rights to use your own Contributions for any other purpose.
If you have not already done so, please complete and send the
Agreement to SDO
for PHP project at [EMAIL PROTECTED] Please read this document
carefully
before signing, and keep a copy for your records.
Full name: --------------------
E-Mail: --------------------
php.net user ID: --------------------
Mailing Address: --------------------
--------------------
--------------------
--------------------
Telephone: --------------------
Facsimile: --------------------
Country: --------------------
You accept and agree to the following terms and conditions for Your
present and
future Contributions submitted to the SDO for PHP project.
1. Definitions.
"You" (or "Your") means (or refers to) the person signing this
Agreement and
includes, if the signatory is representing an organization or other
legal
entity, that legal entity and any of its subsidiaries or
Affiliates, as
identified below.
"Affiliate" means an entity that directly or indirectly Controls,
is
Controlled by or is under common Control with, a party to this
Agreement;
and, for these purposes, "Control" shall mean the direct or
indirect
beneficial ownership of more than fifty percent (50%) of the voting
stock of,
or decision making authority in the event that there is no voting
stock in, a
relevant entity.
"Contribution" means any original work of authorship, including any
modification or addition to an existing work, that is intentionally
submitted
by You to the SDO for PHP project for inclusion in, or
documentation of, any
of the products owned or managed by the SDO for PHP project; and,
for these
purposes, "Submitted" includes any form of electronic, verbal, or
written
communication sent to the SDO for PHP project or its
representatives or to
SDO for PHP project-run electronic mailing lists, source code
control
systems, or issue tracking systems. Contributions do not include
any
communication that is conspicuously marked or otherwise designated
in writing
by You as "Not a Contribution".
2. Grant of Copyright License.
Subject to the terms and conditions of this Agreement, You hereby
grant to the
SDO for PHP project, and to recipients of software and other materials
distributed by the SDO for PHP project, a perpetual, world-wide, non-
exclusive,
no-charge, royalty-free, irrevocable copyright license to reproduce,
prepare
derivative works of, publicly display, publicly perform, sublicense,
and
distribute each of Your Contributions and such derivative works.
3. Grant of Patent License.
Subject to the terms and conditions of this Agreement, You hereby
grant to the
SDO for PHP project, and to recipients of software and other materials
distributed by the SDO for PHP project, a perpetual, world-wide, non-
exclusive,
no-charge, royalty-free, irrevocable (except as stated in this
section) patent
license to make, have made, use, offer to sell, sell, import, and
otherwise
transfer each of Your Contributions, where such license applies only
to those
patent claims licensable by You and that, but for this Agreement,
would
necessarily be infringed by the use of Your Contribution alone or by
the
combination of Your Contribution with the SDO for PHP project. If any
entity
institutes patent litigation against You or any other entity
(including a cross-
claim or counterclaim in a lawsuit) alleging that your Contribution,
or the SDO
for PHP project, constitutes direct or contributory patent
infringement, then
any patent license granted to that entity under this Agreement for
that
Contribution shall automatically terminate (without further notice to
such
entity) as of the date when such litigation is filed.
4. Representations.
4.1 You represent that You are legally entitled to grant the above
licenses.
If You are an employee and Your employer has rights to intellectual
property
that You create that includes Your Contributions, You represent that:
(a) You
have received permission to make Contributions on behalf of that
employer, (b)
Your employer has waived such rights for your Contributions to the SDO
for PHP
project, or (c) your employer has executed a separate Corporate CLA
with the SDO
for PHP project.
4.2 You represent that each of Your Contributions is an original
creation,
created by yourself or by yourself with one or more employees of the
Contributor's employers and any of its Affiliates (see section 6 below
for
submissions on behalf of others).
4.3 You represent that Your Contribution submissions include
complete
details of any third-party license or other restriction (including,
but not
limited to, related patents and trademarks) of which You are
personally aware
and which are associated with any part of Your Contributions.
4.4 You agree promptly to notify the SDO for PHP project in
writing of any
fact or circumstance of which You subsequently become aware that would
make any
of the above representations inaccurate in any respect.
5. Disclaimers.
You are not expected to provide any support for Your Contributions,
except to
the extent that You desire to provide support. You may provide support
for free,
for a fee, or not at all. UNLESS REQUIRED BY APPLICABLE LAW OR AGREED
TO IN
WRITING, YOU PROVIDE EACH OF YOUR CONTRIBUTIONS ON AN "AS IS" BASIS,
WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING,
WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-
INFRINGEMENT,
MERCHANTABILITY OR SATISFACTORY QUALITY, OR FITNESS FOR A PARTICULAR
PURPOSE.
6. Non-original submissions.
Should You wish to submit any work that is not Your original creation
to the SDO
for PHP project, You may submit it to the SDO for PHP project
separately from
any Contribution, identifying the complete details of its source and
of any
license or other restriction (including, but not limited to, related
patents,
trademarks, and license agreements) of which you are personally aware,
and
conspicuously marking the work as "Submitted on behalf of a third-
party: [named
here]". You agree not to submit any such non-original material unless
so marked.
7. General.
7.1 You and the SDO for PHP project consent to the application of
laws of
the State of New York, United States to govern, interpret, and enforce
all of
their rights, duties and obligations arising from, or relating in any
manner to,
the subject matter of this Agreement, without regard to conflict of
law
principles.
7.2 Except for the licenses granted above to the SDO for PHP
project and to
recipients of software and other materials distributed by the SDO for
PHP
project, You reserve all right, title, and interest in and to Your
Contributions.
7.3 This Agreement constitutes the entire agreement and
understanding
between You and the SDO for PHP project relating to Contributions to
the SDO for
PHP project, and supersedes all prior related understandings,
agreements and
communications relating to Contributions to the SDO for PHP project.
Full Name: __________________________________ Date: ________________
(Organisation Name): __________________________________
Signatory Title: __________________________________
On 6 Mar, 22:02, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> Hi Kieran
>
> I've had a think and consulted with a few people. I'd like to
> describe two options. The first is the easiest to implement and
> doesn't pollute the interface, and the second is how we should handle
> this kind of thing longer term, but requires quite a bit more work.
>
> Approach 1. Header class property
> -----------------------------------------------------
>
> I was wondering if we could do something like the following:
>
> /**
> *
> * @service
> * @binding.ws
> * @typeshttp://example.org/./header.xsd
> *
> */
> class MyService {
>
> /**
> * @header
> * @varhttp://example.org/HeaderType
> */
> public $myheader;
>
> }
>
> The @header would signify that the $myheader property is expected to
> come from a header (in this case SoapHeader). Because it's a class
> variable, it won't show up as a WSDL operation, but we could reflect
> on it to generate the right information into the WSDL. The @var
> annotation could be used to identify the namespace and type name of
> the header. The actual structure would be defined by the schema which
> is contained in the header.xsd.
>
> During initialization of the MyService component we would inject the
> SDO instance populated from the soap header. The MyService component
> is then free to use this as appropriate.
>
> There are two open questions for feasibility:
>
> 1. How do we register generically to receive a soap header call from
> the SoapServer. The current implementation as outlined by Rob (thanks
> Rob!) appears to rely on us having a PHP function defined which has a
> name matching that of the outer header element.
> 2. If we can register something, does it use the same type handling
> code as the body (i.e. will it give us back an SDO).
>
> I'm optimistic the answer to 2 is "yes", although this would need to
> be tested, but I'm pessimistic that there's currently any way to
> register a generic function or a class to handle the headers. This
> doesn't appear to fit with the approach that Rob described. If we go
> this route we could prototype and offer a patch to enable it.
>
> Approach 2. Extensible annotations (a longer term thought)
>
> The problem with the approach above is it still puts what would
> normally be infrastructure code into the component. SCA (the
> specifications, not the PHP version) defines a Policy and Intent
> mechanism for describing things like security requirements. We should
> make it possible for people to add new annotations (e.g. something
> like @authentication) and then write code that implements what that
> means for each protocol (e.g. soap/http).
>
> We have started making bindings pluggable using a convention to find
> then under the Bindings directory. We could extend this approach to
> look for specific annotations implementation (e.g. Binding/ws/
> authentication to find the implementation code for the @authentication
> annotation).
>
> I'd be interested to know whether either of these approaches would
> work for what you're trying to achieve
>
> Regards,
>
> Graham.
>
> On 6 Mar, 21:51, "Kieran James" <[EMAIL PROTECTED]> wrote:
>
> > Rob,
>
> > I was talking about the PHP SOAP documentation. The SCA documentation seems
> > thorough.
>
> > Kieran :)
>
> > On 3/6/07, Rob <[EMAIL PROTECTED]> wrote:
>
> > > On 4 Mar, 16:36, "Kieran James" <[EMAIL PROTECTED]> wrote:
> > > > Rob,
>
> > > > Thanks for your input!
> > > > I've only had brief exposure to PHP's SOAP (I'm from the Java camp) and
> > > I
> > > > didn't find the documentation very clear (and for that matter, the book
> > > I
> > > > bought on "Pro PHP XML and Web Services" doesn't cover Headers except
> > > from
> > > > the consumers point of view). I'm amazed at the simplicity of it.
>
> > > Sorry about that. I tried to write about as much of the undocumented
> > > features, but unfortunately looks like I missed some of it - though it
> > > did get me intimate with the ext/soap source code :)
>
> > > Rob
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"phpsoa" group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---
