Quote from: barwizi on January 19, 2014, 09:22:56 am

I am not discouraged, i am insulted. You simply repackaged the document, you have not done anything more than 10% of the job, yet you set about writing such insulting documents. And to further the insult you then state you wish to pay 20% for all the work you copied and re-packaged? as if that is not enough you then go on to "praise" my work in other bounties. I work with dual purpose and in good faith, that however is always dependent on how i see you guys operating. This is no good , i'll encourage you to re-visit your position.

If anything other bounty hunters will see that you cannot be trusted to work in good faith, and that will spread to the community. Do not abuse the way the rules are structured, it will be fatal to how bounties are done and it would be a huge blow to the trust factor.

There is no need for hard filings.

The Customer has decided and it is final. Now what to do? You even doesn’t have Mediation panel.
The Bounty Manager and Bounty Prospector was one and Bounty Hunter has no competitior so it didnt need to be batter then it was. So what to do about it?

I think this is valiable expiriance. Now we have opportunity to learn from our mistakes.

This is why this is the single most important documents for the whole community. It is like constitution for the state. If you fail in it you will have future long standing consecquences, which could geopardise the whole community.

Personaly I don’t like the document because of its obvious lacks of mechanisms for achving stated goals. It is more like list of wishes. It even lacks procedures for its change/improvement. This is biggest lack since noone could expect get perfect work at once. But I may be wrong.

So it would be fair to give it chance to prove it self. Lets see how it will serve its purpose. I suggest we use this tread, or open another, to follow its future implementation.

there is a single customer who had default trust. but you are correct, if this bounty is going to be an example, let us see how it will affect others, yes lets keep this thread open.

There are now two versions in play. i would like us to consider the effectiveness of each and how it stands with regard top the future. Protoshares is the current basis of DACs but this may not hold for much longer than the next two months.

I think the license should be one copyable to any code base that is brought under the DAC flag and used in the DAC community, not just specific to PTS.

This would mean the consensus would be more like "all chains will give 10% to the original and 10% to a sponsoring fund" (that is if others are successful enough to be able to have funds)

This makes it a general DAC license and means us devs wont have to structure a license for every code base we bring into the fold. If one so wishes, even using an all new code base they could honour PTS and there by ensure that all forks will indirectly honour PTS holders.

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

Quote from: barwizi on January 19, 2014, 05:24:39 pm

Quote

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.

Please tell me why you think freetrade should disperse those coins? Or even destroy them? I understand there is general dislike of pre-mines but please give me detailed explanations why he should give up his coinage. I ask so that i may attempt to understand your position.

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.

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.

If you have questions or need help put in a ticket on helpdesk, you'll be noticed faster.

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.