Re: [PDO] [RFC] An Idea for PDO 2

Hello Marcus, (and everyone else!)

This sounds like a reasonable alternative plan.

For the benefit of those that are not intimate with how a PHP  
distribution is made:

The PHP "core" consists of three CVS modules that are checked out  
together as "php-src".
Anything that falls within php-src on a given tag ultimately lands in  
the PHP distribution tarball for source releases, and is compiled into  
binary form and lands in the zip file for windows releases.

PECL is another module in the repository that contains non-core  
extensions.  However, some of these extensions are symlinked so that  
they appear both in PECL and under php-src/ext, and are thus part of  
the "core".  PDO and most of the PDO drivers are linked in in this way.

Now, if we were to remove the symlinks for the drivers where the  
vendors want to provide support but cannot do so without CLA (this  
list is likely to include the IBM, Microsoft and Oracle drivers), that  
would remove those drivers from the "core" image as it appears in CVS.

Those drivers could then be worked on in PECL and protected with an  
appropriate ACL, and have their releases made on their own schedule,  
as it the norm for any PECL extension.

At the time we prepare a PHP release, we could then take the latest  
stable release from PECL for those drivers and put them into the  
"core" tarball (and compile them for the "core" zipfile).

The PDO core itself would reside in the "core" cvs image (php-src).   
Along with the PDO spec, these two modules would be free from CLA.   
Contributors that require a CLA would not be able to directly  
contribute to the spec or the PDO core, but could still contribute  
suggestions and make other input via discussions on this mailing list.

With the CLA drivers outside of the core cvs image, there would not be  
any issues with unfixable broken builds (which was the main bone of  
contention with pdo_odbc), and there would be a clear indicator that  
the CLA'd drivers would be supported by the maintainers of that PECL  
module, so there would be no burden on the broader community for  
fixing bugs in those extensions.  At the same time, since those  
drivers would be open source and residing in our repository, it would  
not prevent community members that were willing/able to sign a CLA  
from helping to maintain those drivers if they wished to do so.

If, at some point, for whatever reason, the "owner" of a CLA'd module  
is unable to support it any more, since the source is open and under a  
compatible license, we could then essentially fork the code and remove  
the ACL and support it for ourselves without a CLA requirement.  I  
don't see this happening any time soon, I'm just mentioning this as a  
possible answer to one of Lukas' concerns about corporations  
abandoning a particular project.

Another thing to note is that PHP today ships code that is licensed  
under a number of different licenses: PHP, TSRM and ZendEngine being  
three large pieces with their own individual licenses, and there are  
some source files or portions of source files with their own  
licenses.  These licenses are all compatible with each other.  With  
that in mind, there is no technical reason that the "PDO License"  
document that was proposed (http://www.php.net/~wez/pdo/PDO-License-12-03-07.pdf 
) could not be used for CLA protected PDO driver extensions--it is  
also compatible with the PHP license.  This would avoid the need to  
change the PHP license itself, and avoids venturing into the grey area  
of LGPL that Marcus suggested (IMO, the viral nature of the GPL is  
far, far worse than a CLA).

The key points of this approach:

- PHP ships with support for the major databases, with the best  
available people working on their respective drivers
- The source for all the drivers would be available to all under a  
license that is compatible with the PHP license
- CLA protected code would be isolated from the bulk of the PHP code
- The build would not be held at the mercy of a breakage in a CLA'd  
extension
- Vendors could support their drivers
- The community can support the rest as they see fit

What objections, if any, are there to this approach, and why?

--Wez.


On Feb 1, 2008, at 3:26 PM, Marcus Boerger wrote:

> Hello all,
>
> So after the initial uproar on last week's attempts to put parts
> of PHP development under the terms of a CLA, a bunch of us actually
> spent some time in finding solutions for one way or the other. I
> don't want to bother you with more details on the why.
>
> One thing for certain, we want PDO.
>
> As the reasoning, this was discussed enough, so I'll jump directly
> to my ideas for a solution.
>
> * Develop a PECL CLA that can optionally be used for PECL projects.
> * If necessary, adapt the PHP License, so that it works nicely
>  together with the CLA.
> * The projects that want a CLA can choose between the PHP License or
>  LGPL.
> * Change the PELC web site so that projects can opt-in to using the
>  CLA.
> * Arrange it so that projects cannot drop the CLA flag.
> * Add a user/CLA/project table to the PHP user database, and use this
>  in CVS ACLs.
> * Create a new CVS module php-default.
> * Move all extensions that can be disabled and are not required for
>  others to PECL.
> * Link everything under php-src plus a default selection of
>  extensions to php-default.
> * Let us once and for all ban CLAs from php-src aka PHP core.
> * Start developing PDO as part of CVS module php-src.
>
> Sorry for not writing this earlier. So how does this idea sound?
>
> Best regards,
> Marcus
>
> p.s.: Post comments as reply or here: http://blog.somabo.de/2008/02/we-want-pdo-don-we.html#links
>
> -- 
> PDO Working Group Mailing List (http://pdo.php.net)
> To unsubscribe, visit: http://www.php.net/unsub.php
>