Affiliated projects

DCNF intend to provide information, services and support for affiliated projects and aid in management of those projects, as best as possible.

Affiliated projects do not need to be owned by DCNF (copyright etc), but the projects must adhere to a list of requirements and general intention to be considered an affiliated project. The project members of an affiliated project does not need to be part of DCNF, and DCNF do not claim ownership over the projects.

Currently affiliated projects

The following are the currently existing affiliated projects:

• ADC Protocol - The ADC protocol repository
• NMDC Protocol - The NMDC protocol repository
• Hublist - The Hublist repository

Proposed affiliated projects

The following are the proposed but not yet existing affiliated projects (i.e. suggestions):

• Browner-addons with a DC backbone - Allow users to connect to hubs and interact with others straight from their browser. This will aid in the paradigm shift from desktop operating systems to "browser operating systems" (e.g. Chrome OS).
• Architecture to aid peer-to-peer distribution of files - Multiple game distributors use BitTorrent to transfer files to its users, and this is a niche that DC can also suitable fit in. A project that focuses on providing basic architecture to alleviate file distributors' server strain can improve the state-of-affairs for involvement in DC.
• Web applications - Slightly different than a browser addon in that the addon runs on the browser. The "web application" instead can run on a server where you simply log in and point to acccess a hub etc. Efforts to do this are already started by AirDC++ and Euskalt++.
• Providing semi-decentralization (and encrypted) architecture - For chat which doesn't rely on single points of failure and for which (Slack, Hipchat, etc) there's evident demand for the idea in general.
• Decentralized hub listing mechanism - May be based on ADC's extension DFAV.
• Bridge software for IRC/Slack etc - Provide plugins for common software aimed at the other systems/protocols.
• Bridge BitTorrent and DC via magnet links - Provide base software that DC and BitTorrent project can share so they don't claim "magnet" URI exclusion in operating systems (e.g. with the magnet.exe project).

Rules

The following are rules, requirements and project intentions that all affiliated projects must adhere to:

• IAAL*: What Peer-to-Peer Developers Need to Know about Copyright Law - This general guide is simple to follow, and should provide context that most software must follow. Even though a developer might not reside in the USA (since EFF deals with US law), some services may be hosted in the US (e.g. SourceForge), and as such rules within that country must be followed. The basic's are; don't add code that helps users break copyright laws, don't add control code for what files users can or cannot download/share etc (no control is easier), don't provide support for users you suspect have infringed on copyright.
• DCNF by-laws - The by-laws of DCNF are simple but clear; projects must be for the betterment of DC and not be detrimental to it.
• Project language - The project's language (code/documentation etc) should primarily be in English, as it is the common language for the organization as well as the fact that most people on DC can use English.
• Project repository - DCNF can provide a project (source code) repository, which will be pulled at agreed-upon intervals into the main DCNF repository. This will serve as the basis for website content. Code and other components should of course adhere to general software development practices¹.
• Projects must be open-source - See Wikipedia for list of suggested licenses. All projects must have an explicit license that they use.
• Projects should have a stated purpose - Some projects may be for end-users and some may be for developers. A project should be very clear in the type of person that will use the software, technology or documentation. E.g., a reference implementation for the NMDC or ADC protocols don't need to provide human-interation, assuming its purpose is to test and verify protocol messages themselves.
• Projects may be excluded - A project may be excluded as an affiliated project if the DCNF concludes that the project breaks DCNF by-laws or doesn't abide by the other requirements. If such an event occurs, DCNF will hand over all software or documentation to the owners. The board of DCNF will may exlcusion descisions.
• Project owners - Projects should have clear owners or managers. A person may own one or more projects, but they should strive to keep all discussion or management separate so that repositories, code, licenses etc don't "poison" each other.

Recommendations

The following are suggestions or recommendations for affiliated projects:

• Projects requiring monetary aid - It is recommended that project owners of projects that cause a monetary strain on organization should be members of the organization. This is to offset (partially at least) any monetary costs.
• Avoid EULA - End-user license agreements (EULA) generally do not apply to software within the EU (illegal in e.g. Sweden) and are generally poor software distribution practices. Additionally, it is difficult for non-lawyers to write a correct EULA. Therefore it is suggested that no projects use EULAs. Licenses such as GNU GPL are distribution licenses and do not need to be "agreed" to be able to be used. If you don't have a real EULA, then software (installations) should not require users to "agree to" (software distribution) licenses.