License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

Rob Lanphier-4
Hi everyone,

There's a ton of issues conflated in the SVN Extension access thread.
I'm sure there are things we can improve about that process, and I'll
talk to the people involved next week about it.  I've asked Sumana not
to rush out a response on this thread today, and I ask that we table
non-license related issues until after Monday.

Now, on to the license issues:

On Fri, Nov 4, 2011 at 10:32 PM, Olivier Beaton
<[hidden email]> wrote:
> There seems to have been concern with my original license, a
> BSD-2-Clause with copyright assignment so I don't lose the ability to
> distribute my code, this isn't the GPL, you need a contributor
> agreement with BSD (as I understand it).

Olivier, I'm sorry your access request didn't go the way you hoped,
but this issue alone is enough to torpedo your access request.  I'm
generally sympathetic to the desire of commercial entities to have a
copyright assignment clause (as I've written about before[1]).
However, to the best of my knowledge, Wikimedia Foundation is not
about to dive into that thicket, and I'd personally be vehemently
opposed to us doing so.

As best I know, we don't have a stated policy for the license
conditions for code that is contributed to our source repository, but
we probably should.  I'll take a stab at the previously unstated
policy now:
1.  We have a strong preference for "GPL version 2 or later" (more on
this in a bit).
2.  We generally accept licenses that are compatible with "GPL v2 or
greater".  BSD 2 and 3 clause, MIT, LGPL, and many other licenses fall
into this category.
3.  Don't mess with the license headers of code other people wrote
without their consent, because:
a)  even in cases where it's legal (e.g. while it's perfectly legal to
slap a GPLv2 header on code that was previously under BSD), it's rude.
 Don't do it.
b)  it's frequently not legal.  Don't "fix" someone's license if you
don't believe it is the proper license under this policy.  Revert the
code instead.
4.  GPLv3 usage is still largely an undecided matter, and we ask that
committers not use this license in any GPLv2+ licensed extension or in
core.  I believe that some extensions may be checked in under this
license, but we're avoiding it for WMF-created work, simply because of
the one-way nature of the decision to move to it.
5.  Anyone can contribute to anyone else's code under the stated
license for that code, with no other strings attached.

Don't take the above as gospel...that's just pretty much the set of
assumptions I've been operating under, and I suspect it's more-or-less
what others are operating under as well.  We can have a debate right
here in this thread about whether this is the right policy to have,
but I'm not faulting anyone for making these assumptions.  There may
also be extensions that don't adhere to this policy.  If there are, we
should probably have a discussion about why that is, and what (if
anything) we should do about them.

On "GPL version 2 or later", what is meant by that is that the license
header explicitly say that the file is licensed as GPL "either version
2 of the License, or (at your option) any later version.".  Not
"choose whatever version of the GPL you want".

Olivier, I'm sorry this wasn't clearly communicated to you until now.
If having copyright assignment is a requirement for your extension, I
suggest you host your extension elsewhere.

Rob
[1] http://blog.robla.net/2010/thoughts-on-dual-licensing-and-contrib-agreements/

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

Olivier Beaton
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.

> Olivier, I'm sorry your access request didn't go the way you hoped,
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?

> but this issue alone is enough to torpedo your access request.
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.

>  We can have a debate right here in this thread about whether this is the right policy to have,

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.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

David Gerard-2
On 7 November 2011 15:08, Olivier Beaton <[hidden email]> wrote:

> 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


Copyright assignments are inherently harmful, as their only use is so
that the assigned-to body can defect on the implicit covenant of open
source: that is, so it can take people's contributions private.

The FSF continues to use them, on the theory that this gives greater
legal protection. While the FSF is quite unlikely to defect (it's
spent twenty-five years behaving as a consistent actor), its legal
theory appears unnecessary (neither the Linux kernel nor BusyBox use
copyright assignments, but both have been spectacularly successful in
pursuing GPL violations) and its continued use makes people think
they're a good idea.

For an example of defection, see Oracle taking MySQL open-core.

Copyright assignments are harmful. They are not some sort of standard
thing in open source. They would be harmful to MediaWiki.


- d.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

Olivier Beaton
> Copyright assignments are harmful. They are not some sort of standard
> thing in open source. They would be harmful to MediaWiki.

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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

Erik Moeller-4
On Mon, Nov 7, 2011 at 8:45 AM, Olivier Beaton <[hidden email]> wrote:
> 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.

Well, in addition to dual-licensing and asking everyone to contribute
under a dual-license, you want everyone to make a copyright assignment
to you, right?

I'm not sure I understand what benefits this brings -- you imply in
your original note that it's required for BSD dual-licensing, but I
don't see why that's true. Could you elaborate on that?

Thanks,
Erik

--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

bawolff
In reply to this post by Rob Lanphier-4
> Message: 10
> Date: Mon, 7 Nov 2011 15:40:58 +0000
> From: David Gerard <[hidden email]>
> Subject: Re: [Wikitech-l] License exceptions in Wikimedia's repo (was
>       Re: SVN Extension Access)
> To: Wikimedia developers <[hidden email]>
> Message-ID:
>       <[hidden email]>
> Content-Type: text/plain; charset=UTF-8
>
> On 7 November 2011 15:08, Olivier Beaton <[hidden email]> wrote:
>
> > 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
>
>
> Copyright assignments are inherently harmful, as their only use is so
> that the assigned-to body can defect on the implicit covenant of open
> source: that is, so it can take people's contributions private.
>
> The FSF continues to use them, on the theory that this gives greater
> legal protection. While the FSF is quite unlikely to defect (it's
> spent twenty-five years behaving as a consistent actor), its legal
> theory appears unnecessary (neither the Linux kernel nor BusyBox use
> copyright assignments, but both have been spectacularly successful in
> pursuing GPL violations) and its continued use makes people think
> they're a good idea.
>
> For an example of defection, see Oracle taking MySQL open-core.
>
> Copyright assignments are harmful. They are not some sort of standard
> thing in open source. They would be harmful to MediaWiki.
>
>
> - d.


You don't need to go for ideological reasons to go against copyright
assignments to individual extension authors. It's simply impractical
in the MW repo where many people make batch maintenance commits to
expect all of those people to assign you their copyright (imho).

My understanding is we allow people to commit extensions under
whatever OSI approved license strikes their fancy, and that if you
commit to someone else's extension, then you also release your commit
under that license. This always struck me as common sense...

-bawolff

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

Olivier Beaton
In reply to this post by Erik Moeller-4
On Mon, Nov 7, 2011 at 1:15 PM, Erik Moeller <[hidden email]> wrote:
> Could you elaborate on that?

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.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

Erik Moeller-4
On Mon, Nov 7, 2011 at 10:37 AM, Olivier Beaton
<[hidden email]> wrote:

> 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.

Yeah, I think Rob's right on that, but would be interested to see what
you find out.

I personally don't philosophically object to having extensions in the
repo that require dual-licensing of all future contributions under some
set of OSI-approved licenses, without any kind of copyright assignment.
But I can see that it might be a pain to maintain such a regime in
practice.
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

Platonides
In reply to this post by Olivier Beaton
Olivier Beaton wrote:
> On Mon, Nov 7, 2011 at 1:15 PM, Erik Moeller <[hidden email]> wrote:
>> Could you elaborate on that?
>
> 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.

Why did you think so?

I'm of the same opinion as bawolff:
> My understanding is we allow people to commit extensions under
> whatever OSI approved license strikes their fancy, and that if you
> commit to someone else's extension, then you also release your commit
> under that license. This always struck me as common sense...

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
> 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.

further explained by Tim:

> He wanted to have a contributor agreement which required anyone who
> changed the file in Subversion to assign copyright to him. The content
> was all under a BSD-style license and anyone could modify it, so the
> contract would have to have the form "if you agree to assign
> copyright, I will agree to allow you to commit to this file".
>
> This kind of agreement is quite common in certain circles, but for it
> to work, the person who you're making the contract with has to be able
> to restrict write access to the source code repository. Since Olivier
> wasn't going to be able to restrict commit access himself, and we
> weren't going to do it for him, the contributor agreement didn't make
> sense.

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.


> 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?

Yes.

> Q2. Should people using any OSI approved license without modification
> be able to use the MediaWiki repo?

Yes.

> Q3. Should people who add a clause to their license that all
> contributions are to be made under the same license be turned away?

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.




_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo

Mark A. Hershberger
In reply to this post by Olivier Beaton

Olivier Beaton <[hidden email]> writes:

>> Could you elaborate on that?
>
> 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.

I'm pretty confused by this whole situation.

IANAL, but if you add restrictions such that you require modifications
to be under the BSD-2-Clause license, then it seems like you have
re-invented dual-licensing with the GPL license without any real
benefit.  If that is the case, I am not in favor of adding
yet-another-licensing-scheme to our repository.  But I could be swayed,
given the right argument.

What is the pragmatic benefit of your proposed license?

Mark.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo

Olivier Beaton
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" <[hidden email]>
wrote:

>
> Olivier Beaton <[hidden email]> writes:
>
> >> Could you elaborate on that?
> >
> > 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.
>
> I'm pretty confused by this whole situation.
>
> IANAL, but if you add restrictions such that you require modifications
> to be under the BSD-2-Clause license, then it seems like you have
> re-invented dual-licensing with the GPL license without any real
> benefit.  If that is the case, I am not in favor of adding
> yet-another-licensing-scheme to our repository.  But I could be swayed,
> given the right argument.
>
> What is the pragmatic benefit of your proposed license?
>
> Mark.
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

Tim Starling-2
In reply to this post by Olivier Beaton
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


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

Olivier Beaton
On Mon, Nov 7, 2011 at 10:54 PM, Tim Starling <[hidden email]> wrote:
> 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.

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.

> 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:

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".

> 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
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.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo

Mark A. Hershberger
In reply to this post by Olivier Beaton
Olivier Beaton <[hidden email]> writes:

> 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.

Others have said here, and I agree, that if you modify an extension
which uses the BSD license, then you are releasing your modifications
using the license that the extension is released under.

If you want to make it really clear to people working on the code use a
license header.  You can see how this is done on a large projects
(albeit ones that use only a single license) by looking at Emacs[1] or
FreeBSD[2].

Point being: I think you're trying to solve a non-problem.  If you're
really worried about how to accept contributions and think your
situation is truly unique, consult a lawyer.  Otherwise, follow the
example of others who have gone before you.

Mark.

Footnotes:
[1]  http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/ -- every.el
file is pre-pended with

;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

[2]  http://svnweb.freebsd.org/base/head/ -- every .c file is pre-pended
with

 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 * notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 * notice, this list of conditions and the following disclaimer in the
 * documentation and/or other materials provided with the distribution.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo

Platonides
In reply to this post by Olivier Beaton
On 08/11/11 02:52, Olivier Beaton wrote:
> 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.

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).


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo

Olivier Beaton
If it's on company time it's All Rights Reserved and will never see
the light of day. Way too many lawyers over here. Anyways it looks for
my perticular case I'll probably end up with just a BSD header (was
most likely overthinking/overparanoid), but as I keep repeating, and
which Rob pointed out, it would be a good thing to a have a documented
guideline (based on consensus) about what can be accepted into the
repo. Key questions like is-gpl-compatability a must? Not all OSI
licenses are IIRC.

On Tue, Nov 8, 2011 at 12:50 PM, Platonides <[hidden email]> wrote:

> On 08/11/11 02:52, Olivier Beaton wrote:
>> 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.
>
> 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).
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo

David Gerard-2
On 8 November 2011 18:02, Olivier Beaton <[hidden email]> wrote:

> If it's on company time it's All Rights Reserved and will never see
> the light of day. Way too many lawyers over here. Anyways it looks for
> my perticular case I'll probably end up with just a BSD header (was
> most likely overthinking/overparanoid), but as I keep repeating, and
> which Rob pointed out, it would be a good thing to a have a documented
> guideline (based on consensus) about what can be accepted into the
> repo. Key questions like is-gpl-compatability a must? Not all OSI
> licenses are IIRC.


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.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo

Chad
On Tue, Nov 8, 2011 at 1:08 PM, David Gerard <[hidden email]> wrote:
> To what degree are extensions derivatives, under copyright law, of
> MediaWiki code? Enough to have to be GPLed? That's a thorny one.
>

IIRC, we've discussed this before but never come up with a solid
answer. We really do need to figure out the answer to this.

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo

Daniel Barrett-3
> To what degree are extensions derivatives, under copyright law, of MediaWiki code?

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


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: License exceptions in Wikimedia's repo

Tim Starling-2
In reply to this post by Platonides
On 09/11/11 04:50, Platonides wrote:

> On 08/11/11 02:52, Olivier Beaton wrote:
>> 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.
>
> 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).

GPL allows commercial usage, but it is seen by some as being
anti-commercial, because of the restriction against integration with a
closed-source product. That's why many software projects (e.g. PHP)
refuse contributions of GPL code.

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12