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

On Feb 1, 2008 9:39 PM, Wez Furlong <wez.furlong@messagesystems.com> wrote: > 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 > > > > -- > PDO Working Group Mailing List (http://pdo.php.net) > To unsubscribe, visit: http://www.php.net/unsub.php > > Impressive post.. One thing I might have missed is (unrelated to this answer from you) where do we send the CLA to if PHP itself is not a legal entity to whoever might decide to sign it ?? Or did you guys plan on making a PHP Org ? Do we send it to some vendors ? Are you making a PDO Group/Org ? -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18