|
|
| (One intermediate revision by one other user not shown) |
| Line 1: |
Line 1: |
| Definitions can be used, as in the Free Software and Free Culture definitions, to highlight network services that meet a standard of freedom. | | {{autonomous|Definitions}} |
| | |
| == Summary of current practices ==
| |
| | |
| [http://www.opendefinition.org/osd OSD]: Open data (private data only open to the user it's about) and public free software.
| |
| | |
| [http://live.gnome.org/FreeOpenServicesDefinition FOSD]: this is more of a brainstorming/reference page than a definition; the draft definition produced from that process has been mailed to the mailing list and if someone nags me I'll put it on the web somewhere :)
| |
| | |
| == Open issues ==
| |
| | |
| * What do you do about Googlejuice?
| |
| * What do you do about identity?
| |
| * Are external dependencies permitted?
| |
| * Ease-of-install requirements?
| |
| * Interoperability requirements?
| |
| * Requirement to share aggregate/anonymized user data?
| |
| | |
| == Definition requirements ==
| |
| | |
| Some brainstorming requirements for what a free network services definition ''should'' be.
| |
| | |
| ; feasible : it should be technically and legally feasible to create a network service that meets the definition. It would be very nice if it were feasible to create useful, beneficial services that meet the definition. It would be a bonus to have a definition that could be met by services implemented by all kinds of entities, including commercial ones.
| |
| ; comprehensible : the language should be in the vernacular, roughly understandable by most people interested in the topic. OSD, FSD, DFSG, etc. are good guidelines for language level. Commonly-understood terms like "software" or "data" don't need to be defined.
| |
| ; parallel : the definition should be similar in spirit, level of detail, and comprehension to Free Software and Free Content definitions.
| |
| ; defensible : there should be a good rationale for each point.
| |
| ; general : it should cover all kinds of network services. In particular, it should not be limited to the Web; to RPC-style services or services with a UI; it should probably not make assumptions about the Internet (versus another network) or particular architectures like client-server or peer-to-peer.
| |
| ; timeless : it would be nice if the definition would be useful for people in 10-20 years.
| |
