[Note: replies set to [EMAIL PROTECTED]; let's keep the discussion on that list rather than cluttering up [EMAIL PROTECTED]
Hi all, Please accept our apologies that it's taken so much time to make these clarifications on some of the discussions regarding PDO 2. It became apparent over the past year or so that PDO has been a good and valuable addition to PHP. Like JDBC in the Java world, PDO offers similar advantages, such as consistent data access APIs and better consistency across the various drivers. It has also become clear that there is still room for improvement around the functionality, consistency and broader vendor support for PDO. For the latter two points, we believe that having direct involvement from the data access providers would be most effective, which is why we set out to try and get them on board. In order to get to a PDO version 2, we set out to accomplish three things: 1) Document how the existing PDO works, so that the various contributors would have a baseline for discussion and making improvements 2) Suggest scope and direction for PDO 2 work 3) Find the right mechanism for all the data access providers (i.e. commercial and non-commercial vendors, and authors/maintainers of PHP data access extensions) to take part in this initiative. (3) is why it's taken so long to get to this point. We believe it to be extremely valuable to have all of the data access providers involved in this initiative. Participation in open source projects is not an easy process for the commercial vendors, as they are technically in competition with each other. We believed that there would need to be some strong pre-requisites to figure out a mechanism which might be considered acceptable to the broader committer community. This included: 1) The mechanism should not require setting up a legal entity for PHP or PDO. This has traditionally been very important to many vendors (e.g. Apache Software Foundation, Eclipse Foundation, Dojo Foundation, ...) 2) Anyone in the community should be able to be part of the mechanism and become a contributor. 3) The license of the work should be compatible with the PHP license and of the same spirit. The discussion was not an easy one, especially due to the first point-- lawyers like having a legal entity. So we decided to try to figure out what the options were for collaboration (if it was at all possible) before moving on to a broader discussion. When it became more clear that CLA would most likely be needed to ensure broad participation we added the following to the pre-requisites: 1) A contributor license agreement should be based on a broadly respected CLA such as the Apache Software Foundation's contributor license agreement and should not require copyright assignment (i.e. the contributor retains rights to his contributions). 2) PHP core should not fall under the same CLA process even though PDO leverages APIs from PHP. It made little sense to dive into a discussion about features and functions before we had a suggested mechanism that was accepted by the community. It's taken much longer than expected, but we have now reached a point where we believe there is enough "meat" to move the discussion into the community to see whether it really does make sense to go down this route. What we've got now is: a) A spec for PDO 1 is now documented and can be reviewed by all and used as a base line for future discussions http://www.php.net/~wez/pdo/pdo-spec.html b) There is a draft of a suggested PDO license and CLA for review by the community and data access vendors (not all vendors have officially agreed to it and pushing it internally for official final approval doesn't make sense before the community supports it). http://www.php.net/~wez/pdo/PDO-CLA-Corporate-12-07-07.pdf http://www.php.net/~wez/pdo/PDO-CLA-Individual-12-07-07.pdf http://www.php.net/~wez/pdo/PDO-License-12-03-07.pdf (these are all under http://www.php.net/~wez/pdo/) c) We have jointly written an FAQ which attempts to clarify some of the questions which have been asked in the past few months. The FAQ is at the end of this email, and is available from: http://www.php.net/~wez/pdo/pdo-faq.txt d) We have setup a separate mailing list which we suggest to use for all discussions. This shouldn't slow down any of the work which is happening on internals@ on PHP 5.3 and PHP 6. The list is [EMAIL PROTECTED] To subscribe, send an email to [EMAIL PROTECTED] e) We have also made available an option to host larger conference calls for discussing some of the issues which may be harder to discuss via email. We can discuss this option on the mailing list. The various vendors will also participate in the mailing list which should allow for effective communication. Thanks, Wez & Andi PDO v2 FAQ: =========== This document is being maintained at: http://www.php.net/~wez/pdo/pdo-faq.txt Why do we need a PDO v2? ------------------------ PDO works quite well for a fair proportion of developers, but there are some features that are either missing or that need improvement. Some of the missing features are important for people building larger systems than the typical PHP developer, and would enable better integration with query building or data mapping libraries and frameworks. Others are improved support for the more advanced features of various database systems, such as XML and other datatypes. There needs to be some planning before running ahead and taking a stab at implementing these features, otherwise we'll create trouble for ourselves and introduce bugs, or not consider the impact of the features across the various database drivers. What are the suggested goals for PDO v2? - Setting up a forum for the development of PDO - Working out the details for a community driven development process - Building up a suite of unit tests, with the goal of reaching at least 80% coverage with 100% pass rate before considering a component of PDO ready to release - Support Unicode for PHP 6, and improve charset support for PHP 5 - Metadata APIs for describing schema and rowsets - Determine how to take advantage of XML column types emerging in some databases, and making the API consistent across those platforms These are just a starting point, and are of course open for discussion. Will PDO v2 be backwards compatible with applications that use PDO v1? ---------------------------------------------------------------------- The group's preference is for PDO v2 to be backwards compatible with v1. From initial review of PDO v1 it seems there are not a lot of areas which would require changing and there are likely to be more areas where PDO v2 would grow the functionality. That said, this is a rare opportunity to have all the industry experts around the same table and make the right long-term decisions. We believe the bias should be to keep backwards compatibility but with an openness to change if there is enough benefit. What decisions have been made regarding the scope of PDO v2? ------------------------------------------------------------ No decisions have been made regarding PDO v2. The group has been mainly discussing on how to collaborate and making sure we have an up-to-date spec of PDO v1 so that we would have a good baseline. Some of the areas which the group did point out as interesting areas to address are: - A detailed written specification for PDO v2 both from a user perspective and from a driver implementer perspective. - Focus on database access as opposed to database abstraction. - Build consistent metadata APIs in order to support database abstraction layers and management tools. - Design testing methodology, test harness and set clear code coverage goals. In any case, the intent is for the PDO v2 spec to be openly developed in version control and reviewed by the broad community. What decisions have been made regarding the requirement for having a CLA? ------------------------------------------------------------------------ The working group has been working diligently in the past few months to try and find a process which would enable all interested parties to effectively collaborate around PDO v2. As part of this it became apparent that in order to most effectively enable some of the commercial vendors to participate and contribute, a process with a CLA requirement would be important. Therefore, the group spent a lot of time trying to find the right CLA & license suggestion which would both address the needs of the commercial companies and in parallel stay as aligned to the PHP community as possible. Such alignment included a process which would not require forming a legal entity for PHP, an Apache-like CLA which did not require copyright assignment and was based on a well known and well respected CLA, and a license which reflected the same values of the PHP license and delivering similar benefits to the PHP license. After many months the group has managed to reach a draft proposal for such a CLA and a license which will likely be acceptable to most and possibly all parties of the working group. This CLA is still in draft form and it is not final. Feedback on the draft is welcome. As is mentioned elsewhere in this FAQ, having such a mechanism and process will allow the highest level of expertise to be available both to planning and developing the next generation of PDO. How do you envision the process moving forward? ----------------------------------------------- The intention is to involve both the interested data access organizations (commercial and non-commercial) and the PHP community in developing PDO v2. PHP's standard way of discussing plans, filtering ideas and delivering code will be used. The steps are: 1. The PDO working group and PHP community leaders will define the goals of PDO v2 and decide on the use of a CLA process. 2. Participants who want to contribute to PDO V2 will agree to a CLA and become part of the working group. 3. A specification for PDO v2 will be written under the leadership of Wez Furlong. 4. Tests to validate that PDO v2 drivers implement the specification will be written. 5. Documentation for the PDO v2 API, and a guide for driver developers will be written. 6. Drivers for each database will be written. It is expected that developers from the database organizations will lead their respective driver efforts, but assistance from other working group members in all areas (specification/coding/testing/documentation) is welcome. Which organizations are participating in the PDO v2 project? ------------------------------------------------------------ Currently vendors/projects who have been part of the initial discussions and have expressed interest in the group include IBM, Microsoft, MySQL, Oracle, PostgreSQL and SQLite. As the intention of PDO v2 is to deliver to PHP users first-class consistent data access to all databases, vendor involvement is crucial as they know their databases and drivers best. We would therefore be happy to see additional database vendors and data access providers join and contribute to the project. Why can't the community just develop v2 like we developed v1? ------------------------------------------------------------- The goal is to have optimized and high-quality drivers for all supported database brands. PDO v1 was developed by a small number of developers who had general database experience, so some drivers are not complete and up to date. By encouraging contributions from data access providers, the PDO v2 project gains the most expert knowledge of all database brands, and the latest optimizations and bug fixes. No one is better qualified to know details of each database brand than the vendors themselves. Driver development won't be done exclusively by the data access providers. PDO v2 will use an open development process, and community contributions are encouraged. Development of the PDO v2 core technology will be chiefly a community effort, just like it has been in the past. By combining the best contributions from both the community and from data access providers, we will produce better technology, with higher quality, in a more timely way. Why does PDO v2 need a CLA? --------------------------- Having CLAs as part of the development and contribution process helps to raise the awareness of contributors about IP, and to clarify any IP associated with contributions to the project. The fact that contributors agree to the requirements of the CLA before contributing mitigates the risk of IP claims against users of the software. Concerns about the IP of contributions are not so infrequent that having CLAs could not be beneficial. IP problems aren't completely foreign to the PHP community. Over the years there have been cases where some code in PHP has been rewritten in order to remove less favorably licensed code from the code base. Also just recently there was an issue with one of the PEAR contributions (http://tinyurl.com/yprb3g) Why didn't the discussion regarding a CLA happen in a public forum? ------------------------------------------------------------------- We first wanted to explore what might be needed to get the commercial database vendors comfortable with participating in the PDO development effort before taking the time and effort to engage more widely and see if the community would also be comfortable with the approach. Won't having a CLA for PDO set a precedent for the rest of PHP? How is PDO unique? ------------------------------------------------------------------------ PDO is a bit different from the other parts of PHP because it acts as a bridge for a number of database extensions to talk to PHP. Most of those extensions use libraries provided by a commercial vendor, and most of those vendors are in competition with each other. The CLA and license make it possible for these potentially competing people to collaborate on the core piece of PDO, alongside community members, and this is very valuable for PDO because it means that we can take advantage of the experience, expertise and support commitment that are being offered by these organizations. There are fears that the introduction of a CLA to a particular corner of PHP will form a precedent that will gradually cause the whole of PHP to be similarly protected. We do not believe that this will be the case because, aside from it being almost impossible to retrofit a CLA to the entirety of PHP, the proposed CLA is very specifically targeted at PDO and at making it possible for database vendors to collaborate on just that piece. There are no viral clauses in the wording of the CLA. How does having a CLA protect the database vendors and enable them to contribute? ------------------------------------------------------------------------ CLAs are designed to make it clear that the person contributing material or information is making the contribution to be used, copied, distributed, etc. by those who receive it, and the contributor will not later claim any violation of their IP rights when the material and information is used, copied, distributed, etc. This provides some protection for everyone who accesses and receives the contributions, allowing them to continue developing code without worrying about IP claims from contributors who have signed CLAs. The database vendors would also sign Corporate CLAs which would protect all recipients and other contributors from claims by the vendors that IP contributed by their employees was not rightly contributed. Companies want to be as comfortable as possible that employees who access the source code or other materials will be able to continue developing the company's products and providing services without worrying about the rights to any of what might be replicated or produced in these products or services. How does having a CLA protect me as a contributor? -------------------------------------------------- In addition to protecting contributors in the same ways that it protects end-users, the CLA also helps to reduce the risk of being tainted by IP that they have not been granted the rights to by protecting against claims from those making the contributions under the CLA. How does having a CLA protect end-users? ---------------------------------------- CLAs are designed to help manage IP risk to everyone involved (including end users) to the extent that those contributors who have signed CLAs should be prevented from claiming that end users (and others) who receive and make use of the contributions are violating the IP rights of the contributor. What if I'm in a country which has different copyright and patent laws? ----------------------------------------------------------------------- Many countries are signatories to treaties that provide certain common practices for intellectual property law. In general, we would not expect there to be great variation from country to country. However if you have concerns with respect to your country, you should consult a knowledgeable legal professional. There are large existing open-source communities like the Apache Software Foundation which are also global in nature and you may also want to consider contacting a contributor in your country who may be able to share their experiences. Does the proposed Apache-like CLA require copyright assignment, like for example the MySQL CLA does? ------------------------------------------------------------------------ The Apache-like CLA is very much different from some of the commercial CLAs in that it does not require contributors to assign copyright to the project. Under the PDO CLA each contributor grants to the PHP Group, other contributors and end users a license to use his contribution. More details can be found in the "Grant of Copyright License" section of the CLA (http://www.php.net/~wez/pdo/PDO-CLA-Corporate-12-07-07.pdf and http://www.php.net/~wez/pdo/PDO-CLA-Individual-12-07-07.pdf). To be clear, the contributor retains copyright to his contribution even after the work has been contributed which is less restrictive than many CLAs used by other open-source projects. How is the proposed CLA different from the Apache contributor license agreement? ------------------------------------------------------------------------ The proposed CLA is based on the Apache CLA. It was clear at the outset of discussing a CLA that the parties believed that only an existing and broadly accepted CLA could act as a foundation for PDO. The group did not want to come up with a whole new CLA which is not recognizable and doesn't have a proven track record. There are a few places where it differs from the Apache CLA. Some main differences include: - It calls out the PHP Group as the administrator of the CLAs and licensor of PDO. The main deviation is not only that this is a different group but also that the group itself has not formed an official legal entity like the Apache Software Foundation. However, due to the fact that the PHP Group has been around for many years and there is clear history to the group's involvement with PHP, the various parties have agreed that the current status is acceptable as the administrator of the CLAs. Note: This is a big accomplishment in itself as in the past companies have been very shy from contributing to projects which didn't have an official legal entity behind it. - There are additional restrictions on the sub-licensing the PHP Group can do on the software, mainly by limiting it to non-viral licenses (e.g. no GPL). As this is something which is consistent with existing PHP licensing philosophy which is aligned to BSD licensing it shouldn't pose a problem. - The goals of the project are more clearly defined and exclude the actual protocol level drivers to clarify that the parties are working together on the layer on top of the low-level driver and are not seeking to replicate the drivers themselves. - The representations are a bit more detailed but don't include any material changes. To summarize, the proposed CLA is almost the same as the Apache CLA both in its content and in its spirit and the changes have been made mainly to add clarification around the intent of the collaboration and the legal entity governing the CLA. Why is there a Corporate CLA and an Individual CLA? Do I have to complete both of them? ------------------------------------------------------------------------ Many employers have legal agreements with their employees granting ownership of material produced by the employee that relates to the company's business to the company, and that often covers material produced on company time and outside company time. The Corporate CLA signed by a company representative goes beyond the Individual CLA in allowing named employees to contribute such company owned IP on the company's behalf. Do I need to search the various patent databases to ensure that my ideas have not been patented yet? ------------------------------------------------------------------------ No. By signing the CLA, you assert that you and you alone authored your contributions, i.e., that your contributions are original to you as a matter of copyright law. You further assert that to the best of your knowledge you are not aware of any patent rights related to your contribution. And so we do not expect you to search for any patents before you submit a contribution. Why is the PDO license separate from the PHP license and how are they different? ------------------------------------------------------------------------ The existence of a PDO license does not set any new precedent because today PHP is already comprised of code under a variety of different licenses in addition to the PHP license. Several examples include TSRM (Thread Safe Resource Manager) and MT RAND which are licensed under BSD-like licenses, Mime Magic which has an Apache 1.1 license, and md5 which has a RSA OS license. The PHP and PDO licenses are generally similar although the PDO license includes language that provides the same level of use rights and protections as the CLAs. We encourage you to compare the licenses and join the discussions on the PDO mailing list. If I have a question that isn't answered here, whom do I ask? ------------------------------------------------------------------------ We have setup a discussion list at mailto:[EMAIL PROTECTED] (you may subscribe by emailing mailto:[EMAIL PROTECTED]). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php