On 08/11/11 02:08, Olivier Beaton wrote:
And here's where I currently stand with my own work. I'm no expert on licensing and my wording so far may not be great, but there seems to be some concern in BSD-like licenses that without such a clause in a shared-commit environment can lead to trouble. Zend Framework is BSD-3-Clause'd and has a contributor agreement to handle IP issues (and not for any dual-licensing goals).
My recommendation is that you contact people who commit code to your extension, and request that they agree to license their contributions under a BSD-style license.
If they do not agree to do this, then you can merge their changes out of your fork on olivierbeaton.com. But knowing the MediaWiki community, I doubt that that will ever happen.
Localisation commits may be slightly tricky. At http://translatewiki.net/wiki/Project:About it says
"Derivative works may also be licensed under the licenses of the respective Free and Open Source projects the translations have been or will be added to."
So in principle it will be fine, but if you wanted to obtain an assurance from every individual translator as to whether have truly agreed to that licensing policy, you would be facing a challenge. If worst comes to worst, you can always distribute a pure-BSD fork which is stripped of localisations derived from translatewiki.net.
As I said before, I don't think a normal contributor agreement can be binding, because you don't control access to the repository. I also don't think your browse-wrap style contract will be binding on all contributors. In OTRS you wrote:
/* By comitting against this file you retain copyright for your contributions and grant them to Olivier Finlay Beaton under the same BSD-2-Clause license (attribution). */
You can't make a contract with someone in such a passive way, you have to bring the terms to their attention somehow and extract their active agreement. Also, as with the copyright assignment, there's a lack of consideration. The committer can explicitly refuse to enter the contract and then commit anyway.
That's why I think that if you want to have a pure-BSD extension with solid legal footing, you should drop these headers from your source files and rely on direct email contact with the extension contributors. That would also have the advantage of being less controversial.
-- Tim Starling