# [PHP-CVS] cvs: CVSROOT / avail loginfo - Thread: https://externals.io/message/33475 - Original archive: https://news-web.php.net/php.internals/33475 - Started by Wez Furlong on 2007-11-27T20:59:23+00:00 - Messages: 92 - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/33475.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #33472 — Antony Dovgal — 2007-11-27T19:56:52+00:00 URL: https://externals.io/message/33475#33472 Hello Wez. Please explain what is this 'pdo-specs' thing and why CLA is needed to commit there. For some reason I thought we've agreed that CLA/NDA-protected or any other restricted-access things should not be placed into PHP CVS. pdo_odbc and other "read-but-do-not-write" stuff have already demonstrated how bad it works. > wez Tue Nov 27 18:53:17 2007 UTC > > Modified files: > /CVSROOT avail loginfo > Log: > karma and ml for some pdo bits > > http://cvs.php.net/viewvc.cgi/CVSROOT/avail?r1=1.1331&r2=1.1332&diff_format=u > Index: CVSROOT/avail > diff -u CVSROOT/avail:1.1331 CVSROOT/avail:1.1332 > --- CVSROOT/avail:1.1331 Mon Nov 26 15:14:40 2007 > +++ CVSROOT/avail Tue Nov 27 18:53:17 2007 > @@ -313,6 +313,10 @@ > avail|ramsey|pecl/uploadprogress > avail|ramsey|pecl/pdo_user > > +# PDO Specs. CLA required to commit > +unavail||pdo-specs > +avail|wez,andi,stas,iliaa|pdo-specs -- Wbr, Antony Dovgal --- ## #33475 — Wez Furlong — 2007-11-27T20:59:23+00:00 URL: https://externals.io/message/33475#33475 · In reply to: #33472 All will be revealed soon. --Wez. > Hello Wez. > > Please explain what is this 'pdo-specs' thing and why CLA is needed > to commit there. > > For some reason I thought we've agreed that CLA/NDA-protected or any > other restricted-access things should not be placed into PHP CVS. > pdo_odbc and other "read-but-do-not-write" stuff have already > demonstrated how bad it works. > > > > > […] > > -- > Wbr, > Antony Dovgal --- ## #33477 — Hannes Magnusson — 2007-11-27T22:51:22+00:00 URL: https://externals.io/message/33475#33477 · In reply to: #33475 > +^pdo-specs $CVSROOT/CVSROOT/loginfo.pl pdo-commits@lists.php.net $USER %{sVv} For consistency with the rest of the commit dedicated mailinglists, should this list be named -cvs@? And out of curiosity (since the word is that Microsoft has a hand in this), who will be the patent holder? ;) -Hannes > All will be revealed soon. > > --Wez. > > > > > > > […] --- ## #33478 — Pierre — 2007-11-27T23:28:53+00:00 URL: https://externals.io/message/33475#33478 · In reply to: #33477 One word: transparency. It is amazing how it helps to discuss things instead of acting like that. --Pierre > > […] > > For consistency with the rest of the commit dedicated mailinglists, > should this list be named -cvs@? > > And out of curiosity (since the word is that Microsoft has a hand in > this), who will be the patent holder? ;) > > -Hannes > > > > > […] --- ## #33482 — Lukas Kahwe Smith — 2007-11-28T08:05:56+00:00 URL: https://externals.io/message/33475#33482 · In reply to: #33478 > One word: transparency. > > It is amazing how it helps to discuss things instead of acting like > that. I find it amazing how oblivious to community concerns this all is. Anyways, from some other discussions I gathered that the main thing that is currently being talked about is CLA's. Once they have a CLA in place they will "open" the discussions. From what I hear at least part of the previous "secret" discussions will then be opened as well via some kind of archive. To me the key piece that would kill the idea of a CLA is if it required me to be able to grant all patents that may be covering any of the code I contribute. So far all the CLA's I have read seemed to imply this. And from my understanding this is what makes the CLA work for companies. The alternate interpretation [1], that the Apache CLA and its many derived CLAs, only requires that you grant all patents that knowingly cover the given code, seems bogus to me, since that would defeat the purpose of the CLA to begin with. And that is to be able to deflect all law suits aimed at the project and its users, by pointing the finger at a single developer. The idea being that single developers are no interesting targets for patent trolls. I find this claim, that most OSS projects keep repeating, so hideously evil. If all you need is to ensure that only single developers are to blame for patent violations, than the patent system would probably quickly get an update (because then even our friends at IBM, SUN etc would start to care - they do like software patents, do not let yourself get confused by their patent pool schemes). The point is, there is no guarantee that a patent holder will not still proceed to sue developer Joe Schmo. Number one, not all of us stay poor, but more importantly it will just take a few law suits to teach all the developers in the world that all the guys that gave you friendly advice on CLA's were either lying or uninformed (or lying about being informed). However all the Joe Schmo developers that were taught this lesson can kiss happy life good bye. Now without CLA's, there would be more incentive for companies like IBM and SUN to actually take a different approach to software patents, like using their happy lobby money to actually put an end to them. Or invalidate the patent claim in question, because otherwise they can be sued as well for using the given code, since they do not have a patent grant from Joe Schmo. I have asked IBM to validate the legal situation with a proper legal analysis (which I might still get cross checked by a lawyer of my choice), but I do not know if my contact at IBM was too lazy to actually ask, or if IBM just chose to not answer because they know full well that CLAs is essentially using developers as bumpers. And when the big guys slam into each other .. there is not much left of the bumpers in between. regards, Lukas [1] http://osdir.com/ml/java.harmony.devel/2006-02/msg00344.html --- ## #33489 — Rasmus Lerdorf — 2007-11-28T22:49:23+00:00 URL: https://externals.io/message/33475#33489 · In reply to: #33482 Lukas Kahwe Smith wrote: > > > > > […] > > I find it amazing how oblivious to community concerns this all is. > Anyways, from some other discussions I gathered that the main thing that > is currently being talked about is CLA's. Once they have a CLA in place > they will "open" the discussions. From what I hear at least part of the > previous "secret" discussions will then be opened as well via some kind > of archive. I agree. As most of you know, I met with IBM a couple of years ago the last time they were keen on getting a CLA in place so they could contribute more. I voiced my skepticism, but kept an open mind and put the ball in their court asking them to write up a detailed explanation of how a CLA will help the average PHP contributor. They said they would do that and disappeared never to be heard from again. My stance on this hasn't changed. I don't care the slightest how a CLA helps them, I want to hear what it does for us. The obvious benefit for the project is to get more contributions, but the cost of those contributions in terms of a CLA burden has to be weighed. And so far nobody has adequately justified why the average PHP contributor should sign a CLA. The existing CLA stuff on IBM-specific stuff like DB2, SDO and IDS was something I didn't care much about since it was pretty much entirely an IBM effort and I doubted there would be a general interest in those things, which has pretty much turned out to be the case. But I am very much against expanding this to cover more of PHP and encroaching on general-purpose things that a large number of non-patent encumbered PHP contributors would have an interest in. So yes, before this goes any further, we need full disclosure here and a really well thought out explanation by someone convincing us of the benefits of signing a CLA. Barring that, I am with Marcus and Lukas on this. Keep it out of PHP CVS and host it somewhere else. -Rasmus --- ## #33490 — Daniel Brown — 2007-11-28T23:13:51+00:00 URL: https://externals.io/message/33475#33490 · In reply to: #33489 > Lukas Kahwe Smith wrote: > > […] > > I agree. As most of you know, I met with IBM a couple of years ago the > last time they were keen on getting a CLA in place so they could > contribute more. I voiced my skepticism, but kept an open mind and put > the ball in their court asking them to write up a detailed explanation > of how a CLA will help the average PHP contributor. They said they > would do that and disappeared never to be heard from again. > > My stance on this hasn't changed. I don't care the slightest how a CLA > helps them, I want to hear what it does for us. The obvious benefit for > the project is to get more contributions, but the cost of those > contributions in terms of a CLA burden has to be weighed. And so far > nobody has adequately justified why the average PHP contributor should > sign a CLA. > > The existing CLA stuff on IBM-specific stuff like DB2, SDO and IDS was > something I didn't care much about since it was pretty much entirely an > IBM effort and I doubted there would be a general interest in those > things, which has pretty much turned out to be the case. But I am very > much against expanding this to cover more of PHP and encroaching on > general-purpose things that a large number of non-patent encumbered PHP > contributors would have an interest in. > > So yes, before this goes any further, we need full disclosure here and a > really well thought out explanation by someone convincing us of the > benefits of signing a CLA. Barring that, I am with Marcus and Lukas on > this. Keep it out of PHP CVS and host it somewhere else. > > -Rasmus > > -- > > > > Without sounding too naive on this, I hope, isn't it also possible that IBM's internal policies require them to have CLAs in place for tax and documentation purposes? Or perhaps to cover their own engineers from liability by claiming them as open source developers, protected under the agreement accepted, ultimately, by the end user. I'd concur that it doesn't belong in the PHP CVS because it's out of the scope and spirit of the initial project, but is it really such a Big Brother issue? It states that all developers are completely free to use and redistribute any code they commit to the repository and the project as a whole, and further, that any user can then use it freely to create derivative works from said code, et cetera. Of course, it does lay the groundwork for new licensing in the future, whereby this project could eventually take on more and more of PHP, until a project that began as open source joins the ranks as a commercial competitor to ASP and Java. Then again, maybe I'm missing something or just blowing smoke out of my ass. I'm exhausted, but I'm trying to understand a bit more about the hot-button parts of the issue. -- Daniel P. Brown [office] (570-) 587-7080 Ext. 272 [mobile] (570-) 766-8107 If at first you don't succeed, stick to what you know best so that you can make enough money to pay someone else to do it for you. --- ## #33491 — Rasmus Lerdorf — 2007-11-28T23:54:20+00:00 URL: https://externals.io/message/33475#33491 · In reply to: #33490 Daniel Brown wrote: > Without sounding too naive on this, I hope, isn't it also possible > that IBM's internal policies require them to have CLAs in place for > tax and documentation purposes? Or perhaps to cover their own > engineers from liability by claiming them as open source developers, > protected under the agreement accepted, ultimately, by the end user. Like I said, I understand why they need a CLA, and they can develop stuff under whatever terms they want. It is only the final license of what they produce that should matter to most people. The sticky point is if this CLA requirement starts bleeding out of fringe things very specific to a certain product and starts infecting general PHP components like all of PDO instead of just a specific PDO driver. -Rasmus --- ## #33494 — Marcus Boerger — 2007-11-29T10:17:17+00:00 URL: https://externals.io/message/33475#33494 · In reply to: #33490 Hello Daniel, I do not care for IBM problems. Not at all. If people want to commit they can do it in their free time. If IBM now thinks they have to make PHP suitable for their own stuff then they are obviously willing to spend quite some interest because they have a much bigger business interest. That said I am confident they can find ways to deal with it inside IBM itself. But they do not like to do it as that would be much more expensive for them. Also the trouble is that then they would need to be real open source. So why in the end not force everybody to sign a CLA. Everybody meaning every sinegle developer on the PHP project. That is from the guy that translates documentation every once in a while to people working on the core like me (And for me it would mean I will instantly stop contribution to PHP at all). And in the long run what are the consequences? Where do we stop? IBM is only one drive behind all this. Actually this is driven by more bigger companies. And the all share the same problem and they all want the same. Today PHP is something that makes money when you can run it on your server fast. So that creates business interest. And business interest creats the will to take over control in anyway and ownership. So in the very long way, will we loose the PHP License (or will it be rewritten?). Open source means open discussions. If something has to be discussed in some hidden rooms than that is not open source! And if something has to be forced over us then that is not the spirit of PHP. In the past eleven years we have been discussing everything openly. We all sometimes hated this openness but on the other hand it is also part of the success of PHP. So what to hell with all this? marcus Thursday, November 29, 2007, 12:13:51 AM, you wrote: > > > […] > Without sounding too naive on this, I hope, isn't it also possible > that IBM's internal policies require them to have CLAs in place for > tax and documentation purposes? Or perhaps to cover their own > engineers from liability by claiming them as open source developers, > protected under the agreement accepted, ultimately, by the end user. > I'd concur that it doesn't belong in the PHP CVS because it's out > of the scope and spirit of the initial project, but is it really such > a Big Brother issue? It states that all developers are completely > free to use and redistribute any code they commit to the repository > and the project as a whole, and further, that any user can then use it > freely to create derivative works from said code, et cetera. > Of course, it does lay the groundwork for new licensing in the > future, whereby this project could eventually take on more and more of > PHP, until a project that began as open source joins the ranks as a > commercial competitor to ASP and Java. > Then again, maybe I'm missing something or just blowing smoke out > of my ass. I'm exhausted, but I'm trying to understand a bit more > about the hot-button parts of the issue. > -- > Daniel P. Brown > [office] (570-) 587-7080 Ext. 272 > [mobile] (570-) 766-8107 > If at first you don't succeed, stick to what you know best so that you > can make enough money to pay someone else to do it for you. Best regards, Marcus --- ## #33495 — Derick Rethans — 2007-11-29T11:03:24+00:00 URL: https://externals.io/message/33475#33495 · In reply to: #33494 > I do not care for IBM problems. Not at all. If people want to commit > they can do it in their free time. If IBM now thinks they have to make > PHP suitable for their own stuff then they are obviously willing to > spend quite some interest because they have a much bigger business > interest. That said I am confident they can find ways to deal with it > inside IBM itself. But they do not like to do it as that would be much > more expensive for them. Also the trouble is that then they would need > to be real open source. To add to this, I think that if IBM (and others) are so keen on having PHP support their nice databases, they should also realize that it is them that should be nice to *us* and not the other way around. We (as in PHP project) shouldn't have to change the ways how we're dealing with contributions at all. It should be the big companies that actually have a financial interested in PHP supporting their software that open up more and appease us. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #33496 — Daniel Brown — 2007-11-29T15:02:03+00:00 URL: https://externals.io/message/33475#33496 · In reply to: #33495 > > > > […] > > To add to this, I think that if IBM (and others) are so keen on having > PHP support their nice databases, they should also realize that it is > them that should be nice to *us* and not the other way around. We (as in > PHP project) shouldn't have to change the ways how we're dealing with > contributions at all. It should be the big companies that actually have > a financial interested in PHP supporting their software that open up > more and appease us. > > regards, > Derick > > -- > Derick Rethans > http://derickrethans.nl | http://ez.no | http://xdebug.org > Well, like I said at the tail of my last message, I was exhausted. This morning, over a nice, hot cup of coffee (very welcome after coming in from the snow outside), I took a better look at the whole thing. That, coupled with your responses (thank you, Rasmus, Marcus, and Derick), gives a much clearer picture. What concerns me now is that I - and I'm sure many others - wasn't even aware of this until this thread popped up. It almost seems like the beginnings of a long-term hostile takeover plan, beginning quietly in the shadows. -- Daniel P. Brown [office] (570-) 587-7080 Ext. 272 [mobile] (570-) 766-8107 If at first you don't succeed, stick to what you know best so that you can make enough money to pay someone else to do it for you. --- ## #33497 — Stanislav Malyshev — 2007-11-29T16:59:50+00:00 URL: https://externals.io/message/33475#33497 · In reply to: #33495 > To add to this, I think that if IBM (and others) are so keen on having > PHP support their nice databases, they should also realize that it is > them that should be nice to *us* and not the other way around. We (as in What I really don't understand is why so many people are so quick to jump into "us vs. them" attitude. Is there a war or what? Isn't there enough conflict so that one must look so hard to create a new one? Or maybe it is worth considering that having good database support is good for *both* PHP and IBM? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #33498 — Stanislav Malyshev — 2007-11-29T17:01:16+00:00 URL: https://externals.io/message/33475#33498 · In reply to: #33496 > this thread popped up. It almost seems like the beginnings of a > long-term hostile takeover plan, beginning quietly in the shadows. Come on... Really. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #33499 — Daniel Brown — 2007-11-29T17:03:12+00:00 URL: https://externals.io/message/33475#33499 · In reply to: #33498 > > […] > > Come on... Really. > > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com > It would certainly be cheaper than the $3.3 Billion they bid for Lotus. P.S. - Apparently sarcasm isn't always read as such. I may have used a sarcasm-less MIME type when sending. ;-P -- Daniel P. Brown [office] (570-) 587-7080 Ext. 272 [mobile] (570-) 766-8107 If at first you don't succeed, stick to what you know best so that you can make enough money to pay someone else to do it for you. --- ## #33500 — Marcus Boerger — 2007-11-29T17:07:50+00:00 URL: https://externals.io/message/33475#33500 · In reply to: #33497 Hello Stanislav, noone disagrees to any work any company is willing to do. Infact we should be extremely happy about the work done by some IBM people lately (to stay with the same company example). At least I am for one really happy! However hiding in some secret rooms and deciding something that might or migfht not affect everyone in the PHP company is different. It is different from any kind of spirit we had and developed in more than ten years. It is different from some access controls executed over CVS to not loose control and directing responsibilities. It simply is not open source. Just read a dictionary on "open" and the web provides enough written stuff on "open source". Let's keep it open and maintain the PHP spirit. That does not prevent any company of contributing to open source. If so then they are not willing to do open source. Then they have to accept the open source model. Not the open source model has to change. marcus Thursday, November 29, 2007, 5:59:50 PM, you wrote: > > […] > What I really don't understand is why so many people are so quick to > jump into "us vs. them" attitude. Is there a war or what? Isn't there > enough conflict so that one must look so hard to create a new one? > Or maybe it is worth considering that having good database support is > good for *both* PHP and IBM? > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com Best regards, Marcus --- ## #33501 — Steph Fox — 2007-11-29T17:16:57+00:00 URL: https://externals.io/message/33475#33501 · In reply to: #33497 > What I really don't understand is why so many people are so quick to jump > into "us vs. them" attitude. Is there a war or what? Isn't there enough > conflict so that one must look so hard to create a new one? > Or maybe it is worth considering that having good database support is good > for *both* PHP and IBM? Stas - we don't even know what they're planning to put into CVS. Just that there's a new module there that nobody wants to talk to php.net about (apparently) and that has a CLA attached. You say 'good database support', but that's one thing more than we know. Nobody was very happy about it the last time there was a CLA attached to a php.net project, so why would they be happy about it now? As for 'us vs. them' - surely the CLA and the ensuing silence are the separators here, rather than the protests against the lack of transparency? - Steph --- ## #33502 — Pierre — 2007-11-29T17:28:35+00:00 URL: https://externals.io/message/33475#33502 · In reply to: #33497 > > […] > > What I really don't understand is why so many people are so quick to > jump into "us vs. them" attitude. Is there a war or what? Isn't there > enough conflict so that one must look so hard to create a new one? > Or maybe it is worth considering that having good database support is > good for *both* PHP and IBM? To see a commit restricting access to something that looks like the future of the most important part of php is everything you want but acceptable. Not without previous discussion or at least one post of internals. I don't think it is that hard to understand, isn't it? Having a clear and transparent contribution process is much more important to my eyes than good support for 's products. If one likes to contribute to a project, he has to adapt himself to the project, not the other way 'round. That's the main problem here and it is not the first time that such thing happens. It is what many of us don't understand. Regards, --Pierre --- ## #33503 — Richard Quadling — 2007-11-29T17:34:50+00:00 URL: https://externals.io/message/33475#33503 · In reply to: #33501 > > […] > > Stas - we don't even know what they're planning to put into CVS. Just that > there's a new module there that nobody wants to talk to php.net about > (apparently) and that has a CLA attached. You say 'good database support', > but that's one thing more than we know. Nobody was very happy about it the > last time there was a CLA attached to a php.net project, so why would they > be happy about it now? > > As for 'us vs. them' - surely the CLA and the ensuing silence are the > separators here, rather than the protests against the lack of transparency? > > - Steph From my understanding of CLA's it mainly deals with patent sharing. What patents does PHP own/license? I would guess IBM have a LOT more patents than PHP. But PHP isn't a real entity (again, as I understand it) - how can it own anything? So, what, exactly, is the fuss all about? Surely all this "us/them", "silence behind doors", etc., is just FUD? If IBM, or anyone, wants to submit code to PHP it can only improve things. We do have peer-review after all. If I can't even get 2 double quotes into the windows version of `exec()` to allow it to support more things with no BC, surely you're not going to just lay down and let IBM ruin the game (and I'm not even saying they are going to ruin the game, just that you have the option of not including their code!). The idea of a major world player contributing to our lill' old PHP sounds really exciting. The more the merrier, as long as the peer-review process works (and it seems to have kept me out of the core well enough!), let them come! Richard. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #33504 — Steph Fox — 2007-11-29T17:49:34+00:00 URL: https://externals.io/message/33475#33504 · In reply to: #33503 > So, what, exactly, is the fuss all about? Richard, the problem with a CLA (moral quibbles apart) is it prevents any of the core contributors doing anything with the code. As in: +# PDO Specs. CLA required to commit +unavail||pdo-specs That's what 'unavail' means. > Surely all this "us/them", "silence behind doors", etc., is just FUD? Show me where there's been any open discussion and I'll agree with you. > If IBM, or anyone, wants to submit code to PHP it can only improve things. Sure, but if IBM, or anyone, wants to prevent the people who work on the PHP core from touching that code don't you think there might be a teensy bit of an issue there? > We do have peer-review after all. Not on CLA'd code we don't. - Steph --- ## #33505 — David Coallier — 2007-11-29T18:09:02+00:00 URL: https://externals.io/message/33475#33505 · In reply to: #33504 > > […] > > Richard, the problem with a CLA (moral quibbles apart) is it prevents any of > the core contributors doing anything with the code. As in: > > +# PDO Specs. CLA required to commit > +unavail||pdo-specs > > That's what 'unavail' means. > > > […] > > Show me where there's been any open discussion and I'll agree with you. > > > […] > > Sure, but if IBM, or anyone, wants to prevent the people who work on the PHP > core from touching that code don't you think there might be a teensy bit of > an issue there? > > > […] > > Not on CLA'd code we don't. > > - Steph > > > -- > > > > Ok this is driving me nuts: http://url.ie/730 or http://tinyurl.com/2242cf (They are both going to the same place but some people have preferences) -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 --- ## #33506 — Daniel Brown — 2007-11-29T18:10:54+00:00 URL: https://externals.io/message/33475#33506 · In reply to: #33505 > > > > […] > > Ok this is driving me nuts: > > http://url.ie/730 > or > http://tinyurl.com/2242cf > > (They are both going to the same place but some people have preferences) > > > > -- > David Coallier, > Founder & Software Architect, > Agora Production (http://agoraproduction.com) > 51.42.06.70.18 > Dave, There was no place for me to type my response to the final question. ;-P -- Daniel P. Brown [office] (570-) 587-7080 Ext. 272 [mobile] (570-) 766-8107 If at first you don't succeed, stick to what you know best so that you can make enough money to pay someone else to do it for you. --- ## #33510 — Jacques Marneweck — 2007-11-29T19:16:28+00:00 URL: https://externals.io/message/33475#33510 · In reply to: #33504 > > […] > > Richard, the problem with a CLA (moral quibbles apart) is it > prevents any of the core contributors doing anything with the code. > As in: > > +# PDO Specs. CLA required to commit > +unavail||pdo-specs > > That's what 'unavail' means. > > > […] > > Show me where there's been any open discussion and I'll agree with > you. > > > […] > > Sure, but if IBM, or anyone, wants to prevent the people who work > on the PHP core from touching that code don't you think there might > be a teensy bit of an issue there? > > > […] > > Not on CLA'd code we don't. Steph the CLA seems to just relate to the docbook xml specifications for PDO. Regards --jm > > - Steph > -- > > -- Jacques Marneweck http://www.powertrip.co.za/ http://www.powertrip.co.za/blog/ http://www.ataris.co.za/ http://www.dataarchitects.co.za/ #include > […] > Richard, the problem with a CLA (moral quibbles apart) is it prevents any of > the core contributors doing anything with the code. As in: > +# PDO Specs. CLA required to commit > +unavail||pdo-specs > That's what 'unavail' means. > > […] > Show me where there's been any open discussion and I'll agree with you. > > […] > Sure, but if IBM, or anyone, wants to prevent the people who work on the PHP > core from touching that code don't you think there might be a teensy bit of > an issue there? > > […] > Not on CLA'd code we don't. > - Steph Best regards, Marcus --- ## #33512 — Steph Fox — 2007-11-29T19:26:39+00:00 URL: https://externals.io/message/33475#33512 · In reply to: #33510 > > […] > > Steph the CLA seems to just relate to the docbook xml specifications > for PDO. Someone told you that, or have you developed psychic powers? The same applies, regardless. If a commit to that module breaks the PHP manual build, you or I can't fix it. There was a time before now when a CLA'd module broke the snaps build, same problem. - Steph --- ## #33515 — Philip Olson — 2007-11-29T20:59:08+00:00 URL: https://externals.io/message/33475#33515 · In reply to: #33512 > > […] > > Someone told you that, or have you developed psychic powers? > > The same applies, regardless. If a commit to that module breaks the > PHP manual build, you or I can't fix it. There was a time before > now when a CLA'd module broke the snaps build, same problem. FWIW, there is an IBM copyright attached to the "PDO Driver How-To" document here: http://php.net/manual/en/internals2.pdo.php However, a ~couple months ago IBM gave permission to remove this copyright (because the authors are listed as general contributors, thus representing IBM) although we've not yet implemented this removal. We did [temporary] remove it about six months ago but... I'll make the update today. Regards, Philip --- Next page: https://externals.io/message/33475.md?page=2