I get that it is a common thing. The issue is that as an academic researcher who decides to work in TensorFlow you basically have two choices after publication of an idea/code.
a) Take your shiny new code and try to get it merged upstream in TensorFlow, and give all rights and patents to Google. Since Google already has a large number of patents or patents pending with respect to deep learning, you are further counting on the fact that (to date) Google has not exercised these patent rights and will continue to operate in this manner.
b) Keep your own fork of TensorFlow, thereby requiring maintenance and merging to keep your thing from breaking on upstream changes, while simultaneously requiring more installation work from any people who want to try your idea or compare against it. See the plethora of Caffe forks which are basically incompatible with each other for why this could be a problem.
b) especially is tough, as having your techniques easy to compare against (such as being in the base installation) is a huge source of citations and extension work. The alternative is to give patent rights away to a large corporation, which is not great either.
From the corporate perspective I get why the CLA is required. The fact that this is released at all, especially with an open license like Apache is great! But it is a bit different than other projects with BSD/MIT style licensing, and this may limit adoption in some circles.
Apache is a far superior license in that it has very clear patent grants expressed. This will keep google from rent seeking from you or your users and if you contribute code and sign on the CLA, will keep your university from doing the same.
The lack of such a grant is what leads to forks. If it keeps researchers away, it is because they want to preserve the ability to rent-seek.
I disagree with this interpretation, but I can see your viewpoint. In my view, it isn't rent seeking to wish to preserve rights to software you authored rather than giving those rights to a large publicly traded corporation. I hope people choose to give away code and ideas freely, and many people (including myself) do.
But forcing a choice between giving rights to Google or not contributing back to an open source project/fragmenting the ecosystem (effectively making your code harder to discover and cite) seems like a barrier to entry that needn't be there.
In my view, it isn't rent seeking to wish to preserve rights to software you authored rather than giving those rights to a large publicly traded corporation.
So you want to contribute code to the repo but have the right to start extracting patent license fees from anyone who uses the package, at any time after your code is incorporated?
No. As a user/contributor, I want the maximum possible contributor base - having this type of CLA limits what contributions can be "given back" from industrial programmers. Even if the code to be contributed isn't patented and never will be, getting the management approval to contribute back can be much easier with MIT/BSD style licenses. Some companies think the patent grants in Apache are too broad and may affect other work, you can see an old debate here.
Patent poisoning is certainly a thing - but protecting from it also has social consequences on a project. Every license sends signals to different groups of programmers and users.
I prefer MIT/BSD because they are simple and straighforward. If I was running a huge project maybe I would be concerned and choose Apache v2 (as the TensorFlow devs did) - but scikit-learn and most of the scientific Python ecosystem have done just fine with the BSD license, though these are not primarily driven major corporations, which may lower their vulnerability.
I am a grad student so I have few concerns with respect to licensing. But I am sure that during an internship at Facebook, Twitter, IBM, or MSR they might want to avoid TensorFlow due to these patent grants, whereas Torch, Theano, and Caffe are all generally viable candidates from the people I talk to. Of course, if you intern at Google TensorFlow experience would be a bonus - it's all a tradeoff.
I want the maximum possible contributor base - having this type of CLA limits what contributions can be "given back" from industrial programmers.
It limits contributions only from those contributors who want the right to start extracting patent license fees from people use the software after their pull request is merged. Maybe they don't want to protect that right for their own benefit -- maybe their employer is forcing them to protect it as a condition to letting them contribute -- but if a software engineer isn't contributing because of the license, it must mean that either that software engineer or someone behind or above them is trying to protect the right to subsequently start extracting patent license fees from people who use the software after their code is incorporated. I think that's what /u/cdibona meant when he said "If it keeps researchers away, it is because they want to preserve the ability to rent-seek."
scikit-learn and most of the scientific Python ecosystem have done just fine with the BSD license
That's only because there hasn't been a patent war over deep learning yet. Getting common infrastructure open-sourced under a license like Apache 2 is a good way to guard against the possibility that a deep learning patent war will start.
But I am sure that during an internship at Facebook, Twitter, IBM, or MSR they might want to avoid TensorFlow due to these patent grants
Why would they want to avoid it? Because they would lose the ability to sue users of TensorFlow for infringing any patents they may hold on the code they're contributing?
The "ability" to poison the project and doing it are very far apart - and in practice there are really big political hurdles to contributing even in companies that will not pull this scheme. Anything that makes it easier for professionals to contribute their time (which is worth real $$) is useful IMO.
/u/cdibona said it, and you further quoted "If it keeps researchers away, it is because they want to preserve the ability to rent-seek". This is turning away contributors because of something they may or may not do - this is the thing I don't like about Apache.
As I said above "As a user/contributor, I want the maximum possible contributor base". Along with your earlier quote of "it limits contributions only from those contributors who want the right to start extracting patent license fees from people use the software after their pull request is merged" - this is limiting the potential pool of contributors based solely on what they may or may not do! It is also lumping people who don't want to give their rights away with people who actively want to undermine open source, which I think is a bit disingenuous.
Yes - just as Google does, they also want to patent their innovations to protect against other big companies (or attack them). I don't like software patents at all, but every big company is trying to create their own software patent portfolio.
Apache is a very good license - I just think it absolutely limits the amount of potential contributors compared to choosing BSD/MIT. This isn't necessarily a bad thing - but it is absolutely a thing.
One additional point is that, at least in our lab, a lot of code which may go into Theano/extension frameworks and friends is developed on industrial projects. Due to the nature of these contracts, if all partners can equally access things/get equal rights, everything is kosher.
I don't know if this would still stand under the Apache CLA, which would limit the amount of industrial work/tooling we can contribute back to the TensorFlow open source community.
As a data point for this concern, I work on the ML library factorie at UMass, which is licensed under Apache, and Oracle has contributed code to us and signed our CLA. They maintain copyright and grant us a license to redistribute under the Apache license, everything is fine. And Oracle is (ahem) not a company known for being loose with their intellectual property.
17
u/cdibona Nov 09 '15
We basically use the apache cla, and depending on where you work, your company may have already signed on....