PHP Release Management Wiki

wiki has moved to http://wiki.php.net

[ AdvancedSearch | AreaMap ]

Non CLA PDO Proposal

Hi,

As several people have pointed out, there are some issues with the current proposal.

1. Not all current and future PHP contributors will be able to sign a CLA due to their employers holding patent portfolio's or other legal concerns
2. General burden that developers may need to get legal advice (especially if they are not based in the US, which is the bulk of the core developers today)
3. Accepting patches, talking and brainstorming freely on IRC/mailinglists and at conferences becomes impossible or legally gray at best
4. Additional complexity for developers may result in lost contributions
5. It does set a precedent that some things do not fit into the long standing PHP community development process

As such I am proposing an alternative approach, which I have already alluded to in various posts, but I want to make it a bit more formal.

Entities or individuals that want to use PHP have to accept the fact that its impossible to retrofit a CLA onto the core of PHP. This is a fact that has not deterred from PHP becoming the number one web scripting language and thereby attracting the interest of large software companies like IBM, Oracle, Microsoft (and now SUN, though I will leave them out of this discussion for now, since it appears that MySQL? AB is not one of the parties involved that requires a CLA and the SUN deal has not had any visible effect on this as of now). As a matter of fact all of these companies have done significant investments into the community. So far all of this has happened without a CLA with the notably exception of some portions of PDO, which have been restricted to a handful of people within the community that signed an Apache like CLA. This has not gone without issues in the PHP development process.

So far the investments into the community have consisted of the following:

1. Sponsoring conferences and other community related events/contests
2. Writing documentation (like what Dan Scott did for PDO when he was still with IBM)
3. Writing tests (like what Chris Jones does for Oracle and many people at IBM are doing)
4. Providing feedback to questions of the respective RDBMS and APIs
5. Writing code (most contributions were done by IBM on drivers directed at their respective RDBMS products)

Of all of the above only the last point seems to require a CLA. All of the other 4 items could certainly be expanded with much less financial investment required compared to having a team of developers allocated, though this way the vendors would be dependent on the community to ensure that their drivers matches their quality criteria's. However vendors are free to higher people in the community to dedicate time. This was done for example by Oracle through Zend in order to improve the quality of ext/oci8.

While its clear that this forces the RDBMS vendors to place a much greater level of trust on the community, it does also mean that the community has to place less trust on the commercial vendors. We all know full well what happened when MySQL? changed its client license from LGPL to GPL. There was no way for us to continue development of the LGPL version, because all the developers where all working for MySQL? AB itself. If we rely solely/primarily on RDBMS vendors to maintain their drivers, there is no knowledge transfer into the community and as a result if a vendor decides to direct their ressources elsewhere, we will have a hard time to keep things going. While we currently certainly have extensions that have only 1 (or even no) maintainer, few extensions have not seen at least a few commits by other developers. There are few extensions that require as much ongoing development (due to advances in the underlying RDBMS) as PDO drivers.

Most importantly without a CLA and another license, PHP will continue to be abel to leverage its open development process, which have not placed limitations on getting feedback small or large from one time or repeated contributors. Where ideas are able to flow at conferences, on IRC/mailinglists or any other way people wish to leverage. Again, while this might have some parties concerned about legal dangers, its really too late to worry about this now, PHP was developed without a CLA in the past 10 years and there is no way to fix this now.

This site powered by YaWiki 0.22 beta.