Source files of,,,,, and Contribute:
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

building-legal-infrastructure.en.xhtml 11KB

  1. <?xml version="1.0" encoding="UTF-8" ?>
  2. <html>
  3. <head>
  4. <title>Building Legal Infrastructure - FSFE Legal</title>
  5. <link rel="stylesheet" media="all" href="/style/grid.css" type="text/css" />
  6. <link rel="stylesheet" media="all" href="ftf.css" type="text/css" />
  7. </head>
  8. <body>
  9. <p id="category"><a href="/activities/ftf/ftf.html">Legal</a></p>
  10. <h1>Building Legal Infrastructure</h1>
  11. <a name="overview"></a><h3>Overview</h3>
  12. <p>This quick guide has some practical tips for building formal structure in your Free Software project. Free Software licensing helps to ensure the survival and coherence of a project, though there are a number of other things which affect the sustainability of what you are doing. When considering the long-term, you might want to create a legal entity, you might want to consolidate copyright or you might want to merge with a larger project.</p>
  13. <p>The guide does not contain legal advice and it is not intended to be prescriptive. However, it will provide a good starting point to talk about building formal structures, and it may help you organise your thoughts. From there you can talk with professionals working in this field, or you might want to speak with specialists like lawyers, citizens' advice centres, business promotion agencies and government bodies.</p>
  14. <a name="governance"></a><h3>Project governance</h3>
  15. <p>When a project is successful and grows, the project leaders may face challenges in administering everything. This is when the core group of developers start talking about governance and the best type of structure to build. This conversation tends to drift towards having formal legal structure to assist with managing finances.</p>
  16. <p>There are many types of formal legal structure. Some examples are: </p>
  17. <ul><li>Company</li>
  18. <li>Non-profit association</li>
  19. <li>Foundation</li>
  20. </ul>
  21. <p>Establishing a formal legal structure is easier than you might assume. In many cases it just takes a couple of forms and a few hours. However, you do need to know what your goals are to understand which type of structure is best suited to you.</p>
  22. <p>To begin this process we suggest the following:</p>
  23. <ul><li> Describe your project goal. These goals are not your development goals, but rather the larger goals that explain why you started the project in the first place. Example: "Allow home users around the world to watch movies and listen to music easily."
  24. </li><li> Make a list of the things you think you need to accomplish this goal. Some examples could include:
  25. <ul><li> Have a cross-platform client to play video and music
  26. </li><li> Have international language support
  27. </li><li> Have an international site to distribute the project code
  28. </li><li> Have a way for people to get the source code
  29. </li><li> Have a way for people to get involved in development
  30. </li><li> Have a formal representative to lead negotiations with third-parties
  31. </li><li> Make sure the project follows the laws of each country it distributes to
  32. </li></ul>
  33. </li><li> Make a list of things that are organisational requirements for you. Some examples could include:
  34. <ul><li> Our project must be a meritocracy
  35. </li><li> We need to be able to deal with finances fairly
  36. </li><li> We don't want to make a profit
  37. </li><li> We don't want individual developers to have a legal risk
  38. </li><li> We want to make sure that no matter who quits the project, the project itself can continue
  39. </li><li> Which country you (or the majority of developers) are based in, and whether you think your legal entity needs to be established there
  40. </li></ul>
  41. </li></ul>
  42. <p>If you do the above, you will already have a pretty good list of your requirements and restraints. This might be enough to get you started, and from this point you might be able to talk with an organisation like FSFE or a lawyer about next steps.</p>
  43. <p>In taking these next steps, you might want to ask a qualified representative about the following questions:</p>
  44. <ul><li> How business law in your chosen jurisdiction affects your legal entity, e.g.
  45. <ul><li> How can we adapt our desired organisational structure to fit with legal requirements?</li>
  46. <li> How should we deal with risk and liability in establishing our legal entity?</li>
  47. </ul>
  48. </li>
  49. <li> Formalising your project goals into a statement of purpose, constitution, business plan or policy document</li>
  50. <li> Financials and tax liability (if any)</li>
  51. </ul>
  52. <a name="understanding-copyright"></a><h3>Understanding copyright</h3>
  53. <p>Sometimes a project has no formal legal entity, but the project members have a combined (though legally dubious) copyright notice like this:</p>
  54. <p><i>"Widgets 1.0 © 2008 Widgets Development Team"</i></p>
  55. <p>But who exactly is this 'team'? If "Widgets Development Team" is not a legal person (i.e. an individual or company) it generally can't hold copyright.</p>
  56. <p>That means it makes more sense to either have individuals hold the copyright or to have a formal legal entity hold the copyright. For example:</p>
  57. <ul><li> Widgets 1.0 ©2008 Richard M. Sprocketmacher, Robert Clockwork</li>
  58. <li> Widgets 1.0 ©2008 Widgets and Sprockets e.V.</li>
  59. </ul>
  60. <p>By keeping track of your copyright you will find it easier to do various things. Examples include:</p>
  61. <ul><li> Being able to represent the whole project when talking with third-parties</li>
  62. <li> Being able to enforce the rights of the whole project if there are violations of the licence</li>
  63. <li> Upgrading your licences if a new version is released</li>
  64. </ul>
  65. <p>Good stewardship of your code is also important, since difficulties can arise if the licence status of a file is unknown. It is worthwhile taking the time to implement the following practices:</p>
  66. <ul><li> Including an accurate, complete copyright statement and licence declaration on every source file</li>
  67. <li> Following the best practices established by the Free Software community on labelling, such as making your users aware of the licence(s) which apply in appropriate and helpful places, e.g. in a 'COPYING' file, in documentation and on your web sites.</li>
  68. <li> Don't forget to ship a copy of the appropriate licence(s) with the work, so that there is no doubt about application.</li>
  69. </ul>
  70. <p><i>See the <a href="">FSF's guidelines on the GNU licences</a> for more tips and tricks.</i>
  71. </p>
  72. <a name="copyright-consolidation"></a><h3>Copyright consolidation</h3>
  73. <p>As part of your project governance you might decide to create a formal legal entity and assign all the project copyright to it. In this case you need to do something called copyright consolidation. That means bringing all the copyright together into one place. </p>
  74. <p>This is usually accomplished with a copyright assignment document. Some people might call this an "exploitation right assignment" document. These type of documents are used by projects like GNU and KDE e.V. </p>
  75. <p>You can see an example of a copyright consolidation on FSFE's website. We publish something called the <a href="/activities/ftf/fla.html">Fiduciary Licence Agreement</a>, and this is designed to transfer copyright or exclusive exploitation rights in both common and civil law countries.</p>
  76. <p>Assigning copyright is a serious business (after all, you are transferring
  77. rights).  Please talk to a legal expert before beginning a process like this.
  78. This is because the process varies across jurisdictions and it is prudent to
  79. employ an experienced legal professional to ensure all assignments and licences are legally valid.</p>
  80. <a name="trademarks"></a><h3>Trademarks</h3>
  81. <p>One of the possible benefits of establishing a formal entity for your Free Software project is that it can assist in the control and management of trademarks.</p>
  82. <p>Trademarks can be useful because:</p>
  83. <ul><li> They help to identify your project, and this may help reduce administrative hassle and legal problems</li>
  84. <li> They prevent other projects being confused with your work</li>
  85. </ul>
  86. <p>Trademarks need to be registered. You might even want to register trademarks in multiple jurisdictions if you have an international project.</p>
  87. <p>A formal legal entity can assist with managing trademarks by:</p>
  88. <ul><li> Establishing guidance on use of the trademarks, including community usage</li>
  89. <li> Licensing trademarks for merchandising, sponsorship, advertising or community relations</li>
  90. <li> Maintaining a single legal contact for your trademarks</li>
  91. </ul>
  92. <p>Trademarks are powerful legal tools, given that they contain an obligation to enforce the rights granted, and because can prevent others from using the name in certain circumstances. Because of this, projects differ on their attitudes to how they should be managed.</p>
  93. <p>When using trademarks you should:</p>
  94. <ul><li> Ensure that your trademarks are unique by conducting searches. It is advisable to pay a lawyer or consultant to do this, however you can also search public databases yourself.</li>
  95. <li> Use appropriate designations (e.g. the 'R' or 'TM' symbols) when appropriate</li>
  96. <li> Keep accurate records</li>
  97. </ul>
  98. <p>It may be appropriate to establish documentation on how, where and for what purposes the trademark may be used by third parties, so that the project and the community at large can avoid conflict over this issue. Open communications are valued in the Free Software world, and it is especially important to consult extensively with your community on how this issue should be handled.</p>
  99. <a name="furtherreading"></a><h3>Further reading</h3>
  100. <p><i>You may find some of the following publications useful for reference purposes and for reading about infrastructure issues in depth. Please note that these documents may use terms such as "Intellectual Property" or "Open Source" which FSFE does not endorse. To learn why visit <a href="">here</a> and <a href="">here</a>.</i>
  101. </p>
  102. <ul><li> Engelfriet, A (2006) <i>Crash course on copyrights</i> / <i>Spoedcursus auteursrecht</i> (English, Dutch) <a href="">Online version</a>
  103. </li><li> Fontana, R, et al. (2008) <i>A Legal Issues Primer for Open Source and Free Software Projects</i> (SFLC), Chapters 3, 4, 5 <a href="">Online version</a>
  104. </li><li> Lindberg, Van (2008) <i>Intellectual Property and Open Source: A practical guide to protecting code</i> (O'Reilly), Chapter 14: "Incorporating as a non-profit" <a href="">WorldCat listing</a>
  105. </li><li> Meeker, Heather J. (2008) <i>The Open Source Alternative: Understanding Risks and Leveraging Opportunities</i> (Wiley) Chapters 4, 7, 8, 10 <a href="">WorldCat listing</a>
  106. </li></ul>
  107. <p>For more information you can contact:</p>
  108. <ul><li> FSFE's Freedom Task Force: <a href=""></a>
  109. </li></ul>
  110. <h3> Copyright note </h3>
  111. <p>Copyright (c) 2009 Graeme West, Shane Coughlan</p>
  112. <p>This work is available under the <a href="" class="external free" title="" rel="nofollow">Creative Commons Attribution-No Derivative Works 3.0 Unported</a> licence.</p>
  113. </body>
  114. <timestamp>$Date$ $Author$</timestamp>
  115. </html>
  116. <!--
  117. Local Variables: ***
  118. mode: xml ***
  119. End: ***
  120. -->