Wat moet elke ontwikkelaar weten over juridische zaken?

Vandaag had ik een onaangename verrassingtoen ik hoorde over enkele implicaties van de GPL-licentie, voornamelijk dat ik het niet zo vrij kon gebruiken als ik dacht.

Nu weet ik het.

Wat moet ik nog meer weten, en meer in het algemeen, wat moet elke ontwikkelaar weten over dergelijke juridische zaken?

Je kunt werknemers, freelancers, bijdragers aan open source-projecten (enz.) scheiden of een breder antwoord geven.

Antwoord 1, autoriteit 100%

Twaalf juridische overwegingen voor softwareontwikkeling

1. Software is auteursrechtelijk beschermd als deze beschikbaar wordt gesteld aan het grote publiek. Het is niet langer nodig om een ​​copyrightvermelding op de applicatie of in de broncode te plaatsen. De eigenaar van het auteursrecht is de auteur(s) of het bedrijf dat de auteur(s) betaalt.

2. Het copyright van software kan worden toegewezen door de eigenaar van het copyright, of het kan worden behouden door de eigenaar en de software kan door de eigenaar in licentie worden gegeven aan de gebruiker of gebruikers.

3. Bibliotheken die in ontwikkeling worden gebruikt, hebben waarschijnlijk beperkingen in hun gebruik en distributie. GPL maakt een bibliotheek niet openbaar, evenmin als het feit dat de bibliotheek wordt geleverd met een ontwikkelplatform. U dient de licentie te lezen en te begrijpen voordat u uw toepassing distribueert. Sommige bibliotheken eisen royalty’s, hoewel dit de laatste jaren minder gebruikelijk is geworden.

4. Procedures voor softwareoctrooien zijn onzin. U mag natuurlijk niet willens en wetens een softwareoctrooi schenden. Er is echter een kleine maar reële kans dat een bedrijf u aanklaagt wegens het schenden van hun patent. Dit kan zelfs gebeuren als u uw software onafhankelijk ontwikkelt, u nog nooit van het octrooi hebt gehoord en het octrooi een techniek dekt die intuïtief voor de hand ligt en bijna helemaal niets met uw software te maken heeft. Er is niet veel dat u kunt doen om dit te voorkomen, gezien het huidige USPTO-beleid, behalve het kopen van een verzekering. Het goede nieuws is dat patenttrollen over het algemeen grote bedrijven aanklagen met veel geld.

5. Als u een werknemer of freelancer gebruikt om software te ontwikkelen, moet u schriftelijk duidelijk maken wie de eigenaar is van het auteursrecht op de toepassing, inclusief de broncode. Sommige freelancers en contractontwikkelingsbedrijven beschouwen de broncode als hun eigendom, waardoor het bedrijf afhankelijk is van de oorspronkelijke ontwikkelaar(s). Dit is legaal als het in de ontwikkelingsovereenkomst staat.

6. Als u een werknemer heeft die ‘off-the-clock’ software ontwikkelt, moet u duidelijk maken wie de eigenaar is van die software en wat voor soort software de werknemer moet kunnen schrijven en distribueren buiten het bedrijf.

7. Als u een werknemer of freelancer bent die software ontwikkelt, moet u, voordat u met de ontwikkeling begint, duidelijk maken wie het auteursrecht op uw toepassing zal hebben. U moet ook weten of verduidelijken wie de eigenaar is van software die u in uw eigen tijd schrijft. Sommige bedrijven hebben clausules in arbeidsovereenkomsten die het eigendom claimen van software die door een ontwikkelaar is geschreven tijdens de periode van tewerkstelling, zowel thuis als op het werk. Veel bedrijven hebben niet-concurrentiebedingen in arbeidsovereenkomsten die de software beperken die een werknemer mag produceren voor distributie buiten het bedrijf. Soms zijn deze beperkingen vrij breed.

8. Een handelsmerk is een naam of symbool, niet de software zelf. Als u software distribueert, moet u (a) ervoor zorgen dat de naam van uw toepassing en het “merk” of het ontwerp van de naam niet “verwarrend vergelijkbaar” zijn met andere toepassingen, en (b) uw handelsmerk registreren. De datum van eerste gebruik is belangrijk bij het oplossen van conflicten, dus u moet documenteren wanneer de applicatie voor het eerst in de handel wordt gebruikt.

9. Als je een applicatie een naam geeft, controleer dan op geregistreerde handelsmerken, maar check ook Google. Een aanvraag waarbij de naam voor het eerst wordt gebruikt, kan mogelijk uw naam en handelsmerk overnemen nadat uw aanvraag is geslaagd, zelfs als zij het handelsmerk niet hebben geregistreerd en u dat wel heeft gedaan.

10. Als u een contract of overeenkomst gebruikt of ondertekent, zorg er dan voor dat beide partijen dit begrijpen. In een arbeidsovereenkomst kan het vooraf vermelden van potentieel gevoelige punten veel problemen later voorkomen. Als in een ontwikkelingsovereenkomst beide partijen weten wie eigenaar is van de broncode, of wie verantwoordelijk is voor upgrades, of wie verantwoordelijk is voor onderhoud, enz., is er veel minder kans op een rechtszaak na de toepassing Het is gedaan. Zorg er in een distributieovereenkomst voor dat de distributeur de verantwoordelijkheden en de duur van de overeenkomst begrijpt.

11. Elke niet-triviale toepassing heeft bugs (of “ontwerpoverwegingen” :-)). Elke gebruikersovereenkomst of distributieovereenkomst moet duidelijk maken dat u niet verantwoordelijk bent voor software die vrij is van bugs, en er kan niet van u worden verwacht dat u alle bugs oplost. Maak duidelijk dat wijzigingen, reparaties en upgrades worden gemaakt naar goeddunken (of naar beste vermogen) van de ontwikkelaar, en maak duidelijk wie voor reparaties en upgrades betaalt.

12. Zelfs nadat je een advocaat hebt geraadpleegd over softwareontwikkelings- en distributieovereenkomsten, moet je de overeenkomsten van andere softwarebedrijven lezen en zien wat hun advocaten hebben bedacht.

13. Ik ben geen advocaat en dit is geen juridisch advies.

Antwoord 2, autoriteit 21%

Neem bij twijfel contact op met een advocaat.

Antwoord 3, autoriteit 19%

Ik ben geen advocaat, maar in de loop van de tijd heb ik een paar vuistregels verzameld van juridische mensen die u kunt gebruiken om tijd te besparen:

• GPL-licentie is ‘copy-left’ of ‘viral’. Het betekent dat elke code die u schrijft en die afhankelijk is van een GPL-component, ook onder GPL moet worden vrijgegeven. Een goede vuistregel is dat als je een GPL-component nodig hebt om je software te compileren, je software moet worden vrijgegeven onder een GPL-licentie.
• U bent niet verplicht uw bron beschikbaar te stellen als u uw software niet distribueert. Als u de software bijvoorbeeld voor interne doeleinden of op een webserver uitvoert, hoeft u de broncode niet vrij te geven. Daarom hoeft Google hun software die GPL-bibliotheken gebruikt niet vrij te geven. Het was een belangrijk twistpunt in GPL v3.
• LGPL (Library of Lesser GPL) vereist alleen dat je je eigen broncode GPL gebruikt als je de LGPL-ed bibliotheek op zo’n manier opneemt dat deze onvervangbaar wordt. Je eigen software hoeft geen GPL te zijn als je alleen de bibliotheek ‘gebruikt’. Het opnemen van header-bestanden en het linken tegen een .dll/.sovan de bibliotheek is een van de manieren waarop u zonder enige verplichting LGPL-ed code kunt ‘gebruiken’, met uitzondering van de juiste copyrightkennisgeving.
• BSD-licentie (de Apache-licentie lijkt erg op) stelt u in staat commerciële extensies te maken van die gebruik maken van de open source-component. Dat is de reden waarom Apple FreeBSD verkoos boven Linux als de kernel voor OSX.
• MPL is zeer commercieel vriendelijk omdat Netscape dacht dat ze wat geld zouden kunnen verdienen aan Mozilla op het moment dat de licentie werd geschreven.

Het helpt vaak om contact op te nemen met de beheerder van het Open Source-project. Zij zijn in de beste positie om u te adviseren over de oorspronkelijke bedoeling van de licentie en over hun eigen visie op open source. Soms zijn beheerders bereid om software onder meerdere licenties vrij te geven om u te helpen. Vaak zijn ze dat niet. Hangt af van de persoon die het auteursrecht bezit.

Het KDE-project heeft een handige matrix

Antwoord 4, autoriteit 6%

Ik denk dat de Juridische gids voor web & Softwareontwikkelingdoor Stephen Fishman Attorney is wat u zoekt.

Recensie

Een geweldig boek! Antwoorden bijna
elke juridische vraag die je maar kunt bedenken
en sommige had je nooit gedacht
van. — John Dvorak, PC Magazine

Omvat elk denkbaar detail
belangrijk voor zo’n snelgroeiende
en immaterieel medium. — Ondernemer

Dit boek slaagt voor mijn eigen persoonlijke test
voor juridische gidsen –met hogere cijfers
dan enige andere juridische gids. — Jeff
Duntemann, redacteur, pc-technieken
Tijdschrift

Productbeschrijving

Bescherm uw rechten en uw harde werk!

De wetten met betrekking tot website en software
ontwikkeling zijn complex en verwarrend,
maar als je ze niet ontwart, is het
kan je duizenden dollars kosten in
advocatenhonoraria en rechtszaken.

Gelukkig, juridische gids voor web &
Softwareontwikkeling decodeert dit
complexe rechtsgebied, grondig
en in lezersvriendelijk Engels. Het
biedt ook contracten, overeenkomsten
en rechtsvormen op cd-rom, met
stapsgewijze instructies voor het vullen
ze eruit, zodat u uw . kunt beschermen
software en website zonder te betalen a
losgeld advocaat.

Gebruik de juridische gids voor web & Software
Ontwikkeling om te leren:

• wat voor rechtsbescherming u nodig heeft
• de sterke punten en beperkingen van elk type bescherming
• hoe inbreuk te voorkomen
• welke voorzieningen u nodig heeft bij het opstellen van een overeenkomst
• hoe u toestemming kunt krijgen om andermans materiaal te gebruiken

Hier vindt u volledige, stap-voor-stap
instructies om op te stellen:

• arbeidsovereenkomsten
• contracten voor aannemers en consultants
• ontwikkelingsovereenkomsten
• licentieovereenkomsten

De 5e editie van Legal Guide to Web
& Softwareontwikkeling is volledig
bijgewerkt om de laatste jurisprudentie te bieden
en wettelijke herzieningen.

Enkele andere suggesties:

• Voor jezelf werken: Law & Belastingen voor onafhankelijke contractanten, freelancers & Adviseurs(dezelfde auteur).
• Consultant & Overeenkomsten voor onafhankelijke contractanten(dezelfde auteur).
• Handboek voor softwarelicentiesdoor Jeffrey I. Gordon.
• Praktische gids voor softwarelicenties voor licentiehouders & Licentiegeversdoor H. Ward Classen.
• De zakgids voor technische contracten: software- en serviceovereenkomsten voor verkopers, contractmanagers en zakelijke ontwikkelaars , en Advocatendoor David Tollen.

Antwoord 5, autoriteit 3%

Als freelancer of aannemer: zorg voor een goede aansprakelijkheidsverzekering en weet wat er onder valt.

De mijne dekt bijvoorbeeld niet de aansprakelijkheid voor fouten in de code waardoor creditcardnummers zichtbaar kunnen worden. Dus ik raak dat spul niet meer aan!

Antwoord 6, autoriteit 2%

Voor werknemers: we moeten uw klanten een eerste adviesronde kunnen geven — zoals kunnen zij/wij de component die we willen gebruiken in hun toepassing?

Voor freelancers: we moeten sterk advies kunnen geven aan uw klanten; en kiezen welke componenten we kunnen gebruiken voor de applicaties die we voor hen ontwikkelen.

Natuurlijk, uw woord is niet zo goed als de adviezen die een advocaat u kan geven; maar je kunt al helpen voor een eerste ronde; bijvoorbeeld om te zeggen “we kunnen dit absoluut niet gebruiken omdat het zou betekenen…”

Uiteindelijk zal de advocaat veel weten over hoekzaken — maar als u een beetje kunt helpen…

Voor OSS-bijdragers: het kan van belang zijn om enkele verschillen tussen gratis licenties te kennen als het u interesseert wat mensen met uw code kunnen doen (herdistribueren? wijzigen? gebruiken in commerciële toepassing? gebruiken in propriëtaire toepassing? )

Antwoord 7, autoriteit 2%

Eén antwoord heeft beweerd dat de wet niet is zoals code. Ik ben het er niet mee eens.

In het begin betaalde IBM programmeurs volgens de instructie. (Iemand die ik kende zei dat hij met een programmeur werkte die op deze manier rijk werd. Blijkbaar wist de man niet hoe hij het indexregister van de machine moest gebruiken; hij schreef een geheugen-nul-routine die handmatig nul opsloeg in elk geheugenadres.)

Er was ook een tijd (lang geleden) dat advocaten per woord werden betaald. Dit hielp om praktijken zoals het aanspreken van mensen als “de meest gewaardeerde zus-en-zo” en andere breedsprakigheden populair te maken.

Ik las net een antwoord op SO dat zei dat VB.NET 2008 nog steeds regelnummers toestaat. Je kunt nog steeds pure DOS draaien op een moderne pc. En er zit veel waarheid in de grap dat alle COBOL-programma’s door incrementele veranderingen van een gemeenschappelijke voorouder afstammen. Achterwaartse compatibiliteit en “historische redenen” zijn wijdverbreid in ons vakgebied.

Dit is vergelijkbaar met het domein van de wet. Er zijn wetten die kleine (of grote) wijzigingen aanbrengen in andere wetten. Je hebt een soort afhankelijkheidshel. Er zijn enkele belachelijke historische wetten (in Hobart, Tasmanië, is het voor een man illegaal om een ​​vrouwenjurk te dragen na zonsondergang – omdat veroordeelden zich ooit als vrouwen zouden verkleden en mensen zouden beroven) die niemand zou durven afdwingen, net zoals er zijn enkele historische functies in software die niemand meer gebruikt.

Wetten hebben vaak onbedoelde gevolgen (bugs!), worden op creatieve manieren gebruikt (hacks!), bevatten mazen (beveiligingsproblemen!), waarvan sommige opzettelijk zijn (achterdeurtjes!), gewijzigd worden (patches!) of vernietigd ( verwijdering!).

Ja, wetten (in tegenstelling tot code) zijn onderhevig aan interpretatie. Maar ik denk dat dit een beetje lijkt op code-onderhoud. Het helpt om wetten aan te passen aan nieuwe sociale normen.

Om de vraag direct te beantwoorden: elke ontwikkelaar zou moeten weten dat wet een belachelijk enorm softwareproject is dat al honderden jaren in ontwikkeling is. (Eigenlijk heeft elk land zijn eigen project en lossen ze problemen op verschillende manieren op.) In theorie weet je na het lezen van een licentie wat je wel en niet met je code mag doen. Maar als een competente programmeur niet alle fouten in zijn code kan ontdekken door deze alleen maar te lezen, welke kans heeft een niet-advocaatdan om de hoekzaken en grijze gebieden van een juridisch document te analyseren?

Net als bij de broncode van software, kunt u de kern van een juridisch document meestal begrijpen door het te lezen, maar als u iets specifieks moet weten, vraag het dan aan een professional.

Antwoord 8

NOLO (ik werk niet voor hen) publiceert een goede reeks juridische handleidingen voor de leek.

http: //www.nolo.com/products/a-legal-guide-to-web-&software-development-SFT.html

Antwoord 9

Ik zou dit op dezelfde manier beantwoorden als “wat moet elke advocaat weten over programmeren?” Dat wil zeggen, weet dat je het diepgaande veld onmogelijk goed genoeg kunt kennen om meer te doen dan de eenvoudigste dingen. Schakel een expert in.

Antwoord 10

U moet de basisrechten en plichten kennen van de licentie die u gaat gebruiken. Het is niet zo moeilijk, en zelfs als er veel van zijn, moet je zorgvuldig alleen diegene lezen die je gaat gebruiken of aanraken. Lees ze maar, in de meeste gevallen zijn ze vrij duidelijk.

Al het andere dat je nodig zou kunnen hebben, dat hangt ervan af. Patenteren? Handelsmerken? Als je deze dingen nodig hebt, is de kans groot dat je in een bedrijf werkt en een juridische afdeling hebt om dit voor je te doen.

Antwoord 11

Ik zou altijd aannemen dat de ontwikkelaars van een project willen dat alle software die hun werk gebruikt, onder exact dezelfde licentie wordt vrijgegeven. Lees hun FAQ’s en juridische pagina’s voor meer informatie en aarzel niet om contact op te nemen met de ontwikkelaars/beheerders als je nog steeds niet zeker bent.

Als u hulp wilt bij het begrijpen van de details van een licentieovereenkomst, neem dan contact op met een advocaat.

Antwoord 12

1. Werk niet in een land met meer advocaten dan ontwikkelaars.
2. Een extreem groot percentage van alle (Amerikaanse) softwarepatenten is nep, maar je kunt niet betalen of wachten tot ze ongeldig worden verklaard.
3. Als je open source software wilt gebruiken/ontwikkelen, gebruik dan een bestaande licentie en wijzig deze niet. Ga niet in de buurt van de grenzen van wat de licentie zou moeten betekenen.

Antwoord 13

De naam van een goede IE-advocaat.

Antwoord 14

6.Als u een werknemer heeft die ‘off-the-clock’ software ontwikkelt, moet u duidelijk maken wie de eigenaar is van > die software, en wat voor soort software de werknemer moet kunnen schrijven en distribueren
buiten het bedrijf.

het recht op vrijheid van meningsuiting zoals vermeld in de meeste grondwetten (vooral als ontwikkelaars gratis s/w off-the-clock maken) kan ervoor zorgen dat dergelijke voorwaarden jammerlijk mislukken in rechtbanken

Antwoord 15

De wet is niet zoals code. Het is geen goed gegoten reeks stappen en regels die ondubbelzinnig kunnen worden begrepen.