Except, of course, that by enforcing it you would be deliberately and aggressively limiting access to creators who want to create digital applications which might be terribly successful, and thereby increase the value (both physical and personal) of activity on the steem blockchain.
Not to mention the impossibility of enforcing that requirement. Given the general lack of governance in the context of the blockchain as is, trying to suggest policy which requires governance which has no mechanism of enforcement is like wishing in one hand and spitting in the other. I suppose at least you have some spit.
What we really need are more reasonable applications that provide actual value to someone's personal experience which just happen to use the steem blockchain.
The problem is that for most of the developers around here, the blockchain comes first – and the idea that the digital application should solve some problem will provide some value to user comes much further down the list.
Aside from that, all of which I wholeheartedly agree with, I truly don’t think that it would be compliant with the MIT license.
And if by inheritance then only the connection layer could be required. Not anything which happens outside of the BC.
Personally, I much more prefer the more open nature of the MIT license over the restrictions of GNU-GPL3.0. Plus the MIT license is compatible with more licenses than the copyleft licenses are.
It is a significant challenge to make things compatible with open source licenses as they are written these days, at least if you ever want to make significant money off of it. This is a bit of a carryover from a lot of the social assumptions of the people who actually write these licenses and have written these licenses, who believe that making money is morally tainted in the first place.
My position is that I think that trying to dictate whether digital applications which touch the blockchain are open source or close source is inevitably doomed to fail, upfront, because it's simply unenforceable and flies right in the face of the design of the technology.
Unless we want to demand that all the voting bots on the steem blockchain prove that there open source and provide that source to us, which would then require that we be able to detect them immediately upon touching the blockchain, keep them from being able to interact until they were checked off, and then allowed back on.
We can't even detect bots consistently.
So – since it's impossible to actually make this policy happen, discussing it is at best a waste of time.
Interestingly enough we shouldn’t have these $hitstorms in a teaglass, which will be forgotten come Monday anyway, because this blockchain is ruled by a Code is Law approach.
No code was violated AFAIK.
As for “the spirit of...”, I thought that was something the rather arbitrarily nature of code is Law would fix.
The MIT license is IMHO a very nice license and ruled by less “pitchfork spirit” than say the GPL scene. None of which are against commercialism yet one first wants to make sure that the spirit is on sharing where the other states to first respect the open nature of the license and seems less controlled by rabid dogs culture.
Interestingly enough we shouldn’t have these $hitstorms in a teaglass, which will be forgotten come Monday anyway, because this blockchain is ruled by a Code is Law approach.
This is absolutely true, and that the position to which I adhere as well. But if there is anything that we can count on when anything (anything) happens on the steem blockchain, it's that whiny bitches will climb out of the woodwork. Some of them will be whales. Some of them will be the proxies of whales. And some of them will just be entitled kids who think that they deserve the magic money numbers in their pocket to go up all the time, and they don't care why it happens or how it doesn't happen.
For extra points, work out the Venn diagram of how these groups overlap.
I'm familiar with the licenses in question and if I were going to be releasing some software myself, the MIT license would be very tempting. Unless I intended to sell it, in which case I definitely wouldn't go with the MIT license.
Though it's a bit off the line of discussion, I always find it amusing how often libraries with viral licenses get used but those licenses don't get applied to various pieces of software. That should be someone's summer research project at some point, to go through github, looking at open source projects, looking at what libraries they use, and seeing if they actually follow the share-alike viral license requirements for the software developed using those libraries.
Which is just not going to happen. They have a vested, very direct interest in getting as many digital applications using the steem blockchain as possible. To that end, they have an aggressive pressure not to care whether or not the project is open source or not but rather whether or not people will actually use it – which is entirely orthogonal
And if we're being cynical, often the closed source solutions end up being better developed. The developers end up having I'm much stronger vested interest in doing a good job because no one else can take their work and run.
That doesn't apply to all things, of course. Anything that depends on a level of trust of the user in order to get the product they desire is going to have a certain extra level of cachet if it's open source. Anything that makes claims about how things work is going to have an extra level of assurance if it's open source.
But streaming applications? That's not a big deal.
Steemit Inc. has made a lot less reasonable, less explainable delegation policy decisions than the one that went to DLive. And notably, even if DLive were an open source project, everything that is happened could easily have happened just the same way because that has nothing to do with whether they decide to take their work to another blockchain.
Policy that would make no difference makes no difference, no matter what.
Except, of course, that by enforcing it you would be deliberately and aggressively limiting access to creators who want to create digital applications which might be terribly successful, and thereby increase the value (both physical and personal) of activity on the steem blockchain.
Not to mention the impossibility of enforcing that requirement. Given the general lack of governance in the context of the blockchain as is, trying to suggest policy which requires governance which has no mechanism of enforcement is like wishing in one hand and spitting in the other. I suppose at least you have some spit.
What we really need are more reasonable applications that provide actual value to someone's personal experience which just happen to use the steem blockchain.
The problem is that for most of the developers around here, the blockchain comes first – and the idea that the digital application should solve some problem will provide some value to user comes much further down the list.
Fix that first, and the rest looks after itself.
Aside from that, all of which I wholeheartedly agree with, I truly don’t think that it would be compliant with the MIT license.
And if by inheritance then only the connection layer could be required. Not anything which happens outside of the BC.
Personally, I much more prefer the more open nature of the MIT license over the restrictions of GNU-GPL3.0. Plus the MIT license is compatible with more licenses than the copyleft licenses are.
It is a significant challenge to make things compatible with open source licenses as they are written these days, at least if you ever want to make significant money off of it. This is a bit of a carryover from a lot of the social assumptions of the people who actually write these licenses and have written these licenses, who believe that making money is morally tainted in the first place.
My position is that I think that trying to dictate whether digital applications which touch the blockchain are open source or close source is inevitably doomed to fail, upfront, because it's simply unenforceable and flies right in the face of the design of the technology.
Unless we want to demand that all the voting bots on the steem blockchain prove that there open source and provide that source to us, which would then require that we be able to detect them immediately upon touching the blockchain, keep them from being able to interact until they were checked off, and then allowed back on.
We can't even detect bots consistently.
So – since it's impossible to actually make this policy happen, discussing it is at best a waste of time.
Interestingly enough we shouldn’t have these $hitstorms in a teaglass, which will be forgotten come Monday anyway, because this blockchain is ruled by a Code is Law approach.
No code was violated AFAIK.
As for “the spirit of...”, I thought that was something the rather arbitrarily nature of code is Law would fix.
The MIT license is IMHO a very nice license and ruled by less “pitchfork spirit” than say the GPL scene. None of which are against commercialism yet one first wants to make sure that the spirit is on sharing where the other states to first respect the open nature of the license and seems less controlled by rabid dogs culture.
This is absolutely true, and that the position to which I adhere as well. But if there is anything that we can count on when anything (anything) happens on the steem blockchain, it's that whiny bitches will climb out of the woodwork. Some of them will be whales. Some of them will be the proxies of whales. And some of them will just be entitled kids who think that they deserve the magic money numbers in their pocket to go up all the time, and they don't care why it happens or how it doesn't happen.
For extra points, work out the Venn diagram of how these groups overlap.
I'm familiar with the licenses in question and if I were going to be releasing some software myself, the MIT license would be very tempting. Unless I intended to sell it, in which case I definitely wouldn't go with the MIT license.
Though it's a bit off the line of discussion, I always find it amusing how often libraries with viral licenses get used but those licenses don't get applied to various pieces of software. That should be someone's summer research project at some point, to go through github, looking at open source projects, looking at what libraries they use, and seeing if they actually follow the share-alike viral license requirements for the software developed using those libraries.
But I have a sick sense of humor.
Upvoted for the Venn diagram.
⭕️
At least there's a little bit of wobble so that they don't make a perfect circle.
Some. A little. Mathematically elliptical.
You'll need calipers.
You're correct. The context under discuss here is about improving Stinc's delegation policy.
Which is just not going to happen. They have a vested, very direct interest in getting as many digital applications using the steem blockchain as possible. To that end, they have an aggressive pressure not to care whether or not the project is open source or not but rather whether or not people will actually use it – which is entirely orthogonal
And if we're being cynical, often the closed source solutions end up being better developed. The developers end up having I'm much stronger vested interest in doing a good job because no one else can take their work and run.
That doesn't apply to all things, of course. Anything that depends on a level of trust of the user in order to get the product they desire is going to have a certain extra level of cachet if it's open source. Anything that makes claims about how things work is going to have an extra level of assurance if it's open source.
But streaming applications? That's not a big deal.
Steemit Inc. has made a lot less reasonable, less explainable delegation policy decisions than the one that went to DLive. And notably, even if DLive were an open source project, everything that is happened could easily have happened just the same way because that has nothing to do with whether they decide to take their work to another blockchain.
Policy that would make no difference makes no difference, no matter what.
I think they are significantly annoyed by the DLive exit for the motivation to make a few changes.
Do you have any suggestions for policy changes that might be effective?