1000 PTS - Write Social Consensus Software License (SCSL) [CLOSED]

[maqifrnswa]

i'm not debating the consensus, that is for bytemaster and company to work out. As for inflationary coins, you may want to read bytemaster's opinions and ideas on that. For now PTS is the code people will fork, but i am working on a version with stake, relative reward and lots more. it will be another version people can use for code and will have a similar license.

I'm not debating anything, I'm just trying to point out what the license actually says and am asking if that is what the intention is. If we put in that 10% of the genesis block must be at least PTS and 10% must be AGS, we are in fact eliminating the social consensus.
Example:
I take the pts code and change it so that the genesis block gives 1 new DAC asset to every PTS holder and the correct proportion to AGS holders. 50/50. My very next block mines 100billion coins which I give to myself. I followed the license, and the license's description of social consensus, but in fact destroyed it. If that is possible, then just license it BSD and don't worry about this extra restriction anyone can get around. Of course, proof of stake blockchains wouldn't do this, but there is nothing preventing someone from implementing a proof of work blockchain that does an end around any genesis-block based social consensus language

Inflationary coins: it doesn't matter what bytemaster or I think, only what is written in the license. If I3 wants to kill off all inflationary coins forever, then put the "final money supply" description in the license. That's fine, but the decision must be made to do that (that's all I'm asking for, is this I3's intentions or not). I don't understand why reading what bytemaster's opinion of those coins has any bearing on this document unless I3 decides it should be in it. My opinion is to not restrict freedom, and even though I think inflationary coins could be a poor economic model, if someone want to do it they should be free to do it. However, social consensus would need to be redefined for that case if I3 wants to do that.

[barwizi]

I like "stake" that you used, but I'm not a lawyer and would like to see their opinion.

Could we get clarification that you want the social consensus to solely be the genesis block or final money supply? Both have problems. Final money supply is probably preferred but will prevent any coin from having inflation. If it is the genesis block, you might as well have no social consensus at all in the license and go with a simple 3 clause BSD since anyone can follow the license and create a chain with a tiny genesis block.

I do not think you understand how this works exactly. Let me put it this way, the consensus states you allocate 10% with a 1:1 mapping, ergo your DAC needs to take into account how many PTS are in existence. SO if there are 100 PTS total in existence, your dac may have a max of 1000 units distributable. That is to say, the 10% is that of ultimate supply based on current existing PTS. You place these in the genesis block allocated to each holding address,  the inclusion is at genesis as it is simpler and easily verifiable.


The chain is based off the current amount of existing PTS with the stipulation of mapping 1:1, as a result it is in violation of license to try scale down the chain.

I understand it. In fact, you just exactly described what I called "final money supply" limits.

My question is: do we want "final money supply limits" or "genesis block limits." If you follow what you wrote (i.e., "final money supply limits"), you cannot have an inflationary coin. If you follow "genesis block limits," you don't have social consensus.

Also, 1:1 mapping isn't necessary as long as you use percentages. We should not add extra limits for no reason.
Here's why 1:1 mapping is an extra unneeded constraint. 100 pts are in existence.
A DAC offers 2:1 mapping. their final money supply is 500, they give 50 to PTS holders. This follows the social consensus but is prohibited by the license.

  i'm not debating the consensus, that is for bytemaster and company to work out. As for inflationary coins, you may want to read bytemaster's opinions and ideas on that. For now PTS is the code people will fork, but i am working on a version with stake, relative reward and lots more. it will be another version people can use for code and will have a similar license.

[maqifrnswa]

I like "stake" that you used, but I'm not a lawyer and would like to see their opinion.

Could we get clarification that you want the social consensus to solely be the genesis block or final money supply? Both have problems. Final money supply is probably preferred but will prevent any coin from having inflation. If it is the genesis block, you might as well have no social consensus at all in the license and go with a simple 3 clause BSD since anyone can follow the license and create a chain with a tiny genesis block.

I do not think you understand how this works exactly. Let me put it this way, the consensus states you allocate 10% with a 1:1 mapping, ergo your DAC needs to take into account how many PTS are in existence. SO if there are 100 PTS total in existence, your dac may have a max of 1000 units distributable. That is to say, the 10% is that of ultimate supply based on current existing PTS. You place these in the genesis block allocated to each holding address,  the inclusion is at genesis as it is simpler and easily verifiable.


The chain is based off the current amount of existing PTS with the stipulation of mapping 1:1, as a result it is in violation of license to try scale down the chain.

I understand it. In fact, you just exactly described what I called "final money supply" limits.

My question is: do we want "final money supply limits" or "genesis block limits." If you follow what you wrote (i.e., "final money supply limits"), you cannot have an inflationary coin. If you follow "genesis block limits," you don't have social consensus.

Also, 1:1 mapping isn't necessary as long as you use percentages. We should not add extra limits for no reason.
Here's why 1:1 mapping is an extra unneeded constraint. 100 pts are in existence.
A DAC offers 2:1 mapping. their final money supply is 500, they give 50 to PTS holders. This follows the social consensus but is prohibited by the license.

[barwizi]

The 4th clause and definition are there, slight modification below.

4. Modifications must preserve the condition that at least 10% of initially allocated total digital assets are assigned proportionally with a 1:1 mapping to PTS holders  and at least 10% of initially allocated digital assets are assigned proportionally to AGS holders.

"digital assets" are defined as exchangeable units derived from the Product and includes, for example, the total currency supply generated by the genesis block.
"PTS holders" are defined as Protoshares addresses and their corresponding account value in the protoshares blockchain at time of genesis initialization
"AGS holders" are defined as the accounts and cumulative corresponding contributions that contributed as transaction inputs to the PTS and BTC donation addresses defined by I3 at a given point in time

this definition reads awkwardly, my attempts to modify have fallen flat. i modified the clause a bit, but not so sure digital assets does quite as well as the one i put in pace. your definition refers to exchangeable units whereas mine refers to them as stake, seems appropriate.

comments?

[barwizi]

Could we get clarification that you want the social consensus to solely be the genesis block or final money supply? Both have problems. Final money supply is probably preferred but will prevent any coin from having inflation. If it is the genesis block, you might as well have no social consensus at all in the license and go with a simple 3 clause BSD since anyone can follow the license and create a chain with a tiny genesis block.

I do not think you understand how this works exactly. Let me put it this way, the consensus states you allocate 10% with a 1:1 mapping, ergo your DAC needs to take into account how many PTS are in existence. SO if there are 100 PTS total in existence, your dac may have a max of 1000 units distributable. That is to say, the 10% is that of ultimate supply based on current existing PTS. You place these in the genesis block allocated to each holding address,  the inclusion is at genesis as it is simpler and easily verifiable.


The chain is based off the current amount of existing PTS with the stipulation of mapping 1:1, as a result it is in violation of license to try scale down the chain.

[maqifrnswa]

Thank you, earthbound, for articulating the point I've been clumsy getting to. My whole point was that the license was getting unwieldy and unenforceable . Using standard licenses should be preferred.

All modified redistributions shall allocate at least 10 % of the total value supply units to PTS holders ie holders of the original at genesis. All AngelShares sponsored redistributions shall allocate a further 10% of the total value supply to AngelShares. The remaining Value supply is allocated at redistributor’s discretion.   

Aside from the spelling errors, lack of definition of AngelShares or PTS in a legally enforceable way?

How about:
https://bitsharestalk.org/index.php?topic=1708.msg29542#msg29542

The 4th clause and definition are there, slight modification below.

4. Modifications must preserve the condition that at least 10% of initially allocated digital assets are assigned proportionally to PTS holders and at least 10% of initially allocated digital assets are assigned proportionally do AGS holders per the definitions below.

"digital assets" are defined as exchangeable units derived from the Product and includes, for example, the total currency supply generated by the genesis block.
"PTS holders" are defined as Protoshares addresses and their corresponding account value in the protoshares blockchain [bytemaster, if there is a fork - which blockchain is the protoshares blockchain?] at a given point in time [bytemaster, what point in time?]
"AGS holders" are defined as the accounts and cumulative corresponding contributions that contributed as transaction inputs to the PTS and BTC donation addresses defined by I3 at a given point in time [bytemaster, what point in time?]

Could we get clarification that you want the social consensus to solely be the genesis block or final money supply? Both have problems. Final money supply is probably preferred but will prevent any coin from having inflation. If it is the genesis block, you might as well have no social consensus at all in the license and go with a simple 3 clause BSD since anyone can follow the license and create a chain with a tiny genesis block.

[barwizi]

https://docs.google.com/document/d/1vJoHfPO3lCV5pSVoHiZ2s3sp6yUUkVDSkul15A4dWPY/edit?usp=sharing

Anyone that wants to chip in can just give me their mail address.

Aside from the spelling errors, lack of definition of AngelShares or PTS in a legally enforceable way?

I've defined them, and value supply.

[bytemaster]

All modified redistributions shall allocate at least 10 % of the total value supply units to PTS holders ie holders of the original at genesis. All AngelShares sponsored redistributions shall allocate a further 10% of the total value supply to AngelShares. The remaining Value supply is allocated at redistributor’s discretion.   

Aside from the spelling errors, lack of definition of AngelShares or PTS in a legally enforceable way?

[barwizi]

I agree with earthbound in respect that we want this license to be enforceable under the law.

BSD + AGS/PTS clause may be sufficient for that.

https://docs.google.com/document/d/1vJoHfPO3lCV5pSVoHiZ2s3sp6yUUkVDSkul15A4dWPY/edit?usp=sharing

PDF with Bitshares document theme https://drive.google.com/file/d/0BxCtiOzdwvPydTRQUF9xWlNMWXM/edit?usp=sharing

[bytemaster]

I agree with earthbound in respect that we want this license to be enforceable under the law.

BSD + AGS/PTS clause may be sufficient for that.

[earthbound]

The actual code is Invictus, by third party we mean to say that they are bot being financed or supported via AGS.

Dan, can we get some clarification on this point?

your licensing and restrictions you chose to not to separate commons and non-commons use of the product ergo you left out the key parts where we restrict those who subscribe to IP and wish to use the product without honouring the SCSL

I understand the philosophical argument here about believing and not believing in IP; however, in reality, this is almost impossible to enforce.  How do you know what I believe and don't believe? Even then, what if my belief changes? At the end of the day, a DAC that doesn't honor the SCSL doesn't get the license to use and modify the code.  At that point, you have a community of PTS and AGS holders that can be very vocal about DACs that steal the code and don't honor the consensus.

It's very possible I misunderstand (it's been known to happen ) so I will write all of the following under the assumption that I do misunderstand. Which, actually, may be the assumption y'all would want to make, also, because if I misunderstand it in the following way, maybe this illuminates a risk that others misunderstand it in this way, also.

So, again, please assume that I misunderstand, and consider: for me, discussion in a legal document of questions about the status quo of law, and whether any given set of beliefs supports that status quo or not--this rings loud alarm bells of anarchism (which, after all, is quite frowned upon, oh, say . . . in courts of law. Yes, I realize how ironic it is for me to say this, in light of the fact that others have cited my writing in this thread as sounding deeply anarchist). For me, it shouts: "Anarchy! Anarchy! We may have qualms with the entire status quo conception of law--so that we might not uphold the law!" Yoink! How scary might a license document be (and how untenable and unenforceable) if it bears any potential shades of lawlessness in it?

To further play out this "what if?" -- if any court of public opinion forms around the license (and against it) which derive from any misunderstandings similar to mine, that may run the risk of making other substantial (and potentially enforceable) questions about the document harder to ask. I fear it would undermine the credibility of the whole document in any setting wherein it may eventually become desirable to wield said document as real, verifiable, and powerful legal weaponry. I suggest we want to lend every possible strength of precedent, credibility and enforceability which it is possible to lend to the document--and I therefore propose omitting any philosophical discussions (from the document) about who believes what about law. I suggest it may be most desirable to couch all the language and assumptions in the most strictly lawful (and perhaps even conservative businessman-type) language that it can afford (obviously, while avoiding undue complexity and also lending it as much immediate clarity and enforceability as possible).

The following may be an aside, but as possibly supporting case precedent: I've read about folks who refused to register for Social Security Numbers under the auspices that their religious beliefs forbid them to do so. I'm sorry to say this is only anecdotal (and I wager some here might more easily find the references than I, or know more of what I speak), but my recollection is that it didn't hold up in the end . . . I think they were compelled to obtain SSNs. (And aren't SSNs an essential mechanism for the IRS to ensure it gets its lawful tax cut in all the settings where the law supports it?)

[earthbound]

I think there is no need for a dispute between earthbound and barwizi when it comes to the intentions of the license.

1) Those the believe in copyright must abide by the SCSL or they cannot use our code.  The SCSL allows them to do ANYTHING but release a DAC that doesn't allocate shares to AGS and PTS holders.  This is a 0 restriction license other than the allocation.

2) Those that do not believe in copyright can do what ever they want including completely ignoring the AGS and PTS allocation.

In any case, it's become very apparent to me that many-a-programmer will willfully ignore the wishes of others, besides (onlookers: see my aside in my last sentence of this post: https://bitsharestalk.org/index.php?topic=2313.msg27945#msg27945 )

As for expecting that such willful ignorance will probably take place (if I read you correctly, and if I also missed before that this is your expectation), well, that may be rather novel, and I like it

[barwizi]

so you're ok with people taking the protoshares code and removing the social consensus as long as they keep it trade secret? That seems like the worst of both worlds. If I was a company, i'd spin-off an LLC that forks code, makes changes and keeps the changes trade secret without giving anything back to the community, and I'd be protected by your license.

the license should be left in and intact. taking the code means you accept the license terms so if you allocate the required % to PTS holders then all is well, you are not obligated to tell us the key changes that made your product unique. But if you are well versed with this community you'll see that the majority of us do not touch products whose source we cannot review.

Because even if they don't follow copyright, the courts of their jurisdiction do. The parenthesis was for our own clarification, that would not actually show up in the license because courts don't care if you don't follow copyright. Therefore, we need something that will do what I3 wants but using language courts would uphold. The strong copyleft was just there to ensure that third parties would be forced to disclose code/cease usage if they turned hostile.

Unless there is a world government, jurisdiction is not something we can control. We simply put terms that we see applicable in most jurisdictions. It's counter productive to start looking at individual jurisdictions. even governments know there is a limit to enforcement, kinda why tax havens exist and little can be done. One thing this license should not become is a hodge-podge of technical law, it becomes too complicated for the average person to understand.

Because you're trying to do two separate things, the licenses and terms you are granting are different. I don't see a reason why there should be only one document if there are clearly two different modes of operation, and you are only operating in one of those two modes at a given time. This allows you to properly write documents that clearly lay out the terms of each of the modes without worrying about simultaneously considering the other mode. It could be one document, but there should be a very clear break between the two "OR" sections. The two-license approach is best used if you let users choose between two well known licenses (what I was trying to find a way to do). But if you're writing your own, then it doesn't matter. Just don't try to do both at the same time - write two clearly distinct sections so there isn't any possible bleedover of rights from one to the other.

I can just say that it is one thing, we are trying to make it difficulty for IP entities to operate this code for profit.

You don't need to know which one they are operating under the same way you don't need to know which option they choose if it is a single document. I was wrong in bringing up that have a single document makes it harder to know which mode you are in. But if you have a single document, how do you know which terms the user accepted?

We know because it will be clear as day if they have honoured the license at the very first block. Public release means you have honoured it anyway.

Pirates read the FBI warning, don't believe it is valid, and end up getting fined or jail time. You are already making more than one license, you already have two license modes that you are trying to smash together as one. It's much less complicated to have to clear distinct modes rather than trying to decipher a single document that covers two cases simultaneously.

The two license solution works best if they are well known licenses, or close derivatives of well known licences (e.g., adding a clause to BSD-3 or modifying GPL). If you do that, it is cleaner to have two separate licenses. But you're right, if you custom write your own license it doesn't matter what you do as long as it is clear that there are two modes of operation and the user has to choose between those two licenses.

In the end, my opinion is non-professional. I think the language of the license should not be written by non-professionals. We can come up with a guidance document, but the actual language should be written by a lawyer. That's why when people ask how they should write their own license, the answer universally is "don't, use an existing one or find a lawyer."

The very structure you were against in the beginning is the one you are stating now. I had put a Commons and non-commons section, make it infinitely easy for a person to pick one.

lol, you cant modify the GPL.

As i said initially, this is a unique situation and requires a unique solution. attempted hack jobs just will not cut it.

[maqifrnswa]

These are my non-professional opinions, take them or leave them. This is just based on lots of open source software licensing experience from a distribution point of view. If it helps, great - if not - that's great too.

"legitimate closed-source development" seems to be at odds with "doesn't claim IP rights." You can't do closed-source development and not claim IP rights.

This is called trade secret. 

I do not believe in copyright personally and thus want to be consistent in my licensing approach.

so you're ok with people taking the protoshares code and removing the social consensus as long as they keep it trade secret? That seems like the worst of both worlds. If I was a company, i'd spin-off an LLC that forks code, makes changes and keeps the changes trade secret without giving anything back to the community, and I'd be protected by your license.

If the entity does not claim copyright what is the point of having a license at all? And if they do claim copyright that is why they should read License 1.

Because even if they don't follow copyright, the courts of their jurisdiction do. The parenthesis was for our own clarification, that would not actually show up in the license because courts don't care if you don't follow copyright. Therefore, we need something that will do what I3 wants but using language courts would uphold. The strong copyleft was just there to ensure that third parties would be forced to disclose code/cease usage if they turned hostile.

So I don't see any reason why we should have more than 1 License for all. If you don't believe in copyright then don't read the license because it's legalese gibberish but if you do believe in that then read and follow the law.

Because you're trying to do two separate things, the licenses and terms you are granting are different. I don't see a reason why there should be only one document if there are clearly two different modes of operation, and you are only operating in one of those two modes at a given time. This allows you to properly write documents that clearly lay out the terms of each of the modes without worrying about simultaneously considering the other mode. It could be one document, but there should be a very clear break between the two "OR" sections. The two-license approach is best used if you let users choose between two well known licenses (what I was trying to find a way to do). But if you're writing your own, then it doesn't matter. Just don't try to do both at the same time - write two clearly distinct sections so there isn't any possible bleedover of rights from one to the other.

Assuming we take a Dual License Approach, how do we know which license each user is operating under?

You don't need to know which one they are operating under the same way you don't need to know which option they choose if it is a single document. I was wrong in bringing up that have a single document makes it harder to know which mode you are in. But if you have a single document, how do you know which terms the user accepted?

that is one of the issues i wanted to bring up. Unless it is absolutely necesarry i believe the current approach is best. A single license that stipulates the rights accorded to the two groups is a cleaner and enforceable solution. I've heard of a product having two licenses but it sounds messy,especially considering the stipulations. Perhaps Single Vendor Commercial Open Source option can offer some ideas. i'll ruminate the idea

I agree. There is no reason why more than one license should exist. Having more than one makes it unnecessary and complicated. No one is going to read a license if they don't believe in copyright. Do "pirates" read the FBI warning?

Pirates read the FBI warning, don't believe it is valid, and end up getting fined or jail time. You are already making more than one license, you already have two license modes that you are trying to smash together as one. It's much less complicated to have to clear distinct modes rather than trying to decipher a single document that covers two cases simultaneously.

The two license solution works best if they are well known licenses, or close derivatives of well known licences (e.g., adding a clause to BSD-3 or modifying GPL). If you do that, it is cleaner to have two separate licenses. But you're right, if you custom write your own license it doesn't matter what you do as long as it is clear that there are two modes of operation and the user has to choose between those two licenses.

In the end, my opinion is non-professional. I think the language of the license should not be written by non-professionals. We can come up with a guidance document, but the actual language should be written by a lawyer. That's why when people ask how they should write their own license, the answer universally is "don't, use an existing one or find a lawyer."

[luckybit]

License 2) an extra strong copyleft license that does not enforce the social contract (for entities that do not claim copyright)

If the entity does not claim copyright what is the point of having a license at all? And if they do claim copyright that is why they should read License 1.

So I don't see any reason why we should have more than 1 License for all. If you don't believe in copyright then don't read the license because it's legalese gibberish but if you do believe in that then read and follow the law.

Assuming we take a Dual License Approach, how do we know which license each user is operating under?

that is one of the issues i wanted to bring up. Unless it is absolutely necesarry i believe the current approach is best. A single license that stipulates the rights accorded to the two groups is a cleaner and enforceable solution. I've heard of a product having two licenses but it sounds messy,especially considering the stipulations. Perhaps Single Vendor Commercial Open Source option can offer some ideas. i'll ruminate the idea

I agree. There is no reason why more than one license should exist. Having more than one makes it unnecessary and complicated. No one is going to read a license if they don't believe in copyright. Do "pirates" read the FBI warning?