Dat valt (m.i.) niet onder de GPL eis.

Maar goed idee, om zakelijk juridisch advies aan anonieme IT nerds te vragen.
Elke cent waard die je ervoor betaald hebt.

Mijn garantie blijft beperkt tot 10 maal het bedrag wat je mij voor dit advies betaald hebt.

Als je GPL software gebruikt ben je gebonden aan de voorwaarden van de GPL, maar die zeggen dat je de broncode moet verspreiden zodra je je objectcode (lees binaries) verspreidt. Bij gebruik strikt binnen een bedrijf hoef je je code niet openbaar te maken.

Mijn vraag zou zijn: welke FOSS licentie. Er zijn er heel veel, van heel open (de BSD licenties) tot heel gesloten (GPL v3).

Daarnaast klopt het dat de meeste van die licenties inderdaad gaan over verspreiding, en daarvan is binnen een bedrijf eigenlijk geen sprake.

Ove het "Mixen van open en gesloten software"
door ICT-jurist Arnoud Engelfriet, september 2006
https://www.iusmentis.com/computerprogrammas/opensourcesoftware/

Lees vooral ook het antwoord op deze vraag:

Juridische vraag: Wat mag je met opensource?
door ICT-jurist Arnoud Engelfriet, 8 april 2009
https://www.security.nl/posting/24818/Juridische+vraag%3A+Wat+mag+je+met+opensource%3F



Laat je niet in de luren leggen doordat de aangehaalde artikelen ouder dan 10 jaar zijn. De strekking er van is ongewijzigd. Mocht je er toch twijfel over houden, neem dan contact met de auteur op. Dat is goedkoper dan proceskosten ophoesten.

Verstandig is om precies te weten waar je mee bezig bent, dus in de zin van de letter van de wet en de jurisprudentie. De officieel geldende documentatie van de GNU General Public License, ook de oudere versies, staan op GNU.org

https://www.gnu.org/licenses/licenses.html#GPL

Ik herhaal: de FOSS wereld is stukken breder dan de GPL. De GPL is niet zaligmakend, en lang niet alle FOSS software is onder die licentie uitgebracht. Zeker binnen een bedrijfsmatige omgeving zul je moeten inventariseren welke licenties van toepassing zijn, en of je die licenties wel binnen je bedrijf wilt. Recentelijk zelf zo'n inventarisatie gedaan, en besloten om bepaalde software uit te sluiten van gebruik wegens te beperkende voorwaarden.

(Ik ben poster 9 oktober 23:53)

Zou je hiervoor niet gewoon een bedrijfsjurist inschakelen, in plaats van het risico te nemen dat juridisch ongeschoolde personen op een of ander internetforum je van compleet verkeerde juridische adviezen gaan voorzien. Ja, zo'n persoon kost geld, maar dat is niet het eerste waar je aan denkt als je in rechtszaken verwikkeld raakt vanwege stellig goedbedoeld maar brak advies van personen zonder kennis van open software jurisprudentie, intellectual property rechten/plichten etc. Penny-wise, pound-foolish wat je hier doet.

En sinds wanneer bezit de gemiddelde jurist internet kennis of kennis van FOSS licenties? Er zijn maar een paar gespecialiseerde juristen.

Zitten er dan wel specialisten op dit forum, iedereen schijnt al een mening te spuien.

Jouw gebruik en de aanpassingen vallen onder GPL 2.0 voor software met die licentie.

Je bent verplicht om copyright meldingen op te nemen in interactieve software (art. 2c). Aangepaste bestanden moeten tonen dat er een aanpassingen hebben plaatsgehad met datum (art 2a). Bij bestanden die je zelf (=nieuw) maakt hoeft dat niet.

Je hoeft niets te redistribueren, want dat mag je normaal ook al niet voor andermans werk, behalve onder de licentiebepalingen (art 2b).

GPL 2.0 is duidelijk niet door een jurist gemaakt.

Sorry, je begon echt zo goed, maar schrijf liever geen aperte onzin op...

De verschillende opeenvolgende GNU General Public License versies zijn ontwikkeld door doorwinterde internationale en Amerikaanse export juristen in dienst van de Free Software Foundation, en ze waren vaak zelf al behept met een zowel diepgaande theoretische als praktische ICT kennis, voordat ze aan dat juridische documentatie project begonnen:


https://en.wikipedia.org/wiki/Eben_Moglen

Ter herinnering: PGP gold destijds als een geheim wapen, verboden voor export. De verschillende licentie soorten, en dat geldt ook voor de BSD en MIT licenties, staan uiteraard sterk onder invloed van de wet- en regelgeving en de geldende jurisprudentie in de Verenigde Staten. De GPL is echter ook veelvuldig in de Europese Unie en elders in rechtbanken succesvol verdedigd. Als ICTer sta je zwak in je schoenen als je denkt dat je daar een loopje mee kunt nemen.

Sorry, schrijf zelf liever geen aperte onzin, het is geschreven door Richard Stallman, een IT-er zonder juridische opleiding. Het kan best dat anderen er zich mee hebben bemoeid, maar dat maakt het nog niet een document geschreven door een jurist.

Ik herken jouw stijl van reageren: je kraakt eerst posters af en komt dan met allerlei links die niets bewijzen.

Het gaat hier over GPL 2.0 uit 1991. Moglen is zich pas na het uitbrengen van GPL 2.0 zich gaan bezighouden met juridische zaken en heeft bijgedragen aan versie 3.0 rond 2005.

Zie de uitstekend onderbouwde post van Anoniem 00:01 hierboven; direct link: https://www.security.nl/posting/627142#posting627202

Dank je, voor je opmerking over mijn toonzetting. Ik zal die wat matigen. Het is zeker niet mijn intentie om mensen tegen de haren in te strijken. De materie is al ingewikkeld genoeg :-) In het vervolg zal ik mijn nieuwe leesbril opzetten.

Ik hoop dat Arnoud zijn licht hier nog een keer over kan laten schijnen. Het blijft complexe materie.

Zoek je een kloon van Arnoud? Hier kun je hem vinden:

Het adviesbureau ICTRecht.NL heeft ruim zestig jurisdisch onderlegde ICT specialisten, juristen en advocaten in huis, en werkt vanuit kantoren in Amsterdam, Groningen en Brussel.


https://ictrecht.nl/over-ictrecht/contact/

Tegenwoordig worden in IT-recht gespecialiseerde juristen bij de vleet opgeleid. De vermaarde rechten studie aan de RUG heeft een 3 jaar voltijds bachelor "Law and IT", plus 1 jaar master studie:

https://www.rug.nl/bachelors/it-recht/

Veel instanties kennen tegenwooridig een functionaris gegevensbescherming, met zo'n achtergrond. De meeste middelgrote advocatenkantoren hebben ook wel een afdeling IT-recht. Zoek, en gij zult vinden.

De rubriek "juridische vraag" op deze website is niet een forum-post als de jouwe met "juridische vraag" in de titel, het is echt een aparte rubriek. Je kan bij alle vragen die Arnoud Engelfriet heeft beantwoord het e-mailadres vinden waar je de vragen voor die rubriek aan kan richten. Als je antwoorden van hem wilt voor dingen die hij niet al beantwoord heeft (er is naar gelinkt door anderen), dan zou ik zeggen: stuur een e-mail naar dat adres met een goed geformuleerde vraag waaruit beter dan uit je forum-topic blijkt over welke situatie je het precies hebt en wat je nodig hebt om daar verder mee te komen.

Ik zou je echter eerst aanraden, ook al ben je geen jurist, om zelf de GPL 2.0 en eventueel andere licenties waarmee je te maken hebt te bestuderen. Voor de GLP zijn uitgebreide FAQs beschikbaar. Deze vraag met antwoord uit de FAQ voor GPL 2.0 lijkt me relevant voor jouw vraag:
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#InternalDistribution

Het eerste deel van het antwoord bevestigt wat anderen al hebben gesteld: je hoeft niet je eigen sourcecode ter beschikking te stellen aan anderen.

Het tweede deel vind ik ook interessant: het suggereert dat als je een externe ontwikkelaar aan de sourcecode laat werken die dat niet thuis mag doen, dan is het namelijk off-site en geldt het wel als verspreiding.

Kijk ook naar de andere vragen, ook als je niet op het eerste gezicht ziet waarom die relevant voor jou zijn. De vraag die ik citeerde is een andere dan jij stelde, en toch geeft hij inzicht. Dat kan bij andere vragen ook zo zijn.

Klik ook op het kopje "philosophy" bovenaan die pagina, daar wordt uitgelegd wat de achterliggende gedachte van vrije software is. De uitleg bevat een link naar een uitleg van de filosofische en praktische verschillen tussen vrije en open source software, geschreven vanuit het perspectief van aanhangers van vrije software.

Zonder dat je die ideeën zelf moet gaan onarmen, je mag het er natuurlijk stevig mee oneens zijn, zijn die nuttig om te begrijpen wat men eigenlijk met de GPL 2.0 (en latere versies) beoogt te bereiken, en dat begrip is een goede basis om te snappen wat je wel en niet met GPL'ed software kan doen en moet laten. En als je dat snapt én respecteert verklein je de kans aanzienlijk dat je er blunders mee begaat.

Het is ook van belang om te weten hoe ermee wordt omgegaan als je toch een licentie schendt. Natuurlijk hangt dat af van wie de precieze auteur van de software is en hoe die ermee omgaat, maar voor de Free Software Foundation (van de GPL) en een flink aantal projecten werkt het zoals hier beschreven (beide sites beschrijven dezelfde principes):
https://www.fsf.org/licensing/enforcement-principles
https://sfconservancy.org/copyleft-compliance/principles.html
De eerste site beschrijft ze voor software die onder het GNU-project valt, de tweede voor een aantal andere aangesloten projecten (er is een pagina op die site die ze opsomt).

Het komt er in het kort op neer dat het doel altijd is om simpelweg te bereiken dat de schending ophoudt, dat discreet af te handelen en pas naar de rechter te stappen als er met een overtreder niet op een schappelijke manier uit te komen is. Let op dat beëindigen van een overtreding behoorlijk ingrijpend kan zijn voor een bedrijf dat software aan derden levert (niet jouw situatie), dan moeten er hals over kop alternatieven gevonden worden en dat kan een hoop ontwikkelwerk met zich meebrengen. Maar ze zijn er niet op uit om je met draconische schadevergoedingen financieel uit te wringen, het is geen verdienmodel.

Voor zover ik weet (van op allerlei IT-nieuwssites en in blogs van betrokkenen lezen hoe dat gaat) zijn deze beschrijvingen behoorlijk representatief van wat je van de FLOSS-wereld kan verwachten. Maar nogmaals, er kunnen altijd uitzonderingen bestaan, want de auteursrechten op software liggen bij de makers ervan en je kan nooit uitsluiten dat iemand het op een heel andere manier aanpakt.

Ik denk dat je, als het bij intern gebruik blijft, niet in de buurt komt van dit soort situaties.

Ik ben geen jurist, dus ik garandeer niet de juistheid van wat ik hierboven geschreven heb.

Dat zou dus inhouden dat degene die extern aan de broncode gaat werken die ook beschikbaar moet krijgen ;-)

Wel een waterdichte non-disclosure-agreement opstellen natuurlijk...

Nogal wiedes.
Let op dat, als mijn interpretatie van dat FAQ-antwoord klopt, een NDA niets verandert aan het feit dat dat volgens die tekst nog steeds een schending van de GPL zou zijn. Of onder Nederlands recht of jurisprudentie thuiswerken door een inhuurkracht toch zou gelden als gebruik binnen de organisatie weet ik als niet-jurist niet te beoordelen. Als die situatie zich voordoet zou ik die aan een jurist willen voorleggen.

Tegelijk geldt denk ik dat de manier waarop, voor zover mij bekend, gewoonlijk met licentieschendingen wordt omgegaan betekent dat een organisatie niet meteen zwaar in de shit zit als die dit doet en er iets mis mee gaat. Vermoedelijk gaat de schade niet verder dan de schade die men hoe dan ook heeft door het uitlekken van je eigen broncode; die staat los van de gebruikte GPL-code. Stoppen met iets verspreiden dat men sowieso niet had willen verspreiden kan gewoon en levert dus geen problemen op, daar moet dus uit te komen zijn.

Waarom zou dat het geval zijn? Immers degene die aan het product werkt krijgt op dat moment de broncode, zoals verlangd door de GPL. Die NDA is om je te beschermen tegen misbruik van dit inzien van de broncode.

"Contractor" wil niet per definitie zeggen "ontwikkelaar van de eigen software waarin GPL source verwerkt zit".

Als je een eigen versie van GCC maakt en je geeft die als binary aan een contractor (die het dan gewoon als compiler gebruikt om aan iets heel anders voor je werken dan die eigen GCC versie) is dat verspreiding volgens de GPL faq.
Nog een wat vergezocht voorbeeld - je maakt een eigen versie van Emacs en stuurt die op naar een ingehuurde tekstschrijver die er gewoon voor je teksten mee moet maken - verspreiding.

Het gaat erom dat GPL-code gebruikt wordt in software voor intern gebruik. De GPL vereist dat als je die software distribueert je die ook onder de GPL beschikbaar maakt. Het spul aan een contractor meegeven die off-site werkt geldt als distributie.

De GPL stelt die eis om ook je eigen code onder de GPL ter beschikking te stellen als je jouw code op GPL-code gebaseerd hebt. Dat doe je als je bijvoorbeeld broncode overneemt in je eigen software maar ook als je een library onder de GPL (niet de LGPL) gebruikt. De vuistregel is dat als de software samen in dezelfde address space uitgevoerd wordt de GPL voor alle code in die address space moet gelden.

Volgens diezelfde FAQ verandert een NDA daar niets aan (zoals ik al schreef is het de moeite waard om hem te lezen als je met de GPL te maken hebt), distributie onder een NDA ziet men bij GNU/FSF nog steeds als distributie. Ik meldde ook al dat ik geen idee heb of dat onder Nederlands overeind blijft, maar het is wel hoe de opstellers van die licentie erover denken.

Daar had "onder Nederlands recht" moeten staan.

Wat wil je beschikbaar stellen, als ik het goed begrijp gebruik je de source code van derden, die dit beschikbaar gesteld heeft. En is er dus helemaal geen sprake van ''onze'' source code.

P.s. Indien je open source gebruikt, extra zaken maakt, welke niet confidential zijn, dan is het hoe dan ook sympathiek te overwegen dat beschikbaar te stellen *ongeacht* of het technisch gezien zou moeten. Gewoon wat terug geven aan de community, van wiens werk jij zelf gebruik maakt.

Security matters begon met: "Bij mijn werkgever maken we software en gebruiken we daarvoor open source code". Dat leest alsof er wel degelijk eigen software wordt gemaakt. Over hoe daarvoor open source wordt gebruikt heeft hij zich helaas niet uitgelaten. Ik heb het steeds gelezen alsof er open source-code in de eigen code wordt verwerkt, maar bij nader inzien kan het ook betekenen dat ze een open source compiler of editor gebruiken, wat geen enkel probleem met de eigen code oplevert.

@security matters: Het valt me op dat je verdomd weinig meepraat over alles wat je losgemaakt hebt. Je hebt mensen aan het meedenken gezet maar gaat nauwelijks het gesprek met ze aan. Waarom ben je zo stil en reageer je niet op wat mensen terecht of onterecht aannemen over de situatie?

Dan zou je de broncode van die aangepaste software aan die contractor ter inzage moeten geven. Met een goede NDA natuurlijk. Een dergelijke ingehuurde partij zal er in de praktijk niets mee doen, willen, of kunnen (met die 'technische' broncode).

Hoezo 'natuurlijk' ?
Als je in de situatie contractor volledig moet voldoen aan de GPL mag je aimgh geen voorwaarden opleggen die de bedoelde werking van de GPL te niet doen.

Het zou de GPL een werkingsloze licentie maken als je gewoon modified GPL software kon ve
rspreiden (cq verkopen) en de klant per NDA z'n GPL recht op ontnemen.

Het is geen klant maar een contractor die dingen voor jou doet. Maar je hebt wel gelijk, idd grijs gebied als het niet om ontwikkelwerk oor contractor aan de broncode gaat.

Het antwoord op de hier gestelde juridische vraag:

"Wanneer software op basis van open source code wordt gemaakt, moet de broncode dan altijd worden gedeeld?"
door Arnoud Engelfriet, 16 oktober 2019

>>> https://www.security.nl/posting/627885/

De Achtergrond is een op zichzelf staand onderdeel van Security.NL met daarin eerder gestelde en door Mr. Engelfriet beantwoorde juridische vragen. Dat onderdeel leent zich beter voor het bediscussiëren van juridische voetangels dan het forum. Vragen aan de auteur is geheel vrij: <juridischevraag@security.nl>, maar een antwoord is niet gegarandeerd.