[Note: replies set to pdo@lists.php.net; let's keep the discussion on
that list rather than cluttering up internals@]

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 pdo@lists.php.net
To subscribe, send an email to pdo-subscribe@lists.php.net.

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:pdo@lists.php.net (you may
subscribe by emailing mailto:pdo-subscribe@lists.php.net).