Jump to content

Licensed deliverables: Difference between revisions

no edit summary
No edit summary
No edit summary
Line 1: Line 1:
'''[[License]]d [[deliverables]]''' are registered with [[Sourceforge]] as several projects, e.g. dividing the project into three parts:
'''[[License]]d [[deliverables]]''' are registered with [[Sourceforge]] as several projects, e.g. dividing the project into three parts to deal with [[contested term]]s.


*[[XML/DTD]] and [[XML/Schema]] documented also in [[ASN.1]] for [[Minimum Message Length]] and proof that the [[Consumerium protocol]] is efficient.  ''This must probably be [[GFDL]].''
*[[XML/DTD]] and [[XML/Schema]] documented also in [[ASN.1]] for [[Minimum Message Length]] and proof that the [[Consumerium protocol]] is efficient.  ''This must probably be [[GFDL]], expressing the [[glossary]] as XML tags that are undisputed. If disputed then executables and label data must be involved, and the tag must be abstracted to something not disputed, to keep [[consensus]]:''


*[[Executable]]s which implement this protocol and data model / [[schema]] / [[foundation ontology]];  The goal is to let programmers sharing some list of concerns collaborate to improve the way [[Consumerium]] signals those concerns to the [[consumer]].  Knowing who can be trusted with what code, who is and is not a saboteur working for the [[producer]]s, is a key problem for which we need a [[trust model]] of some kind (this starts with "who will not break builds"). ''This will likely be a [[GPL]] or some other [[viral license]] with terms to make it easy to keep code making similar assumptions together in one module, and prevent [[bad copy problem]] and [[self-interested fork problem]] GPL creates - but which [[open source]] makes worse! So maybe [[consortium license]] is needed, a specific [[Consumerium License]]?''
*[[Executable]]s which implement the undisputed protocol and basic XML data model / [[schema]] / [[foundation ontology]];  Programmers sharing some list of concerns collaborate to improve the way [[Consumerium]] signals those concerns to the [[consumer]].  This may include coding for specific [[hardware device]]s or [[wireless protocol]]s.  Because this code actually generates [[consumer advice]], it is [[values-sensitive]].  Knowing who can be trusted with what code, who is and is not a saboteur working for the [[producer]]s, is a key problem for which we need a [[trust model]] of some kind (this starts with "who will not break builds"). ''License must reflect this.  This will likely be a [[GPL]] or some other [[viral license]] with terms added to make it easy to keep code making similar assumptions coherent and not sabotaged by those with counter values and counter assumptions, e.g. WAR FTP does not let military users exploit it, nor contribute code to it.''  Goals:  1. code that works and has well advertised assumptions 2. keep code assuming one definition of each [[contested term]] together in one module 3. prevent [[bad copy problem]] and [[self-interested fork problem]] GPL creates - but [[open source]] is worse!   A specific [[Consumerium License]] from which a variant [[factionally defined]] [[consortium license]] can be derived, may be the only/ugly solution here.  Of course what creates controversy in code should ideally be delegated off to:


*[[Label data]] which can and must be consistently gathered and is what is subject to [[audit]] most often.  The goal is to let organizations and people with [[expertise]] and historical, [[built trust]] in things like [[audit]], [[anti-brainwashing techniques]], [[fair]] [[economy]] and [[safe]] [[economy]] gather information from and about the [[producer]].  To avoid a [[centrally controlled information economy]] some party-like [[faction]]s must be involved - these control our bureaucracy and code.  Labels data gathering must be up to th factions.  ''These may create their own [[consortium]] with their own [[consortium license]]'', e.g. [[Greens]] will not let weapons companies use theirs, WAR FTP is not available for military use, but is a terrific product. Executables may also need to use the same license as the label data if there is a lot of markup specific to some [[faction]] that only that faction can be trusted to unravel for its own [[consumer]]s.
*[[Label data]] which can and must be consistently gathered by those who think it is relevant to [[moral purchasing]].  This data is what is subject to [[audit]] most often.  Organizations and individuals with [[expertise]] and historical, [[built trust]] in things like [[audit]], [[propaganda]], [[anti-brainwashing techniques]], [[fair]] [[economy]] and [[safe]] [[economy]] gather information from and about the [[producer]].  To avoid a [[centrally controlled information economy]] some party-like [[faction]]s must be involved and competing to influence (not control )our bureaucracy and code.  Labels data gathering must be up to the factions.  ''These may (or must) each create their own [[consortium]] with their own [[factionally-defined]] [[consortium license]]'', e.g. [[Greens]] will not let weapons companies use theirs.
 
Executables may also need to use the same license as the label data if there is a lot of markup specific to some [[faction]] that only that faction can be trusted to unravel for its own [[consumer]]s.  These licenses must be simple enough that label data and executables that use very different variants, can still interoperate, though perhaps with a warning or fee charged (Greens could not prevent the military executable from using their data, but could charge or them using it, while those using Green executables use it for free, and those using Pink executables use it for less).  Since almost all label data becomes a [[contested term]], we have to assume controversy on day one.  In an object-oriented component the label data and executable would be delivered as one - and only the basic tags in the XML schema would be agreed upon by all [[faction]]s.
Anonymous user
We use only those cookies necessary for the functioning of the website.