I think continuing the license discussion is worthwhile. For the purpose of this conversation as I see it the WikiMedia Foundation is providing services (defined next) to two facets of the MediaWiki community (core and extensions developers): a) Repository to store/revision code (svn or soon git) b) Code review mechanism with community as participants (more for core but usable by extensions) c) Permissive environment where the community can help the community (commit in on each other's code) d) Continuous integration testing (again more for core... is this usable by extensions somehow?) e) Packaging for both core and extensions with backwards-compatibility helpers (this is huge for extensions) This is great and I hope WMF keeps providing these resources, not just to core but also all extensions developers who would benefit. Given that WMF is providing it, they are setting some requirements about how and in what situations it can be used, as well as vetting who can use it. As long as the requirements are not too strict, this seems reasonable and doesn't devalue the service in the first place (and in turn harm MediaWiki). The current attitude by the MediaWik communityi as a whole to anyone walking in on IRC (you have code? commit ASAP!), these lists (see the message a few days ago -- just get commit access its easier if you check these changes in yourself), and the wiki access pages themselves (as long as you're a competent programmer, we'll take you). Given these factors I think it's important to be as permissive as possible in terms of licensing to allow the widest range of contributors, while still enforcing a minimum standard that ensure the community benefits as well from people using the services. As you mentioned below, changing someone's license on their extension, while sometimes legal, is definitely a no go. In my mind at that point you're forking their project, and saying "well now you can contribute to my fork if you like"... I don't expect such a stipulation to be contested much. To be clear, I had spent the last 7 weeks "justifying" my request with no feedback. It's not about a yes/no. But more on that in another thread, this is about licensing issues neh? It shouldn't torpedo anything. As the community grows you will encounter people wanting to use their own licenses on their own code in their own modules more and more. Having a strict requirement to use what I dare call community services is harmful to MediaWiki. To make it clear, copyright assignments (what I had in my original request) are common in the FOSS community, as you pointed out you talked about them yourself on your blog and wmf talked about having one for MediaWiki at one time. They are most common and beneficial for GPL'ed projects that wish to dual-license. So here's question #1, which you seem to have given your stance on, and leveraged WMF behind. Q1. Should WMF allow Dual-Licensed extensions in the MediaWiki repo? Is community consensus even worth gathering, or is this a "closed issue"? If you look at a community like Wordpress, there is a lot of commercial players involved in their plugin ecosystem. Of course they can always host and make their own tools, but does turning them away from community incentives to come to MediaWiki the right choice? Q2. Should people using any OSI approved license without modification be able to use the MediaWiki repo? You mentioned in your mail GPL v2, BSD, MIT, LGPL (and similar) but excluded mentioned a soft exclusion for GPL v3. This seems overly restrictive for extensions. As some people mentioned on the lists already, maybe just blanket approving anything OSI approved seems wise? If you can legally fork it, it seems like that should be enough, the community will always be able to benefit from that code. If having the code be compatible with core licensing (so that you can fold code in) is important, then any GPL-compatible license may work. Q3. Should people who add a clause to their license that all contributions are to be made under the same license be turned away? This is similar to how the GPL comes with a clause that requires all contributions to be GPL'ed (except with the distribution requirement, so is still more commercial friendly). If someone adds a similar clause to their license (say a BSD license), can they still make use of the services? Of course given Q2 there is the issue of whether such a clause invalidates GPL-compliance, or how it could be worded so as not to. 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). I discussed this particular case with you in IRC, but it didn't seem to me we were able to conclusively decide if such a clause is warranted or not (merely that you do not support it). You've encouraged me to bring this question of if it's even needed to the OSI license-discuss, and I've submitted a message there, hopefully it gets approved for discussion soon and we can have further clarification. For my own extension I'll likely take their recommendation. I think in the long run a clearer license policy for the repo is a good thing, if nothing but to make sure people don't waste their time trying to apply.

At the risk of de-railing the discussion, I think everyone can agree that having good high quality extensions for MediaWiki is good for MediaWiki. The license an extension uses does not harm MediaWiki in any way. Nor is this discussion really aimed at proposing a re-licensing of the core. Please stay on-topic. The question is should a WMF-funded service (and the MediaWiki community) allow 3rd party to make use of said services if they have dual-licensed code. They are already contributing positively to MediaWiki a) they have an extension we can use that better our lives (maybe) and b) they are releasing at least a portion of their code with a permissive license which everyone can benefit from. Whether it be GPL or otherwise. True maybe we could benefit MORE, but it's not harming the core or the community. - Olivier

On Mon, Nov 7, 2011 at 1:15 PM, Erik Moeller <erik(a)wikimedia.org> wrote: Given that I wasn't using the GPL, I was concerned that anyone committing against my code would do so under "all rights reserved" and would effectively be forking my code from the point of their revision. I wanted to make sure the code stayed under my BSD-2-Clause license. My first stab at this was to use a contributor agreement that contained a copyright assignment, as people do for dual-licensing with GPL code. A little bit later I found the Zend Framework license, which uses a BSD-3-Clause and a contributor agreement (which forces contributions to give ZF a license to the code in the contribution, not copyright assignment) and I quickly changed to suit. Rob seems to think this may still be unnecessary, and I've sent a mail to the OSI license-discuss mailing to list for clarification on that matter. But the discussion as I set it out in my previous email with the 3 questions are much more general then my own particular case, and I think the community would benefit from consensus on how applications in each case should be handled in the future. Q1. Should WMF allow Dual-Licensed extensions in the MediaWiki repo? Q2. Should people using any OSI approved license without modification be able to use the MediaWiki repo? Q3. Should people who add a clause to their license that all contributions are to be made under the same license be turned away? I gave my thoughts one each question in my previous email. My original request would of been answered by a clear stance on Q1. My current code would have a clear answer given Q3. But I doubt I will be the last to try any of the 3.

Olivier Beaton wrote: Why did you think so? I'm of the same opinion as bawolff: If you edit a file with a header "This is under BSD license", and not changing it, or otherwise conflicting with that statement, I consider you're releasing that commit under the BSD license. Now, it would certainly be possible that someone did a commit saying "This is my own copyright, and nobody is allowed to make derivatives of this", but (a) I expect that would be immediatly reverted (what is doing such unfree code on our svn, and further /restricting/ the previous one?) (b) It's silly to commit it to a public repo if you want to keep it for your own. If someone does a magic improvement to it, it may want to keep its changes for himself and not release them. Note that GPL doesn't prevent that, either (only if there's redistribution). IMHO, such person would do a better job providing it upstream, first as a good netizenship (give back to people which gave you the system), and second because that would allow for being better maintained, and remove the pain of merging each time (so it's also a good thing from an egoistic perspective). Olivier proposal further explained by Tim: I'm not sure if Olivier got confused with licenses, or is it just me who got confused with Olivier reasons. Using a BSD license with an extra same-license clause it's like making CC-BY a CC-BY-SA. You can do it, but then CC-BY isn't the best description / you may have chosen the wrong license. There are some differences, as that wouldn't apply to users but only upstream. I find natural that he wants to keep the extension with the original license, and the sensible thing to do among us is to keep the license chosen by the original author. Moreover, a contribution able to push a license change would need to make a 'substantial' change, or might qualify as PD. So going through a copyright assignment to the extension author looks like an over-complication to me. Each community has its own ways to do thing. That may be appropiate for a community strict on non-SA free licenses where each module is tightly handled by a owner, but I don't think it would work for us. Yes. Yes. That's a greyer area due to the "Are extensions linked?" debate, as such license doesn't seem GPL-compatible. Still, it may be better to have it with a license warning than not having it in the repo. Authors of such extensions should be encouraged to dual-license it with a GPL-compatible license. If instead of a MediaWiki extension, it's an independent piece, that's an emphatic allow.

What do I gain by not using gpl? Commercial use and forking under a license of your choice. The only thing that concerns me using bsd is how to accept contributions that im not merging in safely. Is zend framework concern with bsd and their use of a contrib agreement ? My employer asked me to make modifications to mw for their use, i chose instead to spend my free time so i can share them with others. I cant use gpl even if i wanted to. On Nov 7, 2011 7:31 PM, "Mark A. Hershberger" <mhershberger(a)wikimedia.org> wrote:

On Mon, Nov 7, 2011 at 10:54 PM, Tim Starling <tstarling(a)wikimedia.org> wrote: That would of course be the (please print out this form, sign it, scan it, then email me a copy) sure-fire way of contribution agreements. However if one hoped to make use of a service like the MW repo, this seems like too much of a hassle and like Rob mentioned, you're then better off just running your own show, elsewhere. And as you mention with translators it becomes near-impossible. Agreed, like I mention above, short of getting a signed document, these things aren't legally binding, so the question of it's even worth having comes up pretty strongly. I've sent the question off to OSI license-discuss, I'm hoping they'll approve the message for discussion there so I can get some feedback on what more knowledgeable people think about BSD and contributions from outside sources. They may be able to say what we hope to hear "the BSD header is enough" or what I fear "you need signed contrib agreements" or some middle ground "here's some legal-lawyer speak that project X,Y,Z have used to mitigate this problem". I hope you don't mean the BSD license, and just meant the pseudo contributor agreement license-amendment I was toying with. But in the end, my particular situation is just one of 3 that I mentioned could arise, with the other two being much more common. I don't want this discussion to just focus on my particular struggle with how to license my code, but on how MW might deal with more general non GPL-only code. Like say someone wanted to commit using the Microsoft OSI-approved license, or some non-gpl-compatible OSI license. And of course the case of GPL/propriatery dual-licensing arrangements. Especially given how some people are doing some massive things with extensions (like SMW) I don't see it as unrealistic that this will come up, especially if building a healthy and strong extension developer continues on it's current track.

On 08/11/11 02:52, Olivier Beaton wrote: GPL doesn't preclude commercial usage. It requires you give others the ability to give the same (freedom) rights you gave them, but if the extension is going to be published in our svn, that doesn't seem a problem. Depending on your employer, you may be able to develop it in company time releasing the result under a free license (if the collaborative method results in having a better extension, your company will benefit from having the FOSS developers improve it, and reduce the time you'll need to maintain it as a fork).

On 8 November 2011 18:02, Olivier Beaton <olivier.beaton(a)gmail.com> wrote: To what degree are extensions derivatives, under copyright law, of MediaWiki code? Enough to have to be GPLed? That's a thorny one. (WordPress says all WordPress themes are derivatives and must therefore be GPL, for example. There's a thriving cottage industry in selling WordPress themes, but this would mean they wouldn't have much leverage to stop customers then giving them away, even if that's not how copyright technically works.) - d.

IANAL, but I'd think that extensions are "derivative" of MediaWiki in the same manner that my email is "derivative" of the English Language Dictionary. DanB

The FSF's theory of GPL inheritance is based on the idea that your code has only one purpose: to extend the capabilities of GPL'ed code. It has no other use or function. So, to distribute it under any other license is an attempt to create a collective work that violates the GPL. This case is trivially destroyed by creating unit test code which isn't GPL'ed. On Nov 8, 2011 1:08 PM, "David Gerard" &l