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 -~----------~----~----~----~------~----~------~--~---