Tvheadend Licensing
Tvheadend Licensing
Many of you are probably aware of the message I put out last month regarding the state of the project. Whether it was a happy coincidence or was spurred on by the announcement there has been some increased input into the project and I thank people for that. Let's just hope I can find the time to keep up with the reviewing of submitted code! Or persuade people to join the core team!
One topic that was raised in response to my announcement was that of licensing, and specifically the limitations that the GPLv3 license could have on potential commercial input. Now this is something that was not new to me, and indeed when I first discussed with Andreas opening the project up to the community we did discuss the topic and the relative merits. But at the time it was deemed too much effort to investigate further,
However things have changed since then and we've decided that we are going to push ahead with various efforts that could help put the project on a better footing going forward. In response to this we're doing 2 key things:
1. We're setting up a UK company, Tvheadend Foundation CIC. The CIC stands for Community Interest Company. It's a not-for-profit structure, that's somewhat similar to a charity, but with slightly less regulation. Really the project isn't necessarily big enough to warrant forming such an entity, however to properly handle the licensing changes we are planning, it's an unfortunate side effect.
2. We're going to be asking all contributors to sign a Contributor License Agreement. This will confer on the company/project a full license to do with the software as we see fit, including potentially re-licensing (though the specifics of the CLA will carefully limit what licenses would be allowable). I have already sent out an initial email to get provisional responses on the proposal, this was very positive and most people responded in the affirmative. There are a few that have not responded and we will consider our options regarding those, but they represent a relatively small percentage of the code base.
Our initial intention is NOT to change the GPLv3 license, at least not immediately, at least one of the core team (that will also be a Director of the company) is not entirely convinced with the original proposal to re-license using GPLv2. However we've agreed on this approach as it will give us the potential to change in the future if we believe an opportunity presents itself that would provide clear benefit to the project if we were to re-license using a less restrictive license.
I will try and keep people informed and those of you that have contributed code, whether it be present in the current code base or not, expect to receive another email from me regarding signing of the new CLA.
Regards
Adam (on behalf of the Team)
Comments
Can you open up the point 2 a little bit? How will you handle the CLA signing and do you expect that formality to affect people's willingness to contribute?
It would seem to me that this is a rather heavy process that you're going through and it is not obvious to me what are the benefits of doing it this way, but I'm sure that you have your reasons for doing this. If that will benefit the community, I'm all for it.
Olli,
Based on the feedback from the 50+ contrib's I got a response from (some were un-contactable due to invalid emails, a small number never replied) I doubt it will unduly affect contributions. The vast majority of input comes from a small number of people, who I expect to be unaffected, and I hope the process will not be too onerous for those that want to make small (fly-by) contributions. But there is always a risk, its a balancing act as always.
However the benefit of giving the team full control of the code so that we can use it however we feel will best benefit the project (within the limitations imposed by the CLA) will, in my opinion, outweigh any drawbacks. I completely accept some may see this as overkill. But given the situation we find ourselves in, i.e. contemplating a license change and having to make an effort to contact all existing developers and get agreement from them anyway, it seems a logical step to get them to sign CLAs. And all future contrib's as well so as to protect ourselves from having to go through this process again in the future.
The original plan was that we simply wanted to switch to GPLv2, and while I have agreement for the vast majority of the code base, some significant contributors are not entirely convinced with the move to GPLv2 at the moment. However I have persuaded them that if we get CLAs signed (including by them) so that we're in a position to change the license in future. We will only do so if we can see a clear opportunity that will benefit the project. And the exact details of how we re-license may depend on the opportunity that's presented. For example we might license a specific version of the code as v2, but retain the v3 license on the working code, though to be honest this isn't something we've thought through in detail.
With regard to the specifics of what people will need to do. Anyone that has contributed, and does not intend (doesn't mean they can't change their mind) to contribute further is able to simply send an email with the CLA attached and a statement that they agree (though preferably they will fill in PDF form with necessary info: name, email). Once I have agreement from the other members of the team I will be sending out an email to these people.
For anyone wishing to contribute in the future, they will need to sign an online CLA. This involves going to clahub.com (sign-in with github credentials) and fill in the short form agreeing to the CLA. It's 2 mins of effort that I really hope won't put people off, especially given what they're getting in return (which is hours, probably years, of effort from the existing developers). All contributions will then need to come via github, so that we can properly verify the CLAs are in place (exceptions may be made in special cases).
Certainly its not our intention to make contribution to the project harder! If I didn't think there was a benefit to the project I certainly wouldn't be undertaking this action, as its far from trivial and requires a significant amount of effort on my and the rest of the teams part.
Adam
What I read just frighten me. When you produce code, unless you are employed to do it, you own the copyright and you may transfer part of your rights with a license, be it GPL or not. Accepting to transfer via another license does not necessarily means you want to give up the copyright ownership ("full license" in your wording).
As pointed out, the type of action the company will do needs to be severely defined if you want to get people to be comfortable with it (e.g I change the license to a BSD style one, make a commercial product with it and do no more distribute the code).
When you sign an agreement that you're handing over control to Tvheadend's team, and that agreement clearly states that you give up your copyright, then it's perfectly fine for Tvheadend's team to put whatever license they like on that code. It just has to be mentioned in the copyright notice of the code that it's (potentially) dual licensed.
Exactly the same construction as we use with libCEC: http://www.pulse-eight.net/contributors
Eric, strictly speaking your statement regarding transfer of rights via GPL etc.. is not accurate. But I won't go there, is a horribly complex legal semantic that I don't fully understand myself. The main thing is that a CLA does exactly that, but it can have additional clauses such as a license to choose the outbound license.
And just to be clear, it will actually be a CLA, NOT a CCA.
A CLA grants the licensee (Tvheadend) a license to do with the code anything within the bounds of the license. Which can include the right to re-license as they see fit. Though on that last point our specific license agreement will include a restriction clause, allowing only approved OSI licenses. More info on the specifics of the CLA will be announced soon.
However ownership of the copyright for the commit strictly still resides with the author, you're still free to use that code as you see fit. The CLA in no way restricts your rights.
A CAA however is somewhat more rigid. It transfers Copyright from the original author to the project/company/etc.. In this case the original author gives up all rights to the code and is not even free to use that code elsewhere without permission from the project/company. Clearly this does not suit our requirements.
On your specific example the CLA would allow us to use a BSD license, which would in turn allow people to create a closed product without pushing code back. The project would not be able to do this due to the governance of the company, being a CIC (social enterprise) the company law restricts us from doing that. Of course it doesn't restrict someone else, which strictly I guess could be us under another name.
But the reality is no one on the project team is the least bit interested in doing that. The only reason we're considering this move is to allow more input from commercial entities (something you yourself championed) that wish to enforce a closed platform without breaching the terms of the license.
The reality is that all this stuff is mostly nonsense when it comes to protecting the code from abuse and use in closed source products, be it closed source or closed hardware. We don't have the resources, nor the inclination to actually fight such breaches. And you've only got to look at teh number of chinese clones that breach licenses to know they're mostly meaningless. What we are trying to do is allow more reputable companies to use our code without breaching the license.
And of course, even if we decided to switch stuff to a more permissive license, create a company (or someone else do so) to exploit that and never provide any useful feedback to the project. We still can't remove the original source etc.. that's still publicly available under the original terms.
But again, just to be clear (and so far there has been almost no dissent on this front, since I think most people can clearly see that I and the rest of the team are not in this for commercial / personal gain etc..) there is absolutely no intention to do anything that might harm the Open source project. A certain level of faith is required that the project team are doing things for the right reasons and will do what they consider best for the project.
Adam
Lars,
In a sense you just give a perfect example of why a commercial company does this type of agreement => you build hardware with libcec build-in and do not want to be annoyed with copyright owners.
Adam,
I just do not see the rationale for this if not willing to make commercial stuffs. Saying that I do not say it is your intention; not at all. Just for GPL and copyright: if infringing you are sued by the copyright owner on copyright matters not the license by itself. Plus tryn to have the copyright for all lines of code including others that comes from other GPL project wil be hard.
I reread you stuff, and its much clearer. What I was fearing is more a CCA type of paper which is fine for code you know who has the right of each line of code but barely practicable as soon as someone incorporates other OSI compatible code.
Eric,
The reality is its pretty much impossible in both cases, if your don't own the copyright to the code, you have no legal right to sign either agreement.
But it provides some level of protection for the project, you sign an agreement (and differing projects require differing levels of formality. Fsf is very strict for obvious reasons, we will be far less formal) that specifically states you will own the copyright For any submissions. And if anyone refutes this we have a slightly better level of audit trail.
The requirement for the outbound license is simply to give the project/company flexibility to potential relicense of we see a benefit to the project (not the company, since the company is only there to safe guard the assets, code, of the company). You just have to take it on faith that we won't do something that could be detrimental to the future of the project. But I think (or hope) that the input already given by Andreas and myself (plus others) clearly indicates our general intent.
Adam
Having done the FSF paper once for gdb remote debugging code (more than 10 years ago and I still remember it: I had to use company lawyers and you know what it means...), I will agree for strictness :-) So please make it simpler indeed.
Last word about GPV2 vs GPLV3 enabling to attract more developers by companies that may start using the tvheadend code in their products, I really think it is a chicken and eggs problem. Our policy for example forbid to incorporate GPLV3 code in our embedded devices because we cannot accept that people can modify the device firmware (we sign it on purpose) and I know many, many companies with the same policy for the very same reason. So this will rules out against using tvheadend beforehand and people won't even look at it. But this is copyright owners' decision and I respect it.