/* english */
GOVERNANCE & IP: How decisions are made & who owns what? English version hopefully available soon. Meanwhile use a translator to read the german one below. Read the introduction.
/* deutsch */
5 GOVERNANCE & IP
Wie kommen Entscheidungen zustande und wem gehört, was entsteht?
Je komplexer ein Projekt wird und je mehr Stakeholder daran hängen, desto wichtiger wird das Governance Model. Es sollte von Anfang an ersichtlich sein, wie und von wem wichtige Entscheidungen gefällt werden und welche Prozesse dabei eingesetzt werden. Das kann man z.B. über ein Goveranance Document oder die FAQs kommunizieren.
Open Source Projekte können verschiedene Governance Modelle haben. Wichtig und verbreitet bei Software sind „Benevolent Dictators“ („Wohlwollender Diktator“ – Einzelpersonen oder Kernteams fällen Entscheidungen) und „Meritocracies“ (wer viel beiträgt, darf viel entscheiden.) Abstimmungen über wichtige Fragen können in beiden Fällen eingesetzt werden. Zu häufige Abstimmungen aber lähmen das Projekt. Eine Alternative zur Abstimmung ist der „stille Konsens“. Kommt kein Widerspruch zu gemachten Vorschlägen, gilt das als stilles Einverständnis.
|Zitate & Weiterlesen|
|WEITERLESEN: OSS Watch on Governance Models"|
|It is critical that a project clearly communicates its policies and strategies to potential users and developers of the project’s outputs. A clear governance model also allows potential contributors to understand how they should engage with the project, what is expected of them and what protections are provided to ensure that their contributions will always be available to them. In addition, it describes the quality control processes that help to assure potential users of the viability of the project. (OSS Watch)"|
|It is never too soon to define a suitable governance model. Without one, the chances of third parties wishing to contribute are considerably reduced. This is for a number of reasons: (-) potential contributors will not know how to contribute; (-) they will not be sure what will happen to their contribution; (-) the project will not look serious about engaging with third parties; (-) there is no visible assurance that contributions will be managed in such a way that they will remain of value to the original contributor (OSS Watch)"|
|Transparency: it is clear how the process works, from the method by which candidates get nominated to their term of office and power. An open process mitigates problems with the acceptance of the elections. (?)|
|They can see how the project is run and predict how it will react to their contributions before expending any significant effort on that work. (OSS Watch) "|
|There is no open development if I cannot influence and have my say in what we do and what we are trying to build. That is not open development, that is free labour!’ (OSS Watch)"|
|Exact roles and mechanisms for participating will be dictated by the project’s governance model and vary from one project to another. (OSS Watch) "|
|The more complicated these habits and procedures become, the more important it becomes to aid newcomers with instructions on how they can begin to take part and have a say in the decision making process. Young communities might fall back on the body of knowledge built up and captured in mailing list threads but this does not always help newcomers and can leave them confused. What is needed is something written down, a ‘governance model’, to capture this shared understanding in a concise documentary form. Formalising arrangements helps ensure the community has a life of its own – independent of any one individual – that can survive and flourish for as long as there is a genuine sustained need for the project’s outputs. (OSS Watch)"|
|In the long run, communities need to have open development mechanisms in place to ensure that when key contributors, including the founders, move on, their roles are adopted by others. (OSS Watch)"|
|[on Benevolent Dictators] Benevolent dictators need not possess the greatest technical skills, but they will, according to Fogel, have ‘the ability to recognise good design’. Fogel goes on, however, to make the point that their main responsibility is ensuring participants continue to share the belief that they ‘can do more in concert than individually’. Developers will only remain if their leader can make the project a place they want to keep coming back to. This means rewarding hard work by giving credit where it is due and, for those that want it, responsibility for more significant pieces of work. Management of open source projects has been described as active, informal, and low-key. (OSS Watch)"|
|[on Forks] It’s important that an established project continues to serve the needs of its members. If this ceases to be the case, those who feel theit interests aren’t being served by the project may decide to take a copy of the codebase and continue developing under their own governance. This process is known as forking. It’s important to note that forking isn’t necessarily a bad thing, it may simply be that a section of your community have a specific set of needs that they dont feel can be balanced with the needs of the broader community. There may also be a situation where the established governance model no longer serves the best interests of the project, so the community decide to continue development under a new project with a new governance structure. However, forks that result from clashes of personalities or because of simple disagreements should be avoided as they can divide communities and cause confusion for users. To avoid such forks, the project’s leaders should work to ensure that all contibutors feel enfranchised by the decision making process, even when decisions do not go their way. (OSS Watch)"|
IP – GEISTIGES EIGENTUM
Wem gehört eigentlich, was in kollektiver Zusammenarbeit entsteht? Klarheit über entstehendes „geistiges Eigentum“ ist wichtig für die Motivation. Wer darf wie darüber verfügen? Beitragende müssen ihre Urheberrechte wenigstens teilweise übertragen oder freigeben, damit das Projekt als Communityleistung nutzbar bleibt.
Je nach Art und Komplexität des Projektes sind hier wichtige Entscheidungen zu fällen (z.B. bei der Wahl der Lizenz) und allen Beitragenden offen zu kommunizieren z.B. mit einem „Contributor License Agreement“. Lizenzierung ist ein komplexes Feld und die Lizenz und die Regeln des „Contributor License Agreement“ sollten nicht leichtfertig festgelegt werden. Aber einer gewissen Größe und Professionalität des Projektes kann professionelle Beratung hilfreich sein.
|Zitate & Weiterlesen|
|WEITERLESEN: OSS Watch Document on this|
|WEITERLESEN: Über Open Source Hardware und Lizensierung.|
|In order to be safe, one should always make sure that agreements or contracts specify who will own the intellectual property that results from any collaboration, consortium or contract work. (OSS Watch)"|
|All projects that produce software need to keep complete, detailed records of the licensing and ownership of contributions to that software. (OSS Watch)"|
|If you intend to work on a project as part of your day job, it is vital to check your employment contract for intellectual property rights (IPR) clauses to ensure that you are permitted to participate in an open source project. Since software code is copyright protected, only the owner of that code – or someone authorised by the owner – may legally license it for others to use. Many employers recognize the value of staff participating in the development of software that is used within the firm. Some employers have taken the next step and mark this recognition within institutional IPR policies and/or employment contracts. If you are an educator planning to involve students in an open source project, you should also check that their student agreement permits this type of involvement and that the students understand the implications. (OSS Watch)"|
|It is vital that you know who owns the copyrights in your project. To do this, you need to be able to trace every contribution back to its original author. In the case of contributions that directly affect your project outputs, such as programme code or documentation, this is most efficiently managed through a version control system (see above) coupled with a clearly defined Contributor Licence Agreement and a submission process using an issue tracker. (OSS Watch) "|
|Tools: wikis, bug- and version-trackers and email lists to support the development of the community and keep track of intellectual property rights, if relevant. (OSS Watch)"|
|Till it can be complex to ascertain who should make a legal complaint if someone decides to use the program in a way that violates its licence. To avoid this issue, some open source projects ask that contributors explicitly assign the copyright in their contributions to a body that administers the project, thus keeping ownership centralised and making enforcement of the licence easier. An alternative approach is to have contributors license their contributions to the project’s administrative body under a licence agreement that permits the body to relicense the contribution. (OSS Watch) "|
|The issues of licence compatibility and of complex multiple ownership of intellectual property mean that it is desirable, if not essential, for programmers and their managers to keep detailed records. Version control systems provide some of this record-keeping automatically, recording who made changes to the code and what they did. To complement this information, managers should keep records of the contractual and licensing status of contributors in order to establish who owns their work. They should also require and store explicit agreements from copyright owners that their contributions may be licensed and distributed under the licence selected for the project as a whole. Where code is brought in from existing open source software, the details of the relevant licence must be recorded (having first established that this licence is compatible with the project’s overall licensing policy). (OSS Watch)"|