Backported faster RLock to Python 2.6.
Hi devs, the company where I work has done some work on Python, and the question is how this work, owned by the company, can be contributed to the community properly. Are there any license issues or other pitfalls we need to think about? I imagine that other companies have contributed before, so this is probably an already solved problem. Regards Johan Gill Agama Technologies
On Thu, Jan 7, 2010 at 10:46, Johan Gill <johan.gill@agama.tv> wrote:
Hi devs, the company where I work has done some work on Python, and the question is how this work, owned by the company, can be contributed to the community properly. Are there any license issues or other pitfalls we need to think about? I imagine that other companies have contributed before, so this is probably an already solved problem.
I'm not a license lawyer, but typically your company needs to give the code to the community. Yes, it means it stops owning it. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Thu, Jan 7, 2010 at 1:12 PM, Lennart Regebro <regebro@gmail.com> wrote:
I'm not a license lawyer, but typically your company needs to give the code to the community. Yes, it means it stops owning it.
This is incorrect. The correct information is at http://www.python.org/psf/contrib/. Schiavo Simon
Lennart Regebro wrote:
On Thu, Jan 7, 2010 at 10:46, Johan Gill <johan.gill@agama.tv> wrote:
Hi devs, the company where I work has done some work on Python, and the question is how this work, owned by the company, can be contributed to the community properly. Are there any license issues or other pitfalls we need to think about? I imagine that other companies have contributed before, so this is probably an already solved problem.
I'm not a license lawyer, but typically your company needs to give the code to the community. Yes, it means it stops owning it.
As Simon pointed out, while some organisations do work that way, the PSF isn't one of them. The PSF only requires that the code be contributed under a license that then allows us to turn around and redistribute it under a different open source license without requesting additional permission from the copyright holder. For corporate contributions, I believe the contributor agreement needs to be signed by an authorised agent of the company - the place to check that would probably be psf@python.org (that's the email address for the PSF board). Assuming the subject line relates to the code that you would like to contribute though, that particular change is unlikely to happen - 2.6 is in maintenance mode and changing RLock from a Python implementation to the faster C one is solidly in new feature territory. Although a backport of the 3.2 C RLock implementation to 2.7 could be useful, I doubt that backporting code provided by an existing committer would be the subject of this query :) Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Thu, Jan 7, 2010 at 13:23, Nick Coghlan <ncoghlan@gmail.com> wrote:
As Simon pointed out, while some organisations do work that way, the PSF isn't one of them.
The PSF only requires that the code be contributed under a license that then allows us to turn around and redistribute it under a different open source license without requesting additional permission from the copyright holder.
Even if the contributed code as in this case is a method in an existing file? How does that work, how do they keep ownership of one method in the threading.py method? :-)
Assuming the subject line relates to the code that you would like to contribute though, that particular change is unlikely to happen - 2.6 is in maintenance mode and changing RLock from a Python implementation to the faster C one is solidly in new feature territory. Although a backport of the 3.2 C RLock implementation to 2.7 could be useful, I doubt that backporting code provided by an existing committer would be the subject of this query :)
Ah. I probably misunderstood what the suggested contribution was. Maybe it was a separate file, which I didn't get. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On 07/01/2010 13:11, Lennart Regebro wrote:
On Thu, Jan 7, 2010 at 13:23, Nick Coghlan<ncoghlan@gmail.com> wrote:
As Simon pointed out, while some organisations do work that way, the PSF isn't one of them.
The PSF only requires that the code be contributed under a license that then allows us to turn around and redistribute it under a different open source license without requesting additional permission from the copyright holder.
Even if the contributed code as in this case is a method in an existing file? How does that work, how do they keep ownership of one method in the threading.py method? :-)
When contributing code to Python all work remains copyright the original author. The combined work is copyright *everyone*. The PSF has a license to distribute it, which is all that is important. How you meaningfully exercise your ownership over chunks of code is left for the reader to determine... (i.e. copyright and ownership are legal terms that don't necessarily mean anything *practical* in these situations.) Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
On Thu, Jan 7, 2010 at 14:15, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
(i.e. copyright and ownership are legal terms that don't necessarily mean anything *practical* in these situations.)
OK, fair enough. :-) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On 01/07/2010 01:23 PM, Nick Coghlan wrote:
As Simon pointed out, while some organisations do work that way, the PSF isn't one of them.
The PSF only requires that the code be contributed under a license that then allows us to turn around and redistribute it under a different open source license without requesting additional permission from the copyright holder. For corporate contributions, I believe the contributor agreement needs to be signed by an authorised agent of the company - the place to check that would probably be psf@python.org (that's the email address for the PSF board).
Assuming the subject line relates to the code that you would like to contribute though, that particular change is unlikely to happen - 2.6 is in maintenance mode and changing RLock from a Python implementation to the faster C one is solidly in new feature territory. Although a backport of the 3.2 C RLock implementation to 2.7 could be useful, I doubt that backporting code provided by an existing committer would be the subject of this query :)
Regards, Nick.
Yes, it is the new RLock implementation. If I understood this correctly, we should make a patch against trunk if anything should be contributed. Do you mean that we wouldn't need the paperwork for backporting the original patch committed to py3k? Regards Johan Gill Agama Technologies
Johan Gill wrote:
Yes, it is the new RLock implementation. If I understood this correctly, we should make a patch against trunk if anything should be contributed.
Yep.
Do you mean that we wouldn't need the paperwork for backporting the original patch committed to py3k?
Whether or not a contributor agreement was essential for this particular contribution would depend on how much new code was needed for the backport, but the bulk of the copyright on the C RLock code would remain with Antoine regardless. However, sorting through the legalities of the contributor agreement really is the best way to make sure every is squared away nice and neatly from a legal point of view. After all, even if I was a lawyer (which I'm not, I'm just a developer with an interest in licensing issues), I still wouldn't be *your* lawyer :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
participants (5)
-
Johan Gill -
Lennart Regebro -
Michael Foord -
Nick Coghlan -
Simon Cross