Think of it as a starting point, a first rough version of what I think should be present in a code that binds start-ups to their users to balance the scales and to make sure that people that run companies realize that they have rights, but so do their users.
As for 'eating your own dogfood', I fully intend to subscribe all the services I run to the code of ethics, and I have absolutely no problem with that limiting my options.
And if your views on integrity do not coincide with mine that's perfectly ok, but it is really easy to hammer any idea into the ground, let's see your alternative, something that you think would be an improvement over the status quo that you would find acceptable.
Jacquesm: Just to illustrate how you have a tendency to Specify unreasonable upfront restrictions, your own code prohibits you from correcting some of these errors in your code. Even though this is an 0.1 version, it requires all future versions to be equally or more restrictive. So you will have to live with your "first rough version" forever.
That is exactly as stupid as promising to keep the 0.1 version of your api active forever no matter what even if a serious security vulnerability is discovered.
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
Think of it as a starting point, a first rough version of what I think should be present in a code that binds start-ups to their users to balance the scales and to make sure that people that run companies realize that they have rights, but so do their users.
As for 'eating your own dogfood', I fully intend to subscribe all the services I run to the code of ethics, and I have absolutely no problem with that limiting my options.
And if your views on integrity do not coincide with mine that's perfectly ok, but it is really easy to hammer any idea into the ground, let's see your alternative, something that you think would be an improvement over the status quo that you would find acceptable.
Jacquesm: Just to illustrate how you have a tendency to Specify unreasonable upfront restrictions, your own code prohibits you from correcting some of these errors in your code. Even though this is an 0.1 version, it requires all future versions to be equally or more restrictive. So you will have to live with your "first rough version" forever.
That is exactly as stupid as promising to keep the 0.1 version of your api active forever no matter what even if a serious security vulnerability is discovered.
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.