Licensed deliverables

I strogly contest the contents of this page and this should not be considered normative in any manner Juxo 18:47 Jun 11, 2003 (EEST)

---

Licensed deliverables are registered with Sourceforge as several projects, e.g. dividing the project into three parts to deal with contested terms.

• 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 GPL, expressing the glossary and consepts 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:

• Executables 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 devices or wireless protocols. 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 producers, 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 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 factions 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 consumers. 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 factions.