[PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
Antony Dovgal
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.
On 27.11.2007 21:53, Wez Furlong wrote:
> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Wez Furlong
--Wez.
Hannes Magnusson
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
Pierre
It is amazing how it helps to discuss things instead of acting like that.
--Pierre
Lukas Kahwe Smith
On 28.11.2007, at 00:28, Pierre wrote:
> 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
Rasmus Lerdorf
>
> On 28.11.2007, at 00:28, Pierre wrote:
>
>> 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.
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
Daniel Brown
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.
Rasmus Lerdorf
> 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.
Marcus Boerger
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
>> -Rasmus
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
> 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
Derick Rethans
> 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
Daniel Brown
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.
--
Stanislav Malyshev
> 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
st...@zend.com http://www.zend.com/
(408)253-8829 MSN: st...@zend.com
Stanislav Malyshev
> long-term hostile takeover plan, beginning quietly in the shadows.
Come on... Really.
Daniel Brown
> > 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
> st...@zend.com http://www.zend.com/
> (408)253-8829 MSN: st...@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.
--
Marcus Boerger
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:
>> 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
> st...@zend.com http://www.zend.com/
> (408)253-8829 MSN: st...@zend.com
Best regards,
Marcus
Steph Fox
> 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
Pierre
> > 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
>
> 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 <some company>'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
Richard Quadling
> > 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?
>
> 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!"
Steph Fox
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
David Coallier
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
Daniel Brown
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.
--
Marcus Boerger
for example that would exclude me and I guess others as well.
marcus
Thursday, November 29, 2007, 6:49:34 PM, you wrote:
>> 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
Best regards,
Marcus
Jacques Marneweck
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
On 29 Nov 2007, at 7:49 PM, Steph Fox wrote:
>> 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 the CLA seems to just relate to the docbook xml specifications
for PDO.
Regards
--jm
>
> - Steph
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
--
Jacques Marneweck
http://www.powertrip.co.za/
http://www.powertrip.co.za/blog/
http://www.ataris.co.za/
http://www.dataarchitects.co.za/
#include <std/disclaimer.h>
--Apple-Mail-1--986743414--
Philip Olson
On Nov 29, 2007, at 11:26 AM, Steph Fox wrote:
>>>> We do have peer-review after all.
>>>
>>> Not on CLA'd code we don't.
>>
>> 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.
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
Rasmus Lerdorf
> 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!
We welcome any and all contributions, of course, but where there are
strings attached it starts to get complicated. The problem here is that
IBM employees can't contribute to open source projects without some
protection in the form of a CLA. This CLA basically says that you have
the rights to the contributions you make and that if the company you
work for have copyrights or patents related to the contribution then you
grant all rights to the receiving project. On the surface it may not
sound too bad. It is sort of common sense that we aren't ripping off
proprietary code from somewhere and sticking it in PHP and that we don't
go out and get a patent on some concept and then put that code into PHP
in order to sue everyone using PHP for violating our patent.
However, the legal wording needed to do this looks something like this:
http://www.apache.org/licenses/icla.txt
It is long and complicated and I don't see how anybody could sign this
without getting legal advice. You would also need to pass this by the
legal department of the company you work for. Legal where I work
wouldn't let us sign something like this for the longest time. They are
working through it now, so it may be possible, but they had a long list
of concerns and various needs for clarification as I am sure any company
would have when their employees start signing legal documents affecting
their patent portfolio.
The end result is that I think there will be a significant number of
current PHP contributors who either can't, or won't, sign a CLA like
this. And if the code covered by this CLA is a significant part of PHP,
then we have an untenable position. I would like to be proven wrong on
this. I have had no part in these discussions, but from what people
tell me the proposed CLA is based on the Apache CLA listed above, so
have a careful read through that and make up your own mind.
-Rasmus
Adam Maccabee Trachtenberg
> It is long and complicated and I don't see how anybody could sign this
> without getting legal advice. You would also need to pass this by the
> legal department of the company you work for. Legal where I work
> wouldn't let us sign something like this for the longest time. They are
> working through it now, so it may be possible, but they had a long list
> of concerns and various needs for clarification as I am sure any company
> would have when their employees start signing legal documents affecting
> their patent portfolio.
Without taking a position one way or another on this particular piece
of software, which I know nothing about, I can say that I work for a
similar company as Rasmus, and I have had similar complications with
my legal team over ASF-style CLAs. If they're willing to approve them,
they want to edit them first, which, of course, they cannot do --
these are "take it or leave it" legal documents, which no lawyer
likes.
While those problem can be sometimes worked through, it usually comes
down to a risk / reward calculation. Is the risk of opening ourselves
up given the perceived vagueness of the CLA worth the return we will
get? It's hard to price the risk, but, honestly, I usually price the
return pretty low compared to opening up a large public company to
potentially losing a valuable patent, which makes it a hard bar to
hurdle.
I also don't enjoy spending my time this way, which is more of a
personal issue than a corporate one, but it does make me less
interested in working on those types of projects.
As an additional data point, I have had success getting them to agree
for us to release internal code under both BSD and CDDL open source
licenses, so they are not unfamiliar or unreceptive to these issues
and ideas.
-adam
--
ad...@trachtenberg.com | http://www.trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!
Stanislav Malyshev
And waiting couple of days for the explanation is of course not an option.
--
Stanislav Malyshev, Zend Software Architect
st...@zend.com http://www.zend.com/
(408)253-8829 MSN: st...@zend.com
--
Stanislav Malyshev
> important to my eyes than good support for <some company>'s products.
No, it is not more important. 99.9% of PHP users don't care what process
we have, they care about how well PHP works for them. If we had best
process in the world but no support for what people need - people won't
use PHP just to commend us for oh so good process. Process is important,
but it's a *tool*, not the *goal*.
Stanislav Malyshev
> strings attached it starts to get complicated. The problem here is that
I thought the whole purpose of CLA was to ensure there are *no* strings
attached to the contributed code.
Daniel Brown
> No, it is not more important. 99.9% of PHP users don't care what process
> we have, they care about how well PHP works for them. If we had best
> process in the world but no support for what people need - people won't
> use PHP just to commend us for oh so good process. Process is important,
> but it's a *tool*, not the *goal*.
Actually, I believe the latest Gallup Poll sponsored by CNN put
that number at 97.3%. ;-P
Besides, as I read the message you quoted, my understand was that
Pierre was inferring that it's more important for the community to
have standardized guidelines for contributions, rather than bend to
the whim of one party: in this case, IBM.
--
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.
--
Steph Fox
Derick Rethans
> > Having a clear and transparent contribution process is much more
> > important to my eyes than good support for <some company>'s products.
>
> No, it is not more important. 99.9% of PHP users don't care what process we
> have, they care about how well PHP works for them.
This is irrelevant, because the users where not in question here. And
they only don't care because they have no idea how this stuff is
going to affect a big part of the contributers to PHP.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
Johannes Schlüter
On Thu, 2007-11-29 at 14:56 -0800, Stanislav Malyshev wrote:
> > Having a clear and transparent contribution process is much more
> > important to my eyes than good support for <some company>'s products.
>
> No, it is not more important. 99.9% of PHP users don't care what process
> process in the world but no support for what people need - people won't
> use PHP just to commend us for oh so good process. Process is important,
> but it's a *tool*, not the *goal*.
Right, for the users the process isn't important, they only care about
the license and the result hat comes out.
But still it affects the developers which haven't been consulted either,
yet. And it looks like some people (who ever it is in detail) seem to
try to put stuff with different rules in CVS without discussing it -
which is against the openness of the PHP project as I know it.
johannes
Dan Scott
> On Nov 29, 2007 5:56 PM, Stanislav Malyshev <st...@zend.com> wrote:
> > we have, they care about how well PHP works for them. If we had best
> > process in the world but no support for what people need - people won't
> > use PHP just to commend us for oh so good process. Process is important,
> > but it's a *tool*, not the *goal*.
>
> that number at 97.3%. ;-P
>
> Besides, as I read the message you quoted, my understand was that
> Pierre was inferring that it's more important for the community to
> have standardized guidelines for contributions, rather than bend to
> the whim of one party: in this case, IBM.
Ok, Kreskin - assuming you're as out of the loop as most of the rest
of us, if this is purely an IBM thing, why are MySQL AB employees
signing up for this (see CVS account request from Jay Pipes)? MySQL
AB has its own CLA for contributions to the MySQL code base:
http://forge.mysql.com/wiki/MySQL_Contributor_License_Agreement. Maybe
they're the ones pushing for a CLA this time around.
--
Dan Scott
Laurentian University
Pierre
> > Having a clear and transparent contribution process is much more
> > important to my eyes than good support for <some company>'s products.
>
> we have, they care about how well PHP works for them.
We don't talk about PHP users here but developers and contributors. If
PHP never had contributors (no matter the form) it would never be
where it is now.
> If we had best
> process in the world but no support for what people need - people won't
> use PHP just to commend us for oh so good process. Process is important,
> but it's a *tool*, not the *goal*.
Asking prior to acting unilaterally is part of a process. Starting to
push CLA in the core of PHP without even asking is something I can't
understand.
--Pierre
Greg Beaver
>> Stas - we don't even know what they're planning to put into CVS. Just
>
> And waiting couple of days for the explanation is of course not an option.
Hi,
This is a dangerous approach Stas, the "shoot first, explain later"
approach is a closed-source model. Fortunately, the bullet can be put
back into the gun by removing the CVSROOT unavail until there is at the
very least a notification email. A few days extra before committing
can't hurt unless we have a serious problem in PHP development. As
president of PEAR, I'd like to let you know that I am following this
debate extremely closely to see how things progress and more to the
point - how it is resolved. I'm sure that in the future a similar
question will come up for us should a CLA be adopted in PHP core for a
major component.
Thanks,
Greg
Marcus Boerger
for the future please do not accept any copyright other than
"The PHP Group" or "The PHP documentation Grroup". Thanks.
Otherwise comanies are going to own PHP piece by piece.
marcus
Thursday, November 29, 2007, 9:59:08 PM, you wrote:
> On Nov 29, 2007, at 11:26 AM, Steph Fox wrote:
>>>>> We do have peer-review after all.
>>>>
>>>> Not on CLA'd code we don't.
>>>
>>> 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.
> 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
Best regards,
Marcus
Hannes Magnusson
> Hello Philip,
>
> for the future please do not accept any copyright other than
> "The PHP Group" or "The PHP documentation Grroup". Thanks.
> Otherwise comanies are going to own PHP piece by piece.
It was never accepted.
The docs, with the copyright, were committed without any notification
or heads up.
There were no indications that those docs were covered by CLA, I sure
hope they aren't since I have committed fixes to those files...
-Hannes
Marcus Boerger
the same applies to me as I pointed out to Richard already (as an example
to Stephs argument). An NDA or CLA usually means that you can talk about
stuff you do that contains patents and all that. Now we are not intersted in
patents at all. And the solutiuon is easy keep your patent stuff at home or
make it freely available. Then you can easily get permission fomr a lawyer
to work on OSI complient stuff like PHP. If that was not the case then I
wonder how people from IBM or other big companies could ever contribute to
PHP. Since they did we obviously have no need at all for a CLA and anythign
that comes along with it or as a consequence.
marcus
Thursday, November 29, 2007, 10:03:56 PM, you wrote:
> Richard Quadling wrote:
>> 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!
> We welcome any and all contributions, of course, but where there are
> strings attached it starts to get complicated. The problem here is that
> IBM employees can't contribute to open source projects without some
> protection in the form of a CLA. This CLA basically says that you have
> the rights to the contributions you make and that if the company you
> work for have copyrights or patents related to the contribution then you
> grant all rights to the receiving project. On the surface it may not
> sound too bad. It is sort of common sense that we aren't ripping off
> proprietary code from somewhere and sticking it in PHP and that we don't
> go out and get a patent on some concept and then put that code into PHP
> in order to sue everyone using PHP for violating our patent.
> However, the legal wording needed to do this looks something like this:
> http://www.apache.org/licenses/icla.txt
> It is long and complicated and I don't see how anybody could sign this
> without getting legal advice. You would also need to pass this by the
> legal department of the company you work for. Legal where I work
> wouldn't let us sign something like this for the longest time. They are
> working through it now, so it may be possible, but they had a long list
> of concerns and various needs for clarification as I am sure any company
> would have when their employees start signing legal documents affecting
> their patent portfolio.
> The end result is that I think there will be a significant number of
> current PHP contributors who either can't, or won't, sign a CLA like
> this. And if the code covered by this CLA is a significant part of PHP,
> then we have an untenable position. I would like to be proven wrong on
> this. I have had no part in these discussions, but from what people
> tell me the proposed CLA is based on the Apache CLA listed above, so
> have a careful read through that and make up your own mind.
> -Rasmus
Best regards,
Marcus
Dan Scott
> Hello Philip,
>
> for the future please do not accept any copyright other than
> "The PHP Group" or "The PHP documentation Grroup". Thanks.
> Otherwise comanies are going to own PHP piece by piece.
>
>
> Thursday, November 29, 2007, 9:59:08 PM, you wrote:
>
> > On Nov 29, 2007, at 11:26 AM, Steph Fox wrote:
>
> >>>>> We do have peer-review after all.
> >>>>
> >>>> Not on CLA'd code we don't.
> >>>
> >>> 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.
>
> > 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
In that case, you should:
1) Have a legal entity that you can assign copyright to (PHP Group and
PHP Documentation Group are not legal entities and therefore cannot
hold copyright) and
2) Have a legal form that people "sign" (could be a simple DCO
attached to a submission) to assign their copyright to that legal
entity
We have neither of these things, so we're gesturing wildly and
passionately about copyright statements but ultimately looking rather
foolish.
In the world of academic publishing, the open access movement is
fighting hard to ensure that authors _retain_ copyright when they
submit an article to a journal. Researchers license journals to
publish their articles, so that we don't have to pay multiple times to
access funded research (pay once to support the research, pay a second
time to subscribe to the journal in which the research has been
published).
You're confusing copyright with licenses. Copyright should be retained
by the author (of code or of documentation) - if they assign copyright
to another entity, they waive any right to reuse their own work in a
different forum - except under the terms under which that work is
licensed by the entity that now has the copyright for that material.
So an author can and should maintain copyright over the material they
contribute, but they contribute it under a license that specifies the
terms under which that material can be used (the PHP License, for this
project) by others.
--
Dan Scott
Laurentian University
--
Derick Rethans
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
On Fri, 30 Nov 2007, Dan Scott wrote:
> In that case, you should:
>=20
> 1) Have a legal entity that you can assign copyright to (PHP Group and
> PHP Documentation Group are not legal entities and therefore cannot
> hold copyright) and
Actually, I think the issue is more that:
> > > 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...
There is no requirement in most countries* to show that something is=20
copyrighted, as it's a basic right. It's protected by default, so the=20
whole "=C2=A9 2005 IBM Corporation" is unnecessary. None of the other=20
contributers ever required something like this.
=09
* Atleast in the Netherlands, and what I gather from wikipedia also in=20
the US through the Berne convention=20
(http://en.wikipedia.org/wiki/Berne_Convention_for_the_Protection_of_Litera=
ry_and_Artistic_Works)
regards,
Derick
--=20
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--8323329-1094291151-1196435639=:20723
Content-Type: text/plain; charset=us-ascii
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--8323329-1094291151-1196435639=:20723--
Jay Pipes
>>> No, it is not more important. 99.9% of PHP users don't care what process
>>> process in the world but no support for what people need - people won't
>>> use PHP just to commend us for oh so good process. Process is important,
>>> but it's a *tool*, not the *goal*.
>> that number at 97.3%. ;-P
>>
>> Besides, as I read the message you quoted, my understand was that
>> Pierre was inferring that it's more important for the community to
>> have standardized guidelines for contributions, rather than bend to
>> the whim of one party: in this case, IBM.
>
> Ok, Kreskin - assuming you're as out of the loop as most of the rest
> of us, if this is purely an IBM thing, why are MySQL AB employees
> signing up for this (see CVS account request from Jay Pipes)? MySQL
> AB has its own CLA for contributions to the MySQL code base:
> http://forge.mysql.com/wiki/MySQL_Contributor_License_Agreement. Maybe
> they're the ones pushing for a CLA this time around.
No, MySQL is not pushing for CLAs to be used for PHP core components.
MySQL is the owner of the MySQL code base. That is why we require our
contributors to sign CLAs (Contributor License Agreements); otherwise,
we would not be in the position to offer our server in the same form
dually licensed both under the GPL and under commercial licenses. We
have always developed MySQL with this central control, and our ecosystem
is aware of it.
With PHP, the situation is different. The foundation of PHP was laid by
Rasmus Lerdorf together with a large group of independent developers,
and the central parts of PHP underly a different license and copyright
regime from MySQL.
Given this different licensing background, we understand that core PHP
developers don't favour CLAs. They grew PHP without CLAs and without one
single, commercial copyright holder. And they see no milestone event
absolutely requiring CLAs at this point.
At the same time, we do understand that from the point of those who
advocate CLAs, CLAs are the default way for achieving clarity on IP
ownership. That said, from our perspective, there is no compelling need
for substantial change from status quo.
-Jay
Jay Pipes
Daniel Brown
> On Fri, 30 Nov 2007, Dan Scott wrote:
>
> > In that case, you should:
> >
> > PHP Documentation Group are not legal entities and therefore cannot
> > hold copyright) and
>
> Actually, I think the issue is more that:
>
> > > > 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...
>
> There is no requirement in most countries* to show that something is
> contributers ever required something like this.
>
>
>
> regards,
>
> Derick
>
> --
Derick,
You're completely correct, if they reside in a country that signed
on with the Berne Convention. The only reason one would want to
register the Copyright (in the United States) would be if there was
anticipated infringement for which the author or Copyright holder
would be eligible for legal recourse.
http://www.copyright.gov/help/faq/faq-general.html#mywork
--
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.
--
Daniel Brown
[snip]
> With PHP, the situation is different. The foundation of PHP was laid by
> Rasmus Lerdorf together with a large group of independent developers,
> and the central parts of PHP underly a different license and copyright
> regime from MySQL.
On a side note, did anyone ever say "thank you" to Rasmus, Zeev,
or Andi? I jumped on with PHP after finding it by accident back in
1997, and have never regretted it for a moment. It's so much less
stressful - and allows me to retain more hair - than Perl. You guys
saved my ass a bunch of times without even knowing me!
We now return you to your regularly-scheduled debate thread.
Johannes Schlüter
On Thu, 2007-11-29 at 21:16 +0200, Jacques Marneweck wrote:
> >> We do have peer-review after all.
> >
> > Not on CLA'd code we don't.
>
> Steph the CLA seems to just relate to the docbook xml specifications
> for PDO.
If the spec is CLAd what will the implementation be? Do you expect a
spec needs stronger protection than the code? I'd say it's usually the
other way round.
On a side-note: It's not only about peer review - without signing the
CLA one might still read the code and send reports to the maintainers.
But we can't maintain it! This is a major change in the development
process, currently everybody with CVS account, which you can get quite
easily compared to many other projects, can fix any bugs in every place
(ok, Zend/ and TSRMLS/ are a bit limited, but still) and if we decide on
a API change, like the recent change with refcounts the required fixes
can easily applied.
With code, which is bundled and under a CLA everybody who wants to do
even simple changes, fixing compile errors, ... is _forced_ to sign it
for doing serious work.
If the active developers would agree on that (which I don't think will
ever happen) then there won't be a problem - but getting it from more or
less the outside without prior notification/discussion is plain stupid
imo.
Rules about the development process have to be set by the developers
doing the work, not by companies thinking "They did good work, let's
benefit from them." (even if they do some work for that - the main work
will still be done by others)
johannes
Steph Fox
> On a side-note: It's not only about peer review - without signing the
> CLA one might still read the code and send reports to the maintainers.
I was responding to Richard when I wrote that. He was operating under the
assumption that php.net have control over what goes into a CLA'd module, and
that's the sense in which 'peer review' was used in his post.
> But we can't maintain it! This is a major change in the development
> process, currently everybody with CVS account, which you can get quite
> easily compared to many other projects, can fix any bugs in every place
> (ok, Zend/ and TSRMLS/ are a bit limited, but still) and if we decide on
> a API change, like the recent change with refcounts the required fixes
> can easily applied.
>
> With code, which is bundled and under a CLA everybody who wants to do
> even simple changes, fixing compile errors, ... is _forced_ to sign it
> for doing serious work.
Precisely.
- Steph
Edward Z. Yang
> So an author can and should maintain copyright over the material they
> contribute, but they contribute it under a license that specifies the
> terms under which that material can be used (the PHP License, for this
> project) by others.
Well, in theory, at least. Many open source projects ask for copyright
to be assigned to them (GNU is one notable example) because it 1. makes
changing licensing terms easier (for better or for worse) and 2. it
makes it a lot easier to prosecute copyright violation (single entity
versus multiple entities that have to coordinate).
See: http://www.gnu.org/licenses/why-assign.html
--
Edward Z. Yang GnuPG: 0x869C48DA
HTML Purifier <http://htmlpurifier.org> Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
chris#
On Fri, 30 Nov 2007 10:58:01 -0500, "Daniel Brown" <para...@gmail.com> wrote:
> On Nov 30, 2007 10:37 AM, Jay Pipes <j...@mysql.com> wrote:
>
> [snip]
>
>> With PHP, the situation is different. The foundation of PHP was laid by
>> Rasmus Lerdorf together with a large group of independent developers,
>> and the central parts of PHP underly a different license and copyright
>> regime from MySQL.
>
> On a side note, did anyone ever say "thank you" to Rasmus, Zeev,
> or Andi?
INDEED. Good point.
May I take this opportunity to send a hearty "thank you" to Rasmus, Zeev,
and Andi?
Thanks! While I am still a v.4 lover, I couldn't be more grateful for your having
invented, and perpetuated such a great concept, and language. Here's to
you all!
> I jumped on with PHP after finding it by accident back in
> 1997, and have never regretted it for a moment. It's so much less
> stressful - and allows me to retain more hair - than Perl. You guys
> saved my ass a bunch of times without even knowing me!
>
> We now return you to your regularly-scheduled debate thread.
>
> --
> 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.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
/////////////////////////////////////////////////////
Service provided by hitOmeter.NET internet messaging!
.
Tomas Kuliavas
>> > > 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...
>
> There is no requirement in most countries* to show that something is
> copyrighted, as it's a basic right. It's protected by default, so the
> contributers ever required something like this.
>
> * Atleast in the Netherlands, and what I gather from wikipedia also in
> the US through the Berne convention
> (http://en.wikipedia.org/wiki/Berne_Convention_for_the_Protection_of_Literary_and_Artistic_Works)
>
TRIPS. Copyright is granted automatically and computer software is
regarded as "literal work". All World Trade Organization members sign it
(one chapter in your link). Only time travelers knew about computer
software in 1886.
http://en.wikipedia.org/w/index.php?title=Image:WTOmap_currentstatus.png&oldid=167880578
--
Tomas