Thanks for the response. I think you may want to separate the efforts into 2 distinct licenses that users can choose between instead of one license that tries to cover both at once. This way each one is optimized for its own intention.

Users/devs choose between:
License 1) a permissive license the enforces the social contract (for entities that claim copyright)
License 2) an extra strong copyleft license that does not enforce the social contract (for entities that do not claim copyright)

The first one, above, is pretty boilerplate. Take BSD and add a clause about the social contract (but asking for a 10%/10% PTS/AGS distribution in the genesis block is meaningless due to the point in my previous post). That license covers all 5 of the points you enumerated in the first post. If it was up to me, I would just license the software as License 1 and put all my effort into wording that extra clause to be exactly what I want.

I'm in agreement here.  A two-license approach would be easier to digest.

I just want to make sure this really what you want - this term prevents indefinite generation of coins or inflationary DACs, it might be limiting to some innovations.

Agreed. The only solution I can think of is to set a minimum number of digital assets; maybe 1:1 mapping is the minimum, and developers can increase the supply to their liking.

You'll also need to figure out how to tighten up the definition of a PTS and AGS holder (see my previous post). For example, I can make an Alternative DAC which only honors AGS holders on Jan 1 and PTS holders on Dec 15th because those are the days I first committed that section of my code. How close to release must that be updated again, or is that acceptable?

Agreed.  I'm a little fuzzy on the mechanics of how these "allocations" to PTS and AGS holders are locked into the chain, but I see a potential problem: assuming AGS are transferable, if the allocation is tied to holders on a particular date, holders looking to take advantage of the system will simply acquire AGS on that date, hold, and sell the following day.  This circumvents the idea behind AGS.

"digital assets" are defined as [need your lawyers to word this] and includes, for example, the total currency supply generated by the genesis block. [even this is bad because I can make a coin that has 50% allocation to PTS, 50% to AGS, but after 1 block both of those allocations are reduced to 1%. Do you want a limitation on % total final money supply? If you do that, no one can make a coin that has any inflation in it.]
"PTS holders" are defined as Protoshares addresses and their corresponding account value in the protoshares blockchain [lawyers, if there is a fork - which blockchain is the protoshares blockchain?] at a given point int time [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 [what point in time?]

I'll noodle on these.

If entity A subscribes to IP and is willing to honour the consensus they may use the code for profit. If entity B subscribes to IP but refuses the consensus and attempts to use the code commercially then they are in violation of the license. Entity A cannot use the derivation made by B as it is already in violation. all this must be made explicitly clear.

How do you determine whether someone "subscribes to IP"?

"This definition is limiting in nature, by stating block chain you have limited the apllications useable with DACs. We use but are not limited to the block chain tech, some DACs will use a ledger system similar to ripple and i am working on a Posax implementation (still conceptual). Perhaps you can change it to be less limiting, the technologies we employ are various.

.

Agreed.  Let's make this more broad.

This statement may require re-wording unless we change the consensus, the word used in the concensus is "money supply" and i think keeping the terms of reference makes the linked documents coherent.

"money supply", just like "shares", are phrases that already have a lot of association in the financial/legal worlds.  I wanted to avoid confusion with existing concepts.  I do agree that consistent terminology across the consensus and the license is helpful.

note to bytemaster---- the website calls it the Bitshares Social Concensus, lets get our terms of reference in order.

Up to Daniel - I don't have a strong opinion either way. 

This is only part of the consensus, the consensus has two clauses, one applicable to AGS funded DACs and another for third party DACs. You need to add the other clause.

Third party DAC's wouldn't be using any code from Invictus and therefore wouldn't be bound by the license.  DAC's that do use their development kit are indirectly funded by AGS and should honor the consensus.

andyjbeal@gmail.com