January 26
PHP PDO V2 CLA
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Good points. Again the key issue I see is being able to openly talk to people and get feedback at conferences, on my blog etc. The second I sign this CLA I have waived this for all but the people who have also signed. What happens to patches that are submitted? Bug reports with detailed analysis?
Anyways, you do have a minor mistake in that you imply that reading the specs requires signing a CLA. From my understanding there will be no limitation for people who have not signed to read/compile whatever the CLA'ed PDO group produces. Its only the ability to participate in the development that is being limited to people who have signed this CLA according to the proposal that is currently on the table.
Anyways, you do have a minor mistake in that you imply that reading the specs requires signing a CLA. From my understanding there will be no limitation for people who have not signed to read/compile whatever the CLA'ed PDO group produces. Its only the ability to participate in the development that is being limited to people who have signed this CLA according to the proposal that is currently on the table.
I just realized that you were just going by what Tony has said. I will try to talk to him to find out what made him believe that reading the specs will require signing the CLA (notice that Andi - who is involved in the CLA proposal - commented on his blog without disputing TOny's claim).
FULLACK, Kris. And, BTW: where are the open source database vendors (Postgres, SQlite, Firebird)?
Many of them gave up to try to work with PDO. It was a pain in the beginning to get something if one of the original maintainer/author(s) disagreed, especially before the first releases.
MySql "suffered" from this syndrome. That may explained why they took so long to get on board again (well, we are actually still waiting to see what will be done with the new client library, in regard of PDO...).
All in all, to only propose a CLA for PDO (no matter which portion) will simply reproduce the same mistakes, power 10.
MySql "suffered" from this syndrome. That may explained why they took so long to get on board again (well, we are actually still waiting to see what will be done with the new client library, in regard of PDO...).
All in all, to only propose a CLA for PDO (no matter which portion) will simply reproduce the same mistakes, power 10.
Pierre,
I understand your anger on the current CLA situation.
My questions are:
Have Postgres, SQlite, Firebird been involved in the current PDO 2 CLA discussion? Is this PDO 2 thing really about pushing PHP forward or is it about getting some vendors into the PHP market at the price of trying to force php.net.
The scary thing is that an attempt has been made to change the current php.net "CLA-no-thanks policy. I guess you would be angry as well, if whatever group would have forked PDO 1 and developed PDO 2 in their own repository using their own rules. But anyway, this would have been a hundred times better than trying to force php.net to accept a CLA by making a "silent" and "hidden" CVS commit.
Next. How do you develop any new driver if the specification of PDO 1 is CLA'd? Each and every PDO 1 driver behaves differently. Given that there are no failing tests I have to assume that each and every PDO 1 driver is behaving correct and that inconsistencies are inherent to PDO 1. In some cases I would like to find out what the correct behaviour is. However, if I start asking, will everybody reply to me? Thinking of Tony (and others), for example, why would he even bother to comment on my questions as long as the PDO 1 spec is CLA'd. Even if we came to a conclusion, we would not be able to change the spec and document the new rule. We would need to sign the CLA before doing so. He will never ever sign it, you won't sign it, Pierre. So, how would we improve PDO 1?
I never understood why the specification itself needs to be CLA'd. Driver code, OK, but specification.
Last bus not least, PDO 1 has been done in a rush. If there was no consensus on the specification, how can you blame any contributor (e.g. MySQL) for loosing interest in implementing something you do not agree to.
I understand your anger on the current CLA situation.
My questions are:
Have Postgres, SQlite, Firebird been involved in the current PDO 2 CLA discussion? Is this PDO 2 thing really about pushing PHP forward or is it about getting some vendors into the PHP market at the price of trying to force php.net.
The scary thing is that an attempt has been made to change the current php.net "CLA-no-thanks policy. I guess you would be angry as well, if whatever group would have forked PDO 1 and developed PDO 2 in their own repository using their own rules. But anyway, this would have been a hundred times better than trying to force php.net to accept a CLA by making a "silent" and "hidden" CVS commit.
Next. How do you develop any new driver if the specification of PDO 1 is CLA'd? Each and every PDO 1 driver behaves differently. Given that there are no failing tests I have to assume that each and every PDO 1 driver is behaving correct and that inconsistencies are inherent to PDO 1. In some cases I would like to find out what the correct behaviour is. However, if I start asking, will everybody reply to me? Thinking of Tony (and others), for example, why would he even bother to comment on my questions as long as the PDO 1 spec is CLA'd. Even if we came to a conclusion, we would not be able to change the spec and document the new rule. We would need to sign the CLA before doing so. He will never ever sign it, you won't sign it, Pierre. So, how would we improve PDO 1?
I never understood why the specification itself needs to be CLA'd. Driver code, OK, but specification.
Last bus not least, PDO 1 has been done in a rush. If there was no consensus on the specification, how can you blame any contributor (e.g. MySQL) for loosing interest in implementing something you do not agree to.
"Have Postgres, SQlite, Firebird been involved in the current PDO 2 CLA discussion? Is this PDO 2 thing really about pushing PHP forward or is it about getting some vendors into the PHP market at the price of trying to force php.net."
As far as I know, they were (and) not involved. See the reaction of one of the Firebird developer on internals. It was about forcing php.net, they may reconsider their positions now, but it will not end with this battle.
"I guess you would be angry as well, if whatever group would have forked PDO 1 and developed PDO 2 in their own repository using their own rules."
To be honest? It would not be a surprise . I would not be angry if it was done this way. It'll free the way to improve PDO in php-src and let them create yet another irrelevant DB extension lying in some obscure repository.
"Last bus not least, PDO 1 has been done in a rush. If there was no consensus on the specification, how can you blame any contributor (e.g. MySQL) for loosing interest in implementing something you do not agree to."
I did not blame MySql about their initial retirement (or more specifically Georg). It was expected and to retire was a perfectly normal reaction. I would have retired as well.
However, after months or years things have changed, the active maintainers too, and MySql completely ignored our calls and still does. Giving php.net its own mysql client library is nice but I somehow miserably fail to see the point.
But MySql (despite their bad moves in the past years) was always fair with PHP and let us kids solve our own problems as long as possible. They are doing the same now ;)
As far as I know, they were (and) not involved. See the reaction of one of the Firebird developer on internals. It was about forcing php.net, they may reconsider their positions now, but it will not end with this battle.
"I guess you would be angry as well, if whatever group would have forked PDO 1 and developed PDO 2 in their own repository using their own rules."
To be honest? It would not be a surprise . I would not be angry if it was done this way. It'll free the way to improve PDO in php-src and let them create yet another irrelevant DB extension lying in some obscure repository.
"Last bus not least, PDO 1 has been done in a rush. If there was no consensus on the specification, how can you blame any contributor (e.g. MySQL) for loosing interest in implementing something you do not agree to."
I did not blame MySql about their initial retirement (or more specifically Georg). It was expected and to retire was a perfectly normal reaction. I would have retired as well.
However, after months or years things have changed, the active maintainers too, and MySql completely ignored our calls and still does. Giving php.net its own mysql client library is nice but I somehow miserably fail to see the point.
But MySql (despite their bad moves in the past years) was always fair with PHP and let us kids solve our own problems as long as possible. They are doing the same now ;)
Ok, so there are two issues here: PDO 2, CLA, trying to push php.net and MySQL's past and current policy.
The official MySQL policy regarding PDO 2 CLA is in simple words: MySQL respects those who see a need for a CLA. MySQL itself has no need for a CLA and has no need to push on it. Its up to php.net folks to decide.
Individual people at MySQL think a CLA is a 100% no-go for php.net, others believe its worth accepting it. However, this does not change: in the end its up to php.net to decide.
I have been working on mysqlnd since the project has started more than a year ago. Since about a year I'm following Planet PHP. I have not seen many calls from php.net people towards us since then. From time to time, Tony pings me (or Georg, or...) regarding all the new tests but aside from that there have not been many requests towards us. If you have any suggestions on improvements, I'm happy to hear them.
The official MySQL policy regarding PDO 2 CLA is in simple words: MySQL respects those who see a need for a CLA. MySQL itself has no need for a CLA and has no need to push on it. Its up to php.net folks to decide.
Individual people at MySQL think a CLA is a 100% no-go for php.net, others believe its worth accepting it. However, this does not change: in the end its up to php.net to decide.
I have been working on mysqlnd since the project has started more than a year ago. Since about a year I'm following Planet PHP. I have not seen many calls from php.net people towards us since then. From time to time, Tony pings me (or Georg, or...) regarding all the new tests but aside from that there have not been many requests towards us. If you have any suggestions on improvements, I'm happy to hear them.
"If you have any suggestions on improvements, I'm happy to hear them."
My main question was and still is:
Why yet another library only for PHP?
The second is:
Why have you not began with PDO support from day #1? At the time Mysql was talking about this new lib, pdo was much open to changes than in the beginning. I asked MySql using all possible ways to jump on board to improve mysql support in PDO, result: Nothing and not a single answer (even not to my answer to a MySql request... that tells everything about how internal MySql works, esp. at the management level).
My main question was and still is:
Why yet another library only for PHP?
The second is:
Why have you not began with PDO support from day #1? At the time Mysql was talking about this new lib, pdo was much open to changes than in the beginning. I asked MySql using all possible ways to jump on board to improve mysql support in PDO, result: Nothing and not a single answer (even not to my answer to a MySql request... that tells everything about how internal MySql works, esp. at the management level).
Sorry for late reply Pierre. Whenever MySQL holds an all company meeting, a good number of us gets sick afterwards.
So, why mysqlnd? That's simple, you can answer this yourself. With mysqlnd we have layed the technical foundations to (re-)enable MySQL support by default in PHP: finally no license exception any more, no library dependencies, no installation hazzles, no Windows client library version discussions etc. If MySQL support will be (re-)enabled by default in PHP, is up to php.net folks - as usual. If that's not gonna happen, bad luck. But even if its not gonna happen, I feel good with it: the overall goal is to have "native" connectors for all major languages. And mysqlnd is clearly better integrated and technical superior to libmysql when it comes to PHP. Like we have "native" storage engines for dedicated tasks we now have a "native" connector. I love mysqlnd, (for PHP) its superior to libmysql. Business value? PHP is a huge and important market and if you look at the 2008 goal Web 2.0, you see that MySQL wants to stay the #1 choice in the Web.
Your second question is on PDO and day #1. Scroll up in our thread to read our both summary on the difficult childhood of PDO. From what I know, I have not been involved personally in the PDO 1 development, we have answered all technical questions and given help when needed. However, PDO 1 was developed quite some time ago and I guess that was when the MySQL focus was not on PHP. PDO has a low market share compared to the native interfaces, structural problems have been discussed in depth. If 80% of your users prefer using ext/mysql[i], why would you invest into PDO/MySQL given all the issues on it. What's my benefit?
I have not heard of millions of MySQL Java users who cannot wait to use PHP and who have developers which get scared by yet another native interface which every Java developer will hide behind abstraction layers anyway. Where's the business value?
Yes, in the end my question is: where's the business value.
Personally I want PD[O|DBC|...]. But why would I take an active role on this if I see little value in it. You can't move the duty to develop PDO from php.net to a vendor of your choice.
My thinking. Others - including my employeer - may have different positions.
So, why mysqlnd? That's simple, you can answer this yourself. With mysqlnd we have layed the technical foundations to (re-)enable MySQL support by default in PHP: finally no license exception any more, no library dependencies, no installation hazzles, no Windows client library version discussions etc. If MySQL support will be (re-)enabled by default in PHP, is up to php.net folks - as usual. If that's not gonna happen, bad luck. But even if its not gonna happen, I feel good with it: the overall goal is to have "native" connectors for all major languages. And mysqlnd is clearly better integrated and technical superior to libmysql when it comes to PHP. Like we have "native" storage engines for dedicated tasks we now have a "native" connector. I love mysqlnd, (for PHP) its superior to libmysql. Business value? PHP is a huge and important market and if you look at the 2008 goal Web 2.0, you see that MySQL wants to stay the #1 choice in the Web.
Your second question is on PDO and day #1. Scroll up in our thread to read our both summary on the difficult childhood of PDO. From what I know, I have not been involved personally in the PDO 1 development, we have answered all technical questions and given help when needed. However, PDO 1 was developed quite some time ago and I guess that was when the MySQL focus was not on PHP. PDO has a low market share compared to the native interfaces, structural problems have been discussed in depth. If 80% of your users prefer using ext/mysql[i], why would you invest into PDO/MySQL given all the issues on it. What's my benefit?
I have not heard of millions of MySQL Java users who cannot wait to use PHP and who have developers which get scared by yet another native interface which every Java developer will hide behind abstraction layers anyway. Where's the business value?
Yes, in the end my question is: where's the business value.
Personally I want PD[O|DBC|...]. But why would I take an active role on this if I see little value in it. You can't move the duty to develop PDO from php.net to a vendor of your choice.
My thinking. Others - including my employeer - may have different positions.
"... me time ago and I guess that was when the MySQL focus was not on PHP"
I don't think that MySQL has ever forgotten about PHP. This is not what I want to say. Make it:
"... me time ago and I guess that was when the MySQL focus was not on PDO"
I don't think that MySQL has ever forgotten about PHP. This is not what I want to say. Make it:
"... me time ago and I guess that was when the MySQL focus was not on PDO"
Sqlite was asked to join, but Richard did not have time (especially since until now its all been legal bla bla from all I have heard). PostgreSQL is on board. I dont know if Firebirs was approached (there are actually quite a few users in Brazil, Russia and to some extend Germany). I am surprised that Ingres is not on the list of vendors.
Seems like I was running on false assumption regarding the timing of the involvment of OSS projects.
Your statement about needing to sign a CLA to read the spec is not true.
*If* we were to adopt a CLA, it would mean that a contributor would need to sign the CLA before they could contribute to the code or the spec (depending what exactly we decide should be protected by the CLA).
The CLA has nothing to do with reading or consuming the source code or the specification.
*If* we were to adopt a CLA, it would mean that a contributor would need to sign the CLA before they could contribute to the code or the spec (depending what exactly we decide should be protected by the CLA).
The CLA has nothing to do with reading or consuming the source code or the specification.
I don't have cvs commit access at php.net, and if I asked for commit access purely on the principle of free access to enhance the software, I don't think it would be granted to me. Does that mean PHP itself is not open-source? Your argument seems to lead to this conclusion.
But I am free to enhance PHP code on my own computer and redistribute it myself as a derived work. This is permitted by the PHP License, and it does satisfy freedom #3.
The same is true of PDO, with its proposed CLA and PDO License.
But I am free to enhance PHP code on my own computer and redistribute it myself as a derived work. This is permitted by the PHP License, and it does satisfy freedom #3.
The same is true of PDO, with its proposed CLA and PDO License.
I think Bill has it right. As far as I understand it, the primary restriction the CLA puts on contributions is that you have to be certain that the code you contribute is yours to share, not from a non-open project/software product that may come back to PDO users for their IP rights. I don't know why an open source contributor would not be willing to say that.
Ugh. I never said the CLA "was not a big deal". My appeal was to offer *solutions* and not just bitch about things or make grandiose, religious statements that are full of myths and exaggerations.
You prove my point exactly by saying things such as "[ PDO V2 ] requires signing a legal paper it you want to participate or even read its spec." This is not correct. The CLA does not mean you can't read the darn spec, and nowhere has anyone said this. Please don't exaggerate.
"This makes is essentially non-free software."
Really? Then I guess MySQL, Zend Framework, Apache, Eclipse. etc are ALL non-free software since they require CLAs to contribute to certain parts of the codebase...
"but I feel that the requirement to sign a CLA before being allowed to participiate is violating the spirit, if not the letter of clause 3 and 5 of the Open Source Definition as well"
I don't see the correlation, Kris. Point 3 states:
"The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software."
The PDO license does not hamper this at all. The CLA is different from the license, and should not be confused.
Point 5:
"The license must not discriminate against any person or group of persons."
Again, the license doesn't discriminate against anyone.
Personally, I am not for or against the CLA. I prefer to let the PHP community work it out and MySQL will and should support whatever decision the community comes to.
But what I will not do is stand by and watch people distort the truths (on both sides of the issues) and exaggerate the issues farther than their logical conclusion.
Cheers,
Jay
You prove my point exactly by saying things such as "[ PDO V2 ] requires signing a legal paper it you want to participate or even read its spec." This is not correct. The CLA does not mean you can't read the darn spec, and nowhere has anyone said this. Please don't exaggerate.
"This makes is essentially non-free software."
Really? Then I guess MySQL, Zend Framework, Apache, Eclipse. etc are ALL non-free software since they require CLAs to contribute to certain parts of the codebase...
"but I feel that the requirement to sign a CLA before being allowed to participiate is violating the spirit, if not the letter of clause 3 and 5 of the Open Source Definition as well"
I don't see the correlation, Kris. Point 3 states:
"The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software."
The PDO license does not hamper this at all. The CLA is different from the license, and should not be confused.
Point 5:
"The license must not discriminate against any person or group of persons."
Again, the license doesn't discriminate against anyone.
Personally, I am not for or against the CLA. I prefer to let the PHP community work it out and MySQL will and should support whatever decision the community comes to.
But what I will not do is stand by and watch people distort the truths (on both sides of the issues) and exaggerate the issues farther than their logical conclusion.
Cheers,
Jay
Quicksearch
Comments
about An InnoDB tutorial
Mon, 21.07.2008 11:13
I have a problem in deleting t he child table row from my app lication using unique id. when I am using the command [...]
Mon, 21.07.2008 11:13
I have a problem in deleting t he child table row from my app lication using unique id. when I am using the command [...]
about Nermalisation
Sat, 05.07.2008 16:08
The point is that you have the option to not do, but then yo u'll be in a world of pain. Th e point is also to show [...]
Sat, 05.07.2008 16:08
The point is that you have the option to not do, but then yo u'll be in a world of pain. Th e point is also to show [...]
about Nermalisation
Fri, 04.07.2008 15:40
Nice little article, and I lik e how you've used cats in your examples :) I am a little unclear what the point h [...]
Fri, 04.07.2008 15:40
Nice little article, and I lik e how you've used cats in your examples :) I am a little unclear what the point h [...]
about Salmiakki - the official MySQL Drink
Sun, 08.06.2008 11:34
150g of liquorice are enough t o get the original Salmiakki t aste.... you can add some more , anyway
Sun, 08.06.2008 11:34
150g of liquorice are enough t o get the original Salmiakki t aste.... you can add some more , anyway
about phpvikinger.org: Things that have no name
Sun, 11.05.2008 06:34
In reply to "stuff with no nam es":very informative and succi nct. I am retired and need to learn to build a website [...]
Sun, 11.05.2008 06:34
In reply to "stuff with no nam es":very informative and succi nct. I am retired and need to learn to build a website [...]
about What is the difference between MySQL and Postgres?
Wed, 30.04.2008 14:08
what is the difference between MySql and PostgreSql?
Wed, 30.04.2008 14:08
what is the difference between MySql and PostgreSql?
about Fortune Cookie
Wed, 09.04.2008 21:46
What a random fortune, who kno ws what it means. My favorite random fortune cookie note rea ds "you will make a good [...]
Wed, 09.04.2008 21:46
What a random fortune, who kno ws what it means. My favorite random fortune cookie note rea ds "you will make a good [...]
Categories
Community (12)- DBA
- DBA Tools (2)
- I18N (2)
- Monitoring and Merlin (2)
- Operating System (5)
- Replication (1)
- Scaleout and Tuning (8)
- Security (2)
- SQL (9)
- Strangeness (5)
- Development
- Bugs (3)
- Building (1)
- Devtools (1)
- Features (2)
- Releases (8)
- Engines
- InnoDB (3)
- Memory
- MyISAM and Maria
- Languages
- LUA
- PHP (7)
- Ruby (1)
- Miscellaneous (5)
- MySQL Proxy
- Working for MySQL (7)
Syndicate This Blog
Blog Administration
Disclaimer
All examples, code-snippets, advice, trivia, etc. are supplied in the hope that they are useful, but no warranty of any kind is given. Use of trademarks is not intended as a challenge to them.
Impressum
Copyright 2005-2007 bei den jeweiligen Autorinnen der Beiträge. Die Infrastruktur von MySQL-dump wird betrieben von:
Azundris, Immanuelkirchstraße 18, 710405 Berlin, Germany