I think that an update of the first rough version before it is adopted for practical reasons is perfectly ok, but once adopted it should not be possible to water it down by adopting later versions. That opens the door to adopting a version without restrictions at all and that would render the whole thing pointless.
Keeping your API active if there are security vulnerabilities is interpreting the thing to the letter, the idea is that you will fix the vulnerability and that you will continue to provide the functionality at the same time. If there is an unreasonable conflict between the two (and I fail to see how that could be possible except for very contrived cases) then there probably will be a way to resolve that conflict to everybody's satisfaction.
When you write things like "bankruptcy trustee will be bound by these terms", it becomes hard to argue that other people are unfairly interpreting it "to the letter".
As for the bankruptcy situation, that's one of those cases where there is absolutely no loss for the start-up, after all, the people that found the start-up have nothing to gain once they go bankrupt, but users have everything to gain because if their data gets sold the buyer will be able to do just about anything he wants with the data if the conditions have not been created ahead of time in such a way that they survive the transition.
So, from the point of view of the start-up owner and the users that's a win-win, it may reduce the value of the assets during a bankruptcy liquidation but that's an acceptable trade-off in my opinion.
The issue with your bankruptcy clause isn't its reasonableness (although I personally don't think it's reasonable); the issue is that it's probably not enforceable. I'm not particularly interested in amateurishly delving into the nature of executory and non-executory contracts between freemium startups and their users, but just know that this is not a simple niche in US law.
I'm a very arrogant guy (really), but not so much that I feel like I can come up with a code of conduct for startups on my own. I've got no alternative to offer you. I don't think we need one and I'd bet the market is going to agree.
Comments
I think that an update of the first rough version before it is adopted for practical reasons is perfectly ok, but once adopted it should not be possible to water it down by adopting later versions. That opens the door to adopting a version without restrictions at all and that would render the whole thing pointless.
Keeping your API active if there are security vulnerabilities is interpreting the thing to the letter, the idea is that you will fix the vulnerability and that you will continue to provide the functionality at the same time. If there is an unreasonable conflict between the two (and I fail to see how that could be possible except for very contrived cases) then there probably will be a way to resolve that conflict to everybody's satisfaction.
I very much like RDL's idea: http://news.ycombinator.com/item?id=2774133 , it solves some of the problems without introducing any new ones.
And it allows for a partial adoption, which is really neat.
When you write things like "bankruptcy trustee will be bound by these terms", it becomes hard to argue that other people are unfairly interpreting it "to the letter".
Still waiting for your alternative.
As for the bankruptcy situation, that's one of those cases where there is absolutely no loss for the start-up, after all, the people that found the start-up have nothing to gain once they go bankrupt, but users have everything to gain because if their data gets sold the buyer will be able to do just about anything he wants with the data if the conditions have not been created ahead of time in such a way that they survive the transition.
So, from the point of view of the start-up owner and the users that's a win-win, it may reduce the value of the assets during a bankruptcy liquidation but that's an acceptable trade-off in my opinion.
The issue with your bankruptcy clause isn't its reasonableness (although I personally don't think it's reasonable); the issue is that it's probably not enforceable. I'm not particularly interested in amateurishly delving into the nature of executory and non-executory contracts between freemium startups and their users, but just know that this is not a simple niche in US law.
I'm a very arrogant guy (really), but not so much that I feel like I can come up with a code of conduct for startups on my own. I've got no alternative to offer you. I don't think we need one and I'd bet the market is going to agree.