fsfe-website/activities/ftf/building-legal-infrastructu...

430 行
14 KiB
HTML

<?xml version="1.0" encoding="UTF-8" ?>
<html>
<head>
<title>FSFE - Freedom Task Force (FTF)</title>
<link rel="stylesheet" media="all" href="/style/grid.css" type="text/css" />
<link rel="stylesheet" media="all" href="ftf.css" type="text/css" />
</head>
<body>
<h1>
FTF: Een juridische structuur opbouwen voor uw Vrije
Softwareprojecten
</h1>
<localmenu/>
<a name="overview"></a>
<h3>Overzicht</h3>
<p>
In deze gids vindt u enkele praktische tips om uw Vrije
Softwareproject enigzins formeel te structureren. Dankzij Vrije
Softwarelicenties kan u het voortbestaan en de coherentie van uw
projecten verzekeren. Maar er zijn nog wel een aantal andere
zaken die de duurzaamheid van uw arbeid bepalen. Op langere
termijn kan u eraan denken om een juridische entiteit op te
richten, u zou er voor kunnen kiezen om de auteursrechten te
consolideren of u zou eventueel ook kunnen beslissen om uw werk
te integreren in een groter project.
</p>
<p>
Deze gids is geen juridisch advies en is zeker niet geschreven als
regelgeving. Het is eerder bedoeld als basis voor een opbouwend
gesprek over het opzetten van formele structuren. Het kan u
helpen om alles eens op een rijtje te zetten. Met de inzichten
die u zo vergaart kan u beter voorbereid gaan praten met
specialisten in deze materie: juristen, adviescentra voor
burgers of bedrijven en overheidsinstellingen.
</p>
<a name="governance"></a>
<h3>Projectbeheer</h3>
<p>
Eens een project succesvol blijkt en groeit, staan de
projectleiders voor de uitdaging om alles te blijven beheren. Op
dat moment moeten de belangrijkste ontwikkelaars beginnen praten
over het beheer en zoeken naar de best mogelijke structuur
daarvoor. Deze discussie leidt meestal naar de keuze
voor een formele juridische structuur die ook het financieel
beheer kan ondersteunen.
</p>
<p>
Er bestaan verschillende formele juridische structuren. Enkele
voorbeelden:
</p>
<ul>
<li>Bedrijf</li>
<li>Non-profit organisatie</li>
<li>Stichting</li>
</ul>
<p>
Een formele juridische structuur opzetten is eenvoudiger dan u
denkt. In veel gevallen hoeft u er slechts een paar uur in te
investeren en enkele formulieren in te vullen. Uiteindelijk is
de juiste keuze afhankelijk van de doelen die u stelt.
</p>
<p>
Wij stellen voor dat u als volgt aan het proces begint:
</p>
<ul>
<li>
Beschrijf de doelen van uw project. Niet uw specifieke
ontwikkelingdoelen, maar eerder het omvattende idee dat aan de
basis van dit project ligt. Bijvoorbeeld: "Thuisgebruikers
over heel de wereld moeten films kunnen bekijken en muziek
beluisteren."</li>
<li>
Maak een lijstje van de zaken waaraan zeker voldaan moet
worden om dit doel te bereiken. Enkele mogelijke voorbeelden:
<ul>
<li>
Een cross-platform client om video en muziek af te
spelen</li>
<li>
Ondersteuning voor internationale talen</li>
<li>
Een internationale website om de code te verdelen</li>
<li>
Zorgen dat de broncode makkelijk te verkrijgen is</li>
<li>
Mensen aantrekken die kunnen helpen bij de
ontwikkeling</li>
<li>
Een formele vertegenwoordiger aanstellen die kan
onderhandelen met derden</li>
<li>
Het project moet de wetten respecteren van de landen
waar het verdeeld wordt</li>
</ul></li>
<li>
Omschrijf de organisatorische regels die u belangrijk
vindt. Enkele voorbeelden:
<ul>
<li>Ons project moet een meritocratie worden</li>
<li>
We moeten de financiële zaken eerlijk kunnen
beheren</li>
<li>Wij willen winst maken</li>
<li>
Individuele ontwikkelaars mogen geen juridisch risico
lopen</li>
<li>
Het project mag niet afhankelijk zijn van één bepaalde
persoon en moet kunnen overleven ongeacht wie het project
verlaat</li>
<li>
In welk land woont u (of de meerderheid van de
ontwikkelaars), is het zinvol om daar ook de juridische
structuur op te bouwen</li>
</ul></li>
</ul>
<p>
Als u de bovenstaande lijst hebt afgewerkt zal u al een vrij
goed idee hebben over de mogelijkheden en de beperkingen van uw
project. Dit zou al moeten volstaan om aan het echte werk te
beginnen. U kan beginnen praten met organisaties zoals de FSFE
of een advocaat over de volgende stappen.
</p>
<p>
Tijdens die volgende stappen kan het interessant zijn om aan een
gekwalificeerd vertegenwoordiger de volgende vragen te stellen:
</p>
<ul>
<li>
Op welke wijze beïnvloedt de bedrijfswetgeving in het door u
gekozen land uw juridisch entiteit? Voorbeelden:
<ul>
<li>
Hoe moeten we de door ons gewenste organisatorische
structuur aanpassen om te voldoen aan de juridische
vereisten?</li>
<li>
Hoe moeten we risico's en verantwoordelijkheden aanpakken
bij het oprichten van onze juridische entiteit?</li>
</ul></li>
<li>
Officialiseer de doelen van je project in een
intentieverklaring, constitutie, bedrijfsplan of
beleidsdocument</li>
<li>
Financiële verantwoordelijkheid, belastingen (indien van
toepassing)</li>
</ul>
<a name="understanding-copyright"></a>
<h3>Hoe werkt het auteursrecht</h3>
<p>
Projecten hebben soms geen formele juridische entiteit maar de
leden van het project hebben een gezamenlijke (alhoewel
juridisch betwijfelbare) melding van auteursrecht, zoals
bijvoorbeeld:
</p>
<p><i>"Widgets 1.0 © 2008 Widgets Development Team"</i></p>
<p>
Maar wat is precies het 'team'? Als "Widgets Development Team"
geen rechtspersoon is (bijvoorbeeld een natuurlijke persoon of
bedrijf) kan die algemeen gesproken geen auteursrecht hebben.
</p>
<p>
Het heeft dus meer zin als het auteursrecht toebehoort aan een
persoon of een formele juridische entiteit. Zoals:
</p>
<ul>
<li>
Widgets 1.0 ©2008 Richard M. Sprocketmacher, Robert
Clockwork</li>
<li>
Widgets 1.0 ©2008 Widgets and Sprockets e.V.</li>
</ul>
<p>
Als u de auteursrechten goed beheert, zal u merken dat sommige
zaken veel eenvoudiger worden:
</p>
<ul>
<li>
U kan het hele project vertegenwoordigen als u praat met
derden</li>
<li>
Men kan de rechten voor het volledige project afdwingen als de
licentievoorwaarden niet worden nageleeft</li>
<li>
U kan makkelijk overschakelen naar een nieuwere versie van de
licentie die u gebruikt</li>
</ul>
<p>
Het is ook heel belangrijk om je code goed te beheren. Als je
niet weet welke licentie bij welke code hoort, kan je in grote
problemen komen. Even de tijd nemen om de volgende raadgevingen
te implementeren zal op termijn zeker renderen.
</p>
<ul>
<li>
Zorg dat men in elk bronbestand een juiste en volledige
kennisgeving van het auteursrecht en de licentie opneemt.</li>
<li>
Volg de aanbevolen praktijken beschreven door de Vrije
Softwaregemeenschap voor het labelen van de software: licht de
gebruikers van de software in over de licentie die van toepassing
is, maak deze informatie bekend op traditioneel te verwachten
en nuttige plaatsen zoals het 'COPYING'-bestand, de
documentatie en de website.</li>
<li> Voeg een kopie van de licentie(s) die van toepassing
is(zijn) toe aan het werk. Zo weet men waaraan men zich moet
houden.</li>
</ul>
<p>
<i>Lees <a href="http://www.fsf.org/licensing/licenses/gpl-howto.html">FSF's
guidelines on the GNU licences</a> voor meer tips en trucs.</i>
</p>
<a name="copyright-consolidation"></a>
<h3>De auteursrechten consolideren</h3>
<p>
Eén van de mogelijke keuzes om uw project te kunnen beheren, is
het oprichten van een formele juridische entiteit waaraan al de
auteursrechten van het project kunnen toegewezen worden. Deze
techniek noemen we het consolideren van de auteursrechten. Wat
concreet betekent dat alle auteursrechten samen beheerd kunnen
worden.
</p>
<p>
Dit wordt meestal bewerkstelligd door middel van een document
dat het auteursrecht toewijst. Sommige mensen noemen dit liever
een document dat de exploitatierechten toewijst. Dit soort
documenten wordt gebruikt door projecten zoals GNU en KDE e.V.
</p>
<p>
U kan een voorbeeld van zo'n document vinden op FSFE's
website. Wij publiceren daar
de <a href="/activities/ftf/fla.html">Fiduciary Licence
Agreement</a> een document waarmee men het auteursrecht of de
exclusieve exploitatierechten kan overdagen. Het is zo geschreven
dat het zowel werkt in het systeem van het gewoonterecht (common
law) als in het civiele rechtsysteem.
</p>
<p>
Auteursrechten toewijzen is een ernstige zaak (men draagt
tenslotte juridische rechten over). Neem contact op met
juridische adviseurs voor je aan dat proces begint. De
praktische uitvoering kan verschillen tussen verschillende
rechtssystemen. Uit voorzorg kan men best een ervaren jurist
onder de arm nemen zodat men zeker is dat alle toewijzingen en
licenties juridisch geldig zijn.
</p>
<a name="trademarks"></a>
<h3>Handelsmerken</h3>
<p>
Het oprichten van een formele entiteit voor Vrije
Softwareprojecten kan helpen bij het controleren en beheren van
de handelsmerken.
</p>
<p>Handelsmerken zijn nuttig:</p>
<ul>
<li>
Ze bezorgen je project een identiteit, wat de administratieve
rompslomp en juridische problemen kan beperken.</li>
<li>
Ze voorkomen dat andere projecten met uw project verward
worden.</li>
</ul>
<p>
Handelsmerken moeten geregistreerd worden. U kan deze zelfs in
verschillende rechtsgebieden registreren als uw project
internationale ambities heeft.
</p>
<p>
Een formele juridische structuur kan helpen bij het beheren van
handelsmerken:
</p>
<ul>
<li>
Men kan richtlijnen opstellen voor het gebruik van de
handelsmerken, ook voor het gebruik door de gemeenschap</li>
<li>
U kan een vergunning verlenen voor het gebruiken van de
handelsmerken voor merchandising, sponsoring of
advertenties</li>
<li>
U hebt zo een eenduidig juridisch aanvaardbaar contactpunt
voor uw handelsmerken</li>
</ul>
<p>
Handelsmerken zijn juridisch gezien sterke wapens maar je hebt
ook de plicht om de rechten die ze je geven te vrijwaren. En ze
verhinderen onder bepaalde voorwaarden dat anderen de door u
gekozen naam kunnen gebruiken. Door deze redenen nemen
verschillende projecten ook verschillende standpunten in over het
beheer van deze rechten.
</p>
<p>
Controleer de volgende zaken als u handelsmerken wil gebruiken:
</p>
<ul>
<li>
Onderzoek of de handelsmerken die u wil gebruiken uniek
zijn. Het wordt aangeraden om hiervoor beroep te doen op een
advocaat of juridisch consulent.</li>
<li>
Gebruik de juiste aanduidingen (onder andere 'R' of 'TM'
synbolen) waar nodig</li>
<li>Hou alles bij in nauwkeurige verslagen</li>
</ul>
<p>
Het kan nuttig zijn om in een document vast te leggen hoe, waar
en voor welke doelen de handelsmerken gebruikt kunnen worden
door derden. Zo kunnen oeverloze discussies en conflicten in het
project en de gemeenschap in het algemeen vermeden worden. Open
communicatie is waardevol in de Vrije Softwarewereld. Het is dan ook
bijzonder belangrijk om uw gemeenschap uitvoerig te consulteren
voor het bepalen van deze regels.
</p>
<a name="furtherreading"></a>
<h3>Bijkomende informatie</h3>
<p>
<i>De volgenden publicaties over infrastructurele zaken kunnen
nuttig zijn als naslagwerk of voor dieper onderzoek. Deze
documenten kunnen termen bevatten zoals "intellectuele eigendom"
of "Open Source" welke door de FSFE niet gesteund
worden. Waarom? Lees even de
artikelen <a href="http://www.gnu.org/philosophy/not-ipr.html">"Did
You Say “Intellectual Property”? It's a Seductive Mirage"</a>
en <a href="http://www.gnu.org/philosophy/open-source-misses-the-point.html">"Why
“Open Source”misses the point of Free Software"</a>.</i>
</p>
<ul>
<li>
Engelfriet, A (2006) <i>Crash course on copyrights</i>
/ <i>Spoedcursus auteursrecht</i> (Engels,
nederlands) <a href="http://www.iusmentis.com/copyright/crashcourse/">Online
versie</a></li>
<li>
Fontana, R, et al. (2008) <i>A Legal Issues Primer for Open
Source and Free Software Projects</i> (SFLC), hoofdstukken 3, 4,
5 <a href="http://www.softwarefreedom.org/resources/2008/foss-primer.html">Online
versie</a></li>
<li>
Lindberg, Van (2008) <i>Intellectual Property and Open Source:
A practical guide to protecting code</i> (O'Reilly), hoofdstuk
14: "Incorporating as a
non-profit" <a href="http://www.worldcat.org/oclc/213307382">WorldCat
listing</a></li>
<li>
Meeker, Heather J. (2008) <i>The Open Source Alternative:
Understanding Risks and Leveraging Opportunities</i> (Wiley)
hoofdstukken 4, 7, 8,
10 <a href="http://www.worldcat.org/oclc/166873236">WorldCat
listing</a></li>
</ul>
<p>Als u meer informatie wil kan u ons contacteren:</p>
<ul>
<li> FSFE's Freedom Task
Force: <a href="mailto:ftf@fsfeurope.org">ftf@fsfeurope.org</a></li>
</ul>
<h3>Over dit document</h3>
<p>Copyright (c) 2009 Graeme West, Shane Coughlan</p>
<p>
Dit document wordt uitgegeven onder
de <a href="http://creativecommons.org/licenses/by-nd/3.0/deed.nl"
class="external free"
title="http://creativecommons.org/licenses/by-nd/3.0/"
rel="nofollow">Creative Commons Naamsvermelding-Geen
Afgeleide werken 3.0 Unported</a> licentie.
</p>
</body>
<timestamp>$Date$ $Author$</timestamp>
</html>
<!--
Local Variables: ***
mode: xml ***
End: ***
-->