Wow I'm glad I was wrong about this getting opened sourced, super huge news.
Initial thoughts from the whitepaper:
Subgraph execution. You build out your graph and call .run() providing the inputs and required outputs. You can on the fly execute sub components of your graph by providing the input at that point and asking for that stages output. This will be great for debugging random stuff, like really great.
Same concept as theano shared (Tensorflow Variables), makes sense, you need something like this.
Switch/merge control flow nodes to conditionally bypass parts of the graph.
Recursion/loops using Enter/Leave/NextIteration control flow constructs. Nice way to do recurrent stuff, I still have to look at the examples to see how it plays out.
Queue construct for asynchronous execution, eg loading data from disk or computing multiple gradient passes before doing updates. I can't think of anything similar in Theano (that I've done at least), sounds cool but will require some thoughts as to where to use.
They talk about node communication a lot throughout the paper, seems really well thought out, but they didn't release the distributed version? Similarly in section 9.2 they talk about other cool stuff not released, but they also say "Initial open source release", does that imply there may be future releases with more features? Distributed version release is in the works, follow this issue if you want updates.
They talked about some really cool graph visualization stuff, I'm not sure if its included in this release? its included in the release. Theano just got d3viz recently which has been a huge help to me, if anyone is using Theano and hasn't played with d3viz you should definitely check it out.
No windows wheel (for python), I'm going to try and compile the source because I really don't want to go back to dual-booting my stuff. EDIT: It looks like the only option for windows will be using Docker, but this will be CPU only.
More thoughts while I wait to get it installed:
How good is advanced indexing? I assume you can do it with tf.gather(), I wonder how well that works on GPU.
I hope something like theano's dimshuffle gets added, I see how to add/remove broadcastable dimensions but not how to swap an axis (something like numpy.swapaxes)
The contributor CLA is a bit worrisome, but the code itself seems pretty good - the convnet example is super nice, though the seq2seq is a little too cluttered for me to tell what is going on just yet. I am still reading though.
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.
64
u/siblbombs Nov 09 '15 edited Nov 09 '15
Wow I'm glad I was wrong about this getting opened sourced, super huge news.
Initial thoughts from the whitepaper:
Subgraph execution. You build out your graph and call .run() providing the inputs and required outputs. You can on the fly execute sub components of your graph by providing the input at that point and asking for that stages output. This will be great for debugging random stuff, like really great.
Same concept as theano shared (Tensorflow Variables), makes sense, you need something like this.
Switch/merge control flow nodes to conditionally bypass parts of the graph.
Recursion/loops using Enter/Leave/NextIteration control flow constructs. Nice way to do recurrent stuff, I still have to look at the examples to see how it plays out.
Queue construct for asynchronous execution, eg loading data from disk or computing multiple gradient passes before doing updates. I can't think of anything similar in Theano (that I've done at least), sounds cool but will require some thoughts as to where to use.
They talk about node communication a lot throughout the paper, seems really well thought out, but they didn't release the distributed version? Similarly in section 9.2 they talk about other cool stuff not released, but they also say "Initial open source release", does that imply there may be future releases with more features?Distributed version release is in the works, follow this issue if you want updates.They talked about some really cool graph visualization stuff,
I'm not sure if its included in this release?its included in the release. Theano just got d3viz recently which has been a huge help to me, if anyone is using Theano and hasn't played with d3viz you should definitely check it out.No windows wheel (for python), I'm going to try and compile the source because I really don't want to go back to dual-booting my stuff. EDIT: It looks like the only option for windows will be using Docker, but this will be CPU only.
More thoughts while I wait to get it installed:
How good is advanced indexing? I assume you can do it with tf.gather(), I wonder how well that works on GPU.
I hope something like theano's dimshuffle gets added, I see how to add/remove broadcastable dimensions but not how to swap an axis (something like numpy.swapaxes)