Je code beschermen

[Dorgaldir]

greetingz,

ik heb een paar vraagjes.
Binnen afzienbare tijd ga ik waarschijnlijk freelance/zelfstandig werken als developer (momenteel voornamelijk php maar dat is niet zo belangrijk)

De bedoeling is dat ik sommige scripts ga vrij geven na een tijdje en dat een deel te koop zal worden aangeboden.

Hoe bescherm ik mezelf het beste hiertegen, welke licentie kan ik het beste gebruiken? Want ik heb wel enkele dingen gelezen maar ik geraak er niet veel wijzer uit.

Stel dat ik een basis script heb dat ik als freeware wil uitgeven en een uitgebreider pakket dat ik wil verkopen, hoe zit dit juridisch, wat kan ik en wat kan ik niet. Want een deel van de gratis code zal ook in de betalende code zitten, dus als ik bepaalde freeware licenties op het basis pakket zet dan schend ik mijn eigen licentie door het uitgebreide pakket te verkopen.

Ik wil gewoon dat de intelectuele eigendom van de code van mij blijft, ongeacht of ik er nu geld voor krijg of niet, zodat ik beschermd ben tegen mensen die mijn code willen gebruiken voor er zelf geld mee te verdienen.

Ik hoop dat mijn vraag duidelijk is...

[RobIII]

Galen schreef op donderdag 07 oktober 2010 @ 15:16:
Hoe bescherm ik mezelf het beste hiertegen, welke licentie kan ik het beste gebruiken? Want ik heb wel enkele dingen gelezen maar ik geraak er niet veel wijzer uit.

Inkoppertje: Wat heb je al gelezen, welke licentietypes heb je al gevonden, wat waren de pro's en con's voor elk van die licentietypes voor jou? En welke leek jou het best geschikt en waarom twijfel je daar (concreet) over?

Daarbij: Je kunt natuurlijk altijd "dual licensen"; je bent zelf eigenaar van je code dus je kunt daar natuurlijk mee doen wat je wil. Als je licentie je niet aan staat voor eigen gebruik geef je jezelf gewoon een andere licentie

Verder is dit wel een goed beginpunt lijkt me (en kijk dan vooral even naar het blok "Free and open source software" onder aan de pagina).

[Voor 33% gewijzigd door RobIII op 07-10-2010 15:26]

[Herko_ter_Horst]

If it ain't open source it ain't worth paying for.

Ik begrijp dat je een Open Source licentie gaat gebruiken?

Je mag je gaan inlezen in de wondere wereld van het (internationaal) auteursrecht en licenties.

Als je hier professioneel mee aan de slag gaat, kan ik ten zeerste aanraden hier ook professionele hulp voor in te schakelen, d.w.z. een in auteursrecht en (software-)licenties gespecialiseerde advocaat. Het is namelijk geen sinecure om dit goed te doen, zeker niet als je in je code ook nog gebruik gaat maken van Open Source componenten/libraries.

[Voor 64% gewijzigd door Herko_ter_Horst op 07-10-2010 15:28]

[HerrBohm]

In principe ben je vrij om in je licentie neer te zetten wat je wilt. Ik denk alleen niet dat het slim is om zelf een licentie te ontwikkelen. Mocht je software populair worden dan ben je vaak dingen vergeten waar juristen wel aan zullen denken.

Welke licenties het beste is kan ik zo niet voor je zeggen. Dat ligt aan wat je precies wil overeenkomen, denk aan bepaalde garanties, algemene voorwaarden, aansprakelijkheid en meer.

Als een deel van je gratis code in de betalende code zit mag je dit zeker wel verkopen. Jij hebt namelijk het auteursrecht op de gratis code en publiceert deze slechts onder een (open source) licentie. Jij kan dus meerdere vormen van licenties aan die code hangen.

[RobIII]

offtopic:
Garfield orgie hier

[Dorgaldir]

Herko_ter_Horst schreef op donderdag 07 oktober 2010 @ 15:24:
[...]

Ik begrijp dat je een Open Source licentie gaat gebruiken?

Voor een deel toch zeker , zelf jaren gebruik gemaakt van alles wat open source is, dan zou het hypocriet zij om het zelf niet te doen. Maar er moet ook een boterham verdiend worden dus ik moet wel zekerheden hebben.

Herko_ter_Horst schreef op donderdag 07 oktober 2010 @ 15:24:
Als je hier professioneel mee aan de slag gaat, kan ik ten zeerste aanraden hier ook professionele hulp voor in te schakelen, d.w.z. een in auteursrecht en (software-)licenties gespecialiseerde advocaat.

Maar die kosten waarschijnlijk een smak geld, mijn opstart kapitaal is veel te weinig om de eerste maanden mensen in te huren ik zal al blij zijn als ik op korte termijn een extra pc kan aanschaffen

HerrBohm schreef op donderdag 07 oktober 2010 @ 15:28:
In principe ben je vrij om in je licentie neer te zetten wat je wilt. Ik denk alleen niet dat het slim is om zelf een licentie te ontwikkelen. Mocht je software populair worden dan ben je vaak dingen vergeten waar juristen wel aan zullen denken.

Welke licenties het beste is kan ik zo niet voor je zeggen. Dat ligt aan wat je precies wil overeenkomen, denk aan bepaalde garanties, algemene voorwaarden, aansprakelijkheid en meer.

Als een deel van je gratis code in de betalende code zit mag je dit zeker wel verkopen. Jij hebt namelijk het auteursrecht op de gratis code en publiceert deze slechts onder een (open source) licentie. Jij kan dus meerdere vormen van licenties aan die code hangen.

Dus als ik het goed begrijp zou ik in theorie een open licentie op mijn code kunnen zetten en die aan jou geven en daarna op dezelfde code (of lichtelijk gewijzigd) een andere licentie op plakken om aan iemand anders te geven.

RobIII schreef op donderdag 07 oktober 2010 @ 15:30:

offtopic:
Garfield orgie hier

jej

[Hydra]

Je hebt hier in nederland hoe dan ook auteursrechten op software die je zelf ontwikkeld hebt (dus niet in de tijd van de baas ofzo). Hou daar rekening mee.

[HerrBohm]

Galen schreef op donderdag 07 oktober 2010 @ 15:34:
Dus als ik het goed begrijp zou ik in theorie een open licentie op mijn code kunnen zetten en die aan jou geven en daarna op dezelfde code (of lichtelijk gewijzigd) een andere licentie op plakken om aan iemand anders te geven.

Klopt, in de praktijk kan dit natuurlijk ook

[Dorgaldir]

Hydra schreef op donderdag 07 oktober 2010 @ 15:35:
Je hebt hier in nederland hoe dan ook auteursrechten op software die je zelf ontwikkeld hebt (dus niet in de tijd van de baas ofzo). Hou daar rekening mee.

ik woon wel in vlaanderen, maar ik denk dat op dat vlak niet zoveel verschil zal zijn.
Maar moet je dan de code niet binnenbrengen bij sabam? (autheursrechtenorganisatie)

[RobIII]

Galen schreef op donderdag 07 oktober 2010 @ 15:37:
Maar moet je dan de code niet binnenbrengen bij sabam? (autheursrechtenorganisatie)

Ik weet niet hoe jullie Belgen het geregeld hebben ( ) maar dat zou mooi worden Dan hebben de auteursrechtenorganisaties de sourcecode van héééééél veel producten liggen Goddank niet nee

[MSalters]

Nee, copyright is hier (NL en BE) automatisch. Je hoeft niet eens een copyright notice in je code op te nemen. Overigens, als je je code ook buiten de EU wil beschermen, dan is zo'n melding wel verplicht.

[Dorgaldir]

RobIII schreef op donderdag 07 oktober 2010 @ 15:41:
[...]

Ik weet niet hoe jullie Belgen het geregeld hebben ( ) maar dat zou mooi worden Dan hebben de auteursrechtenorganisaties de sourcecode van héééééél veel producten liggen Goddank niet nee

dat dacht ik ook, maar hoe kan je dan bewijzen dat jij als eerste op die code een licentie hebt gezet, want als ik jou mijn script doorstuur, met de licentie vermelding erin dan wis jij die gewoon, hangt er zelf een andere boven en het is klaar.

[RobIII]

Galen schreef op donderdag 07 oktober 2010 @ 15:44:
[...]

dat dacht ik ook, maar hoe kan je dan bewijzen dat jij als eerste op die code een licentie hebt gezet, want als ik jou mijn script doorstuur, met de licentie vermelding erin dan wis jij die gewoon, hangt er zelf een andere boven en het is klaar.

Ghehe; een 1972 truukje dat ik eens gehoord heb om de bewijslast te vergemakkelijken is het volgende: Zet je code op een CD/DVD/Stick/whatever en stop die in een verzegelde enveloppe. Verstuur die aangetekend aan jezelf en open de enveloppe niet bij ontvangst maar berg 'm veilig op. De postzegelstempeldinges bevat de datum en het feit dat de enveloppe niet geopend is (zegel is in tact) bewijst dat wat erin zit onaangetast is. Daarmee kun je in ieder geval bewijzen dat jij op (voor) die datum die code in je bezit had. Maar dat is een poor-mans oplossing

[Voor 3% gewijzigd door RobIII op 07-10-2010 15:54]

[AtleX]

Dan ga je toch met wat uitdraaien van je version control system wapperen waarin precies de hele ontwikkeling van het spul, inclusief data & namen, te volgen is?

[Voor 4% gewijzigd door AtleX op 07-10-2010 15:52]

[Dorgaldir]

AtleX schreef op donderdag 07 oktober 2010 @ 15:50:
Dan ga je toch met wat uitdraaien van je version control system wapperen waarin precies de hele ontwikkeling van het spul, inclusief data & namen, te volgen is?

Dat is natuurlijk ook waar

RobIII schreef op donderdag 07 oktober 2010 @ 15:49:
[...]

Ghehe; een 1972 truukje dat ik eens gehoord heb om de bewijslast te vergemakkelijken is het volgende: Zet je code op een CD/DVD/Stick/whatever en stop die in een verzegelde enveloppe. Verstuur die aangetekend aan jezelf en open de enveloppe niet bij ontvangst maar berg 'm veilig op. De postzegelstempeldinges bevat de datum en het feit dat de enveloppe niet geopend is (zegel is in tact) bewijst dat wat erin zit onaangetast is. Daarmee kun je in ieder geval bewijzen dat jij op (voor) die datum die code in je bezit had. Maar dat is een poor-mans oplossing

lol das een goeie

heb me een wikibook gemaakt met wat pagina's die me hier aangereikt zijn en enkele die daaraan gelinkt waren, nu even 70 A4tjes doorlezen omtrent licenties
Dan weet ik weer wat doen vanavond

[HerrBohm]

Een veel veiliger maar ook wat duurdere manier is om de code in escrow onder te brengen, bijvoorbeeld in bewaargeving of in notarieel depot.

[Hydra]

AtleX schreef op donderdag 07 oktober 2010 @ 15:50:
Dan ga je toch met wat uitdraaien van je version control system wapperen waarin precies de hele ontwikkeling van het spul, inclusief data & namen, te volgen is?

Dat is natuurlijk ook simpel te faken.

HerrBohm schreef op donderdag 07 oktober 2010 @ 16:02:
Een veel veiliger maar ook wat duurdere manier is om de code in escrow onder te brengen, bijvoorbeeld in bewaargeving of in notarieel depot.

Dat is voor veel klanten sowieso een must. Als ons bedrijf belly-up gaat en niemand de software overneemt krijgen zij toegang tot de sourcecode.

[Voor 39% gewijzigd door Hydra op 07-10-2010 16:03]

[analog_]

Ook intressant is dat als jij libraries van andere projecten gebruikt je moet zien dat je deze ook voor commercieel gebruik 'gratis' mag gebruiken of wat daar de gevolgen van zijn.

[pedorus]

RobIII schreef op donderdag 07 oktober 2010 @ 15:30:

offtopic:
Garfield orgie hier

offtopic:
Ligt aan dit topic, heb jij daar geenook last van?

RobIII schreef op donderdag 07 oktober 2010 @ 15:49:
[...]

Ghehe; een 1972 truukje dat ik eens gehoord heb om de bewijslast te vergemakkelijken is het volgende: Zet je code op een CD/DVD/Stick/whatever en stop die in een verzegelde enveloppe. Verstuur die aangetekend aan jezelf en open de enveloppe niet bij ontvangst maar berg 'm veilig op. De postzegelstempeldinges bevat de datum en het feit dat de enveloppe niet geopend is (zegel is in tact) bewijst dat wat erin zit onaangetast is. Daarmee kun je in ieder geval bewijzen dat jij op (voor) die datum die code in je bezit had. Maar dat is een poor-mans oplossing

Ik denk dat je een stuk beter af bent als het gewoon in je gmail sent mail folder staat... Het heet niet voor niets Poor man's copyright.

[Dorgaldir]

analog_ schreef op donderdag 07 oktober 2010 @ 16:05:
Ook intressant is dat als jij libraries van andere projecten gebruikt je moet zien dat je deze ook voor commercieel gebruik 'gratis' mag gebruiken of wat daar de gevolgen van zijn.

Daarom maak ik ook zo weinig mogelijk gebruik van libraries, maar toch bedankt voor de herrinering

[AtleX]

Hydra schreef op donderdag 07 oktober 2010 @ 16:02:
[...]


Dat is natuurlijk ook simpel te faken.

Tuurlijk, maar dat mag de tegenpartij dan gaan bewijzen.

[RobIII]

pedorus schreef op donderdag 07 oktober 2010 @ 16:06:
Het heet niet voor niets Poor man's copyright.

Dat zei ik toch ook? Laatste regel uit het stuk dat je quote

[Dorgaldir]

AtleX schreef op donderdag 07 oktober 2010 @ 16:11:
[...]

Tuurlijk, maar dat mag de tegenpartij dan gaan bewijzen.

Maar wie is de tegenpartij? als ik jou code overneem, logs fake en jou dan aanklaag...

* Galen vind dat er wel veel mensen zonder garfield posten

[Voor 12% gewijzigd door Dorgaldir op 07-10-2010 16:17]

[HerrBohm]

Galen schreef op donderdag 07 oktober 2010 @ 16:13:
* Galen vind dat er wel veel mensen zonder garfield posten

offtopic:
Misschien kunnen we een petitie starten voor ons eigen subforum.

[AtleX]

* AtleX dynamische icons...

[Dorgaldir]

HerrBohm schreef op donderdag 07 oktober 2010 @ 16:20:
[...]

offtopic:
Misschien kunnen we een petitie starten voor ons eigen subforum.

offtopic:
Of toch op zijn minst een award ofzo

[H!GHGuY]

Het copyright van alles wat jijzelf schrijft komt automatisch jou toe.
Onder welke voorwaarden je deze code, of een gecompileerd product, aan anderen beschikbaar stelt staat in de licentie.

Er zijn copyleft licenses, waarbij je anderen de rechten geeft om de code te wijzigen, aan te passen en te herdistribueren, maar er zijn ook commerciele licenses die enkel recht geven op het gebruik van de gecompileerde vorm van de code. Je kan code waarop jij copyright hebt aan eender wie onder een verschillende license uitgeven.

Onder de copyleft licenses zijn ook nog eens vele varianten. Strong copyleft en weak copyleft licenses: er is behoorlijk wat verschil tussen MIT, BSD en GPL, AGPL, LGPL of openssl.
Waar MIT en BSD weinig restricties/verplichtingen stellen en andere statisch/dynamisch gelinkte code niet contamineren is dit voor GPL (statische & dynamische contaminatie), LGPL (statische contaminatie) en AGPL (networked users krijgen ook toegang tot sources) wel anders.

Net zoals jij software uitgeeft en wenst dat de voorwaarden gerespecteerd worden, moet je natuurlijk ook in de omgekeerde richting voldoen. Het is snel gebeurd dat je een codefragmentje van codeplex, sourceforge of een willekeurige website copy-paste. Of linkt tegen een library met license waar je eigenlijk liever onderuit zou willen.
Het is trouwens soms bemerkenswaardig hoe licenses incompatibel zijn en voor problemen zorgen, of hoe net bepaalde uitzonderingen je goed uitkomen.

Soms zijn er ook speciale use-cases voor het gebruik van een bepaalde license. Zo heeft het syslog-ng project recentelijk de core van het programma onder een LGPL license gereleased, die typisch eerder op libraries rust.
De reden is dat de developer dynamisch linken wil mogelijk houden zodat hij zijn brood kan verdienen met plugins te verkopen (die hij dan een hele tijd later alsnog onder een copyleft license uitgeeft).

Zoals hierboven al gezegd; en hopelijk maak ik dit in mijn post ook duidelijk: contacteer iemand met verstand van auteursrecht en open-source licenses. Het kan je kopzorgen en centen besparen.

[Gomez12]

Bedenk ook goed wat voor klanten je wil gaan bedienen, hier hangt veelal ook je licentievorm aan vast namelijk.

Met een beer-license oid kom je niet echt snel bij de grotere bedrijven binnen.
Een helemaal op maat gemaakte licentie is ook niet echt aan te raden ( zo goed als niemand leest die dingen, dus overtreding is makkelijker gebeurd als ze het niet kennen )

En bedenk ook goed wat jij wil dat iemand anders met jouw code mag doen. Een GPL licentie is veelal niet erg geliefd bij bedrijven die het willen integreren in hun eigen code.

En vooral, hou het simpel en overzichtelijk.

En blijf in je achterhoofd houden dat een licentie in wezen maar 1x uitgegeven kan worden per product ( oftewel het moet in 1x goed zijn ). Als je later van licentie wilt veranderen en je vroegere code wordt geforked oid dan heb je een heck of a job met uitzoeken/bewijslast.

Oftewel contacteer iemand met verstand van zaken

[Avalaxy]

Over auteursrecht:

Het gaat inderdaad niet zozeer om copyright symbooltjes, maar om het kunnen bewijzen dat de code van jou is. Een aantal manieren:

- Kunnen bewijzen dat je er aan gewerkt hebt (familieleden, collega's, etc. die je eraan hebben zien werken)
- Je werkhistory bewaren (bijvoorbeeld je VCS repository)
- De code aan jezelf sturen via de post zoals RobIII al zei
- Een bewijsakte halen bij een notaris (tegen betaling)
- Een van de andere opties zoals registratie bij de belastingdienst, BBIE, etc.

Zie ook deze link voor meer info:
http://www.iusmentis.com/auteursrecht/registratie/

[Gomez12]

Avalaxy schreef op donderdag 07 oktober 2010 @ 22:11:
Over auteursrecht:

Het gaat inderdaad niet zozeer om copyright symbooltjes, maar om het kunnen bewijzen dat de code van jou is. Een aantal manieren:

- Kunnen bewijzen dat je er aan gewerkt hebt (familieleden, collega's, etc. die je eraan hebben zien werken)
- Je werkhistory bewaren (bijvoorbeeld je VCS repository)
- De code aan jezelf sturen via de post zoals RobIII al zei
- Een bewijsakte halen bij een notaris (tegen betaling)
- Een van de andere opties zoals registratie bij de belastingdienst, BBIE, etc.

Zie ook deze link voor meer info:
http://www.iusmentis.com/auteursrecht/registratie/

Dat is de theorie. In de praktijk wil je eigenlijk helemaal nooit naar dit soort bewijzen terug moeten grijpen.
Als je dit soort bewijzen nodig hebt, dan zit je al in een down & dirty rechtbank gevecht en zal je "bewijs" voornamelijk afhangen van je overredingskunsten.

Meestal wordt er namelijk niet je complete code blind gecopy-paste, maar wordt er aan gesleuteld / gefinetuned door de overtreder waardoor de code niet meer 100% gelijk is aan jouw code.
Jouw "bewijs" is ook maar een snapshot ( of een serie snapshots ) en dus is de copy die bij de notaris ligt ook achterhaald.

De kans dat een niet kwaad bedoelende overtreder 100% jouw (bij de notaris gedeponeerde) code gebruikt is erg laag. Je hebt dus opzich een redelijk moeilijke bewijslast.
En als de overtreder gaat nitpicken heb je een lange en dure rechtsgang te gaan.

Oftewel, je hebt wel een bewijslast nodig als uiterste redmiddel. Maar zorg er wel voor dat je onbewuste overtreders een alternatief aanbied wat een rechtszaak voorkomt.
Het is niet zo simpel dat je als je wat code deponeert dat je dan maar elke rechtszaak op je sokken wint.

[Avalaxy]

Dat is waar Maar het sowieso hebben van bewijs is altijd beter dan het niet hebben van bewijs, ook al kun je het niet direct opvoeren als bewijs

[Voutloos]

Misschien een beetje flauw, want kennis over licenties, autersrecht en wat je ter bescherming kan doen kan nooit kwaad, maar eh:
Als je net voor jezelf begint kan je misschien beter eerst het gros van je tijd steken in het uitwerken van iets dat het kopieren waard is.

[Dorgaldir]

Voutloos schreef op donderdag 07 oktober 2010 @ 23:28:
Misschien een beetje flauw, want kennis over licenties, autersrecht en wat je ter bescherming kan doen kan nooit kwaad, maar eh:
Als je net voor jezelf begint kan je misschien beter eerst het gros van je tijd steken in het uitwerken van iets dat het kopieren waard is.

Dat is waar ik denk ook niet dat met wat ik de eerste jaren ga doen ik direct in dat schuitje ga zitten, maar ik ben graag geïnformeerd.

Allesinds iedereen al bedankt voor de uitleg, heb ik al veel van bijgeleerd.

Iemand met kennis van zaken onder de arm nemen is iets wat ik zal overwegen, maar eerst zien dat er wat geld in het laatje zit om die persoon te kunnen betalen he

[YopY]

Voutloos schreef op donderdag 07 oktober 2010 @ 23:28:
Misschien een beetje flauw, want kennis over licenties, autersrecht en wat je ter bescherming kan doen kan nooit kwaad, maar eh:
Als je net voor jezelf begint kan je misschien beter eerst het gros van je tijd steken in het uitwerken van iets dat het kopieren waard is.

+1 . Maar desalniettemin is het vergaren van informatie in deze fase niet verkeerd - stel dat hij een OS library in zijn commerciele product verwerkt, dat ding uitbrengt, honderden licenties verkoopt... en een rechtszaak aan zijn broek krijgt omdat de OS library niet commercieel gebruikt mag worden.

[Herko_ter_Horst]

Kunnen we dan afspreken dat we ophouden "Open Source" tegenover "commercieel" te zetten? Alsof Open Source software geen commerciële waarde heeft. Alsof bedrijven die Open Source software maken/ondersteunen niet commercieel zouden zijn. Je bedoelt waarschijnlijk "Open Source" vs "proprietary".

Open Source mag (volgens de meest gebruikelijke definitie) namelijk altijd commercieel gebruikt worden. Het mag echter niet altijd binnen een product dat onder een proprietary license wordt uitgebracht gebruikt worden.

[H!GHGuY]

Gomez12 schreef op donderdag 07 oktober 2010 @ 21:41:
En blijf in je achterhoofd houden dat een licentie in wezen maar 1x uitgegeven kan worden per product ( oftewel het moet in 1x goed zijn ). Als je later van licentie wilt veranderen en je vroegere code wordt geforked oid dan heb je een heck of a job met uitzoeken/bewijslast.

Dit is volgens mij niet correct.
Als ik vandaag versie 1.0 uitbreng onder GPL (waaraan enkel ikzelf heb gewerkt) dan mag ik volgend jaar versie 1.0 uitbrengen onder MIT of een proprietary license.
Ik mag ook versie 2.0 (die code van 1.0 bevat) uitgeven onder BSD of een proprietary license.

Wie de copyright bezit bepaalt de spelregels van het contract tussen beide partijen (uitgever en gebruiker). De gebruiker heeft enkel wel of niet akkoord te gaan.

Als je met 2 personen aan een stuk software werkt, moet je beide instemmen welke licentie je gebruikt. Stel dat je in onvrede uit elkaar gaat en je wil verderbouwen op de software dan zal je hoogstwaarschijnlijk een bod op de copyrights moeten doen.

[Herko_ter_Horst]

H!GHGuY schreef op vrijdag 08 oktober 2010 @ 12:57:
[...]


Dit is volgens mij niet correct.

Het is in zoverre correct, dat een eenmaal uitgegeven Open Source^(*) licentie niet zomaar meer kan worden ingetrokken: zodra iemand de code onder die licentie heeft gekregen, mag hij deze altijd onder die licentie blijven uitbrengen, ook al schakel jij over op iets anders.

Als ik vandaag versie 1.0 uitbreng onder GPL (waaraan enkel ikzelf heb gewerkt) dan mag ik volgend jaar versie 1.0 uitbrengen onder MIT of een proprietary license.
Ik mag ook versie 2.0 (die code van 1.0 bevat) uitgeven onder BSD of een proprietary license.

Dat klopt, dat mag. Maar versie 1.0 blijft "voor eeuwig" (d.w.z. zolang er nog één kopie onder die license bestaat) óók beschikbaar onder de GPL, naast de nieuwe license. Je kunt niet afdwingen dat de nieuwe license gebruikt wordt. Versie 2.0 is echter alleen onder de nieuwe license verkrijgbaar.

(*) in principe geldt dit ook voor proprietary licenses, maar die hebben vaak ontbindende voorwaarden die hun levensduur beperken

[Voor 9% gewijzigd door Herko_ter_Horst op 08-10-2010 13:08]

[maui71]

Kans is natuurlijk groot dat je gewoon continue ingehuurd wordt op projecten, en dan kan je rechten op je code in 9/10 gevallen gewoon vergeten. Of je moet een "heel" product ontwikkelen wat anderen weer inzetten (aldan niet via een oem constructie).

[Voor 26% gewijzigd door maui71 op 08-10-2010 14:03]

[Dorgaldir]

maui71 schreef op vrijdag 08 oktober 2010 @ 14:02:
Kans is natuurlijk groot dat je gewoon continue ingehuurd wordt op projecten, en dan kan je rechten op je code in 9/10 gevallen gewoon vergeten. Of je moet een "heel" product ontwikkelen wat anderen weer inzetten (aldan niet via een oem constructie).

Dat zal dikwijls inderdaad het geval zijn, maar ik heb enkele ideetjes voor projecten die ik zelf wil uitwerken, en het gaat voornamelijk over die code. Of proberen af te dingen dat je bepaalde stukken code wel zelf mag houden op voorwaarde dat het bedrijf dat je inhuurt er zonder extra kosten gebruik van mag maken oid. Je kan altijd proberen

[Gomez12]

H!GHGuY schreef op vrijdag 08 oktober 2010 @ 12:57:
[...]
Dit is volgens mij niet correct.
Als ik vandaag versie 1.0 uitbreng onder GPL (waaraan enkel ikzelf heb gewerkt) dan mag ik volgend jaar versie 1.0 uitbrengen onder MIT of een proprietary license.
Ik mag ook versie 2.0 (die code van 1.0 bevat) uitgeven onder BSD of een proprietary license.

Klopt, maar nu kom je 2000 regels van jouw code tegen in een andere app. 1500 zijn 100% identiek aan je GPL code, de andere 500 lijkt op je proprietary license, maar er lijken enkel wat veranderingen doorgevoerd.

Komt die code nou uit je GPL-product en is er wat eigenhandig bijgebouwd of is het je proprietary product wat ze een beetje vernaggeld hebben?
Veel plezier met de bewijslast als de klant moeilijk gaat doen.

Over standaard code-licencies wil je al zo goed als nooit een rechtszaak voeren omdat die extreem complex en lang zijn, maar als je ook nog eens van licentievorm veranderd bent dan wordt het imho helemaal hopeloos.

Netzogoed met GPL code naar BSD overbrengen, als jij als ontwikkelaar kwaad wilt dan kan je een lange rechtszaak tegen menig klant beginnen zolang het niet 100% je BSD-code is ( dan kan je namelijk weer betogen dat het je GPL-code met wat maatwerk is ).
Menig klant met kennis van zaken is redelijk huiverig voor dit soort rechtzaken en dan kan er dus niet voor jou gekozen worden omdat jouw code een mogelijk rechtzaak-risico is en de code van je concurrent niet.

Strikt volgens de regels mag je wel van licentie veranderen, maar het is gewoon niet tactisch.

[H!GHGuY]

Herko_ter_Horst schreef op vrijdag 08 oktober 2010 @ 13:05:
[...]
Het is in zoverre correct, dat een eenmaal uitgegeven Open Source^(*) licentie niet zomaar meer kan worden ingetrokken: zodra iemand de code onder die licentie heeft gekregen, mag hij deze altijd onder die licentie blijven uitbrengen, ook al schakel jij over op iets anders.
[...]
Dat klopt, dat mag. Maar versie 1.0 blijft "voor eeuwig" (d.w.z. zolang er nog één kopie onder die license bestaat) óók beschikbaar onder de GPL, naast de nieuwe license. Je kunt niet afdwingen dat de nieuwe license gebruikt wordt. Versie 2.0 is echter alleen onder de nieuwe license verkrijgbaar.

Daar zijn we akkoord, als dit is wat Gomez12 bedoelde.

Gomez12 schreef op vrijdag 08 oktober 2010 @ 20:26:
[...]

Klopt, maar nu kom je 2000 regels van jouw code tegen in een andere app. 1500 zijn 100% identiek aan je GPL code, de andere 500 lijkt op je proprietary license, maar er lijken enkel wat veranderingen doorgevoerd.

Komt die code nou uit je GPL-product en is er wat eigenhandig bijgebouwd of is het je proprietary product wat ze een beetje vernaggeld hebben?
Veel plezier met de bewijslast als de klant moeilijk gaat doen.

Veel succes, maar je kan niet 1 deel van je programma onder GPL en een ander onder een proprietary license uitgeven. GPL, maar dat wist je wel, is een viral license. Als je dus een proprietary stuk meelevert waartegen gelinkt wordt, dan valt die code ook automatisch onder GPL.

Stel nu nog dat het LGPL is dan ben je helemaal niet verplicht om de source van het proprietary stuk vrij te geven
en is er geen probleem.

Ook als je aan dual-licensing doet en je komt je source, in gewijzigde vorm, tegen dan hoop ik toch wel dat je bijhoudt wie je licensees zijn voor het proprietary deel. Niemand zegt trouwens dat je proprietary license modificaties of herdistribueren van source code moeten toestaan. Beter is zelfs om dit niet te doen.
In dat geval, valt ELKE wijziging die je tegenkomt onder GPL. Dus als jouw klant, die een proprietary license heeft verkregen, een gewijzigde vorm verspreidt, komt de proprietary license te vervallen en zijn er best wat manieren om die klant het leven zuur te maken. Invalletje van de politie, rechtszaak over contractbreuk, verlies van inkomsten, ... enz.

Over standaard code-licencies wil je al zo goed als nooit een rechtszaak voeren omdat die extreem complex en lang zijn, maar als je ook nog eens van licentievorm veranderd bent dan wordt het imho helemaal hopeloos.

Netzogoed met GPL code naar BSD overbrengen, als jij als ontwikkelaar kwaad wilt dan kan je een lange rechtszaak tegen menig klant beginnen zolang het niet 100% je BSD-code is ( dan kan je namelijk weer betogen dat het je GPL-code met wat maatwerk is ).
Menig klant met kennis van zaken is redelijk huiverig voor dit soort rechtzaken en dan kan er dus niet voor jou gekozen worden omdat jouw code een mogelijk rechtzaak-risico is en de code van je concurrent niet.

Strikt volgens de regels mag je wel van licentie veranderen, maar het is gewoon niet tactisch.

Als je je code onder BSD uitbrengt dan denk ik niet dat je nog een commercieel doel voor ogen hebt.
BSD staat zowat alles toe met de code zolang je maar de copyright notice en de license mee distribueert (en eventueel de advertising clause respecteert). BSD staat dus ook gebruik in proprietary code toe zonder vrijgave van de aangepaste sources.

Trouwens zijn er genoeg voorbeelden van dual-licensed code: db4o, xsd zijn er al 2 waar ikzelf mee gewerkt heb.

Bovendien zijn bedrijven helemaal niet huiverig tov OS licenses (GPLv3 in het midden gelaten). Ze zien de voordelen van het OS model in en zoeken dan ook elke mogelijk manier om er de voordelen van mee te nemen.

[Gomez12]

H!GHGuY schreef op zaterdag 09 oktober 2010 @ 13:16:
[...]
Veel succes, maar je kan niet 1 deel van je programma onder GPL en een ander onder een proprietary license uitgeven. GPL, maar dat wist je wel, is een viral license. Als je dus een proprietary stuk meelevert waartegen gelinkt wordt, dan valt die code ook automatisch onder GPL.

Enkel als je "gebruiker"/klant bent. Als je zelf de copyrights bezit mag je dezelfde code wel onder 20 licenses uitgeven.
Wat jij nu stelt is (in extrema) dat als iemand 1 regel code onder GPL als hobby schrijft, dat hij die regel code dan niet meer voor zijn baas mag gebruiken. Zo werkt dat dus niet. Als jij alle rechten erop bezit dan mag jij ermee doen wat je wilt.

Niemand zegt trouwens dat je proprietary license modificaties of herdistribueren van source code moeten toestaan. Beter is zelfs om dit niet te doen.

Hangt heel erg van je klant af. Grotere klanten worden al niet erg blij als ze niet de rechten op jouw kleine stukje code krijgen, als ze er nu en toekomstig niets aan mogen veranderen dan wordt het helemaal verkopen.

In dat geval, valt ELKE wijziging die je tegenkomt onder GPL. Dus als jouw klant, die een proprietary license heeft verkregen, een gewijzigde vorm verspreidt, komt de proprietary license te vervallen en zijn er best wat manieren om die klant het leven zuur te maken.

Interessant, dat wist ik niet. Bij dual licensing als dus de proprietary vervalt dan wordt er automagisch teruggeschakeld naar GPL (indien dat de andere licentie was)? Begrijp ik het zo goed?
Want dat lijkt me een bizar gevalletje waar ik wel eens een onderbouwing van zou willen zien.

Invalletje van de politie, rechtszaak over contractbreuk, verlies van inkomsten, ... enz.

En als zolderkamer programmeur regel je natuurlijk zo een invalletje van de politie bij een groot bedrijf etc.

[...]
Trouwens zijn er genoeg voorbeelden van dual-licensed code: db4o, xsd zijn er al 2 waar ikzelf mee gewerkt heb.

Bovendien zijn bedrijven helemaal niet huiverig tov OS licenses (GPLv3 in het midden gelaten). Ze zien de voordelen van het OS model in en zoeken dan ook elke mogelijk manier om er de voordelen van mee te nemen.

Ik zeg ook niet dat ze huiverig zijn voor OS licenses, ik zeg ook niet dat ze huiverig zijn voor dual licenses ( voordat je daarmee komt ), ik zeg enkel dat ze huiverig zijn voor license veranderingen.

Andere reden waarom ze oa niet blij worden van license veranderingen is dat (bij een grotere klant) een license serieus nagekeken moet worden door een legal afdeling etc. Als dat eenmaal goedgekeurd is, dan kan er in geinvesteerd worden om er omheen te bouwen.
Bij een license verandering moet eerst legal er weer overheen kijken ( in die tijd kan je niets met de nieuwe versie doen ) daarna heb je kans dat je je huidige gebruik moet aanpassen als je de nieuwe code wilt blijven gebruiken, of je kan de oude code gaan forken waardoor je een hele hoop meer updatewerk ( is geld ) intern neerlegt.

[Herko_ter_Horst]

Gomez12 schreef op zaterdag 09 oktober 2010 @ 14:18:
[...]

Interessant, dat wist ik niet. Bij dual licensing als dus de proprietary vervalt dan wordt er automagisch teruggeschakeld naar GPL (indien dat de andere licentie was)? Begrijp ik het zo goed?
Want dat lijkt me een bizar gevalletje waar ik wel eens een onderbouwing van zou willen zien.

Er is geen "automagische terugschakeling", er is enkel het recht om de code te mogen gebruiken. Als dat recht volgens de proprietary license om wat voor reden dan ook vervalt, dan is de enige licentie die nog recht geeft te code te gebruiken, de andere licentie uit de dual license constructie, in dit voorbeeld de GPL. Wil je die code blijven gebruiken verspreiden, dan zul je die andere licentievoorwaarden moeten accepteren.

Vervolgens is de GPL een uitzondering op de meeste andere Open Source licenties, vanwege het virale sterke copyleft gedrag van deze licentie. De GPL dwingt namelijk af dat code die met GPL code gelinkt is, óók onder de GPL moet worden uitgebracht. Daarmee is in de meeste gevallen een middenweg niet mogelijk: zit er een stukje GPL code in jouw code, dan moet volgens de GPL alle code onder de GPL worden uitgebracht.

[Gomez12]

Herko_ter_Horst schreef op zaterdag 09 oktober 2010 @ 14:41:
[...]
Er is geen "automagische terugschakeling", er is enkel het recht om de code te mogen gebruiken. Als dat recht volgens de proprietary license om wat voor reden dan ook vervalt, dan is de enige licentie die nog recht geeft te code te gebruiken, de andere licentie uit de dual license constructie, in dit voorbeeld de GPL. Wil je die code blijven gebruiken verspreiden, dan zul je die andere licentievoorwaarden moeten accepteren.

Dus standaard heb je dan niets te maken met de GPL kant, je bent gewoon een illegale gebruiker. Pas als je de GPL license accepteert dan pas val je onder GPL. Duidelijk, ik vond het al zo vreemd.

[Herko_ter_Horst]

Gomez12 schreef op zaterdag 09 oktober 2010 @ 15:19:
[...]

Dus standaard heb je dan niets te maken met de GPL kant, je bent gewoon een illegale gebruiker. Pas als je de GPL license accepteert dan pas val je onder GPL. Duidelijk, ik vond het al zo vreemd.

Klopt, maar pas even op met het woord 'gebruiker': zolang je de software alleen maar gebruikt (voor jezelf, of intern binnen een organisatie), zijn de meeste voorwaarden van de GPL (of andere OS licenties) helemaal niet van toepassing. Pas als je de software - al dan niet combinatie met eigen code, aanpassingen, e.d. - gaat verspreiden, ontstaan de meeste verplichtingen.

[Soultaker]

Herko_ter_Horst schreef op zaterdag 09 oktober 2010 @ 14:41:
Wil je die code blijven gebruiken verspreiden, dan zul je die andere licentievoorwaarden moeten accepteren.

Juist het gebruik van computerprogramma's wordt ook beperkt onder de auteurswet. Als een licentie verlopen is (of als je helemaal nooit een licentie had) mag je officieel de software dus niet blijven gebruiken.

@Hierboven: ik weet niet of je het verkeerd begrijpt of het ongelukkig uitlegt, maar de GPL is wél van toepassing op gebruik, in de zin dat de GPL eigen gebruik expliciet toestaat waar de auteurswet dat (zonder toestemming) verbiedt. Het verschil tussen gebruik en distributie is relevant voor de GPL omdat je de broncode van je programma pas openbaar hoeft te maken als je het daadwerkelijk distribueert (wat helaas nogal een vage term is). Maar je moet nog steeds de GPL accepteren (of een andere licentie natuurlijk) om software te mogen gebruiken.

[Voor 38% gewijzigd door Soultaker op 09-10-2010 16:04]

[H!GHGuY]

Gomez12 schreef op zaterdag 09 oktober 2010 @ 14:18:
[...]
Enkel als je "gebruiker"/klant bent. Als je zelf de copyrights bezit mag je dezelfde code wel onder 20 licenses uitgeven.
Wat jij nu stelt is (in extrema) dat als iemand 1 regel code onder GPL als hobby schrijft, dat hij die regel code dan niet meer voor zijn baas mag gebruiken. Zo werkt dat dus niet. Als jij alle rechten erop bezit dan mag jij ermee doen wat je wilt.

In realiteit is het nog erger. Wat jij in opdracht schrijft van je baas hoort hem toe. Maw van alle code die je op het werk schrijft behoort de copyright toe aan je baas. (Althans bij het gemiddelde arbeidscontract)
Als jij in je hobby GPL-code schrijft en die vrijgeeft en vervolgens diezelfde code copy-paste in software voor je werk, dan heb je een probleem. Ik ben geen advocaat, dus ik kan niet zeggen wat er gebeurt, maar er is wel degelijk een probleem: volgens copyright behoort de code jou toe, terwijl je ze toch in code voor je baas gebruikt.
Afhankelijk van je contract en de wetgeving kan hier dus een conflict ontstaan.

[...]
Hangt heel erg van je klant af. Grotere klanten worden al niet erg blij als ze niet de rechten op jouw kleine stukje code krijgen, als ze er nu en toekomstig niets aan mogen veranderen dan wordt het helemaal verkopen.

We weten beiden dat de omstandigheden hier wel afhankelijk zijn van veel context.
Het gaat voornamelijk over het verschil tussen herdistributie in binaire vorm of in code-vorm. Vermoedelijk staan de meeste commercial/proprietary licenses (in een dual-license systeem) wel binary herdistributie toe, maar geen code distributie. Doe je dit toch, van valt het herdistribueren onder de GPL license aangezien dat de enige andere beschikbare license is (die je trouwens impliciet accepteert op het moment dat je aan herdistributie doet).

[...]
Interessant, dat wist ik niet. Bij dual licensing als dus de proprietary vervalt dan wordt er automagisch teruggeschakeld naar GPL (indien dat de andere licentie was)? Begrijp ik het zo goed?
Want dat lijkt me een bizar gevalletje waar ik wel eens een onderbouwing van zou willen zien.

Zoals Herko zegt: bij multi-licensing heb je de keuze welke license je aan voldoet. Bij proprietary/commercial licenses is een deel van de overeenkomst typisch de overdracht van $€. Doe je iets wat onder de ene license niet kan, maar wel onder een andere license, dan heb jij (al dan niet impliciet) gekozen om die andere license te gebruiken. Voorwaarde blijft wel dat je voldoet aan alle voorwaarden in de license.
Als je bijvoorbeeld (GPL) dual-licensed code onder een proprietary license aankoopt, dan heb je ook nog altijd het recht om de code volgens de GPL te behandelen en te herdistribueren alsook het recht om volgens de proprietary license te handelen.

[...]
En als zolderkamer programmeur regel je natuurlijk zo een invalletje van de politie bij een groot bedrijf etc.

Jij hebt even veel rechten als een multi-national. Als jij afdoende bewijzen hebt kun je evenveel. (Los van het gemiddelde kromme rechtssysteem natuurlijk )

[...]
Ik zeg ook niet dat ze huiverig zijn voor OS licenses, ik zeg ook niet dat ze huiverig zijn voor dual licenses ( voordat je daarmee komt ), ik zeg enkel dat ze huiverig zijn voor license veranderingen.

Andere reden waarom ze oa niet blij worden van license veranderingen is dat (bij een grotere klant) een license serieus nagekeken moet worden door een legal afdeling etc. Als dat eenmaal goedgekeurd is, dan kan er in geinvesteerd worden om er omheen te bouwen.
Bij een license verandering moet eerst legal er weer overheen kijken ( in die tijd kan je niets met de nieuwe versie doen ) daarna heb je kans dat je je huidige gebruik moet aanpassen als je de nieuwe code wilt blijven gebruiken, of je kan de oude code gaan forken waardoor je een hele hoop meer updatewerk ( is geld ) intern neerlegt.

Als je idd elke versie van je programma een nieuwe license geeft dan zullen er wel een paar legal departementen met extra werkzekerheid zijn en zullen je klanten dit niet zo apprecieren.
Als je echter de oude license behoudt voor die klanten (mits dit voor jou accepteerbaar is) maakt het hen niet uit aan welke license je jouw product ook aan Piet of Pol verkoopt.
Tenzij je een termijn vastlegt in je license (dan zul je waarschijnlijk je klanten zien huiveren) kunnen ze het stuk software die ze van jou krijgen levenslang(of een andere lange termijn?) onder die license gebruiken. Dat ze dan misschien die allerlaatste release niet onder die license kunnen krijgen is dan hun probleem, maar hoe groter de klant hoe meer $$ er over tafel kunnen komen om alsnog updates te krijgen

Gomez12 schreef op zaterdag 09 oktober 2010 @ 15:19:
[...]

Dus standaard heb je dan niets te maken met de GPL kant, je bent gewoon een illegale gebruiker. Pas als je de GPL license accepteert dan pas val je onder GPL. Duidelijk, ik vond het al zo vreemd.

En accepteren doe je volgens GPL zo:

From http://www.gnu.org/licenses/old-licenses/gpl-2.0.html:
5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.

[Voor 9% gewijzigd door H!GHGuY op 09-10-2010 16:35]

[Herko_ter_Horst]

Soultaker schreef op zaterdag 09 oktober 2010 @ 16:01:
[...]

Juist het gebruik van computerprogramma's wordt ook beperkt onder de auteurswet. Als een licentie verlopen is (of als je helemaal nooit een licentie had) mag je officieel de software dus niet blijven gebruiken.

@Hierboven: ik weet niet of je het verkeerd begrijpt of het ongelukkig uitlegt, maar de GPL is wél van toepassing op gebruik, in de zin dat de GPL eigen gebruik expliciet toestaat waar de auteurswet dat (zonder toestemming) verbiedt. Het verschil tussen gebruik en distributie is relevant voor de GPL omdat je de broncode van je programma pas openbaar hoeft te maken als je het daadwerkelijk distribueert (wat helaas nogal een vage term is). Maar je moet nog steeds de GPL accepteren (of een andere licentie natuurlijk) om software te mogen gebruiken.

Ik legde het inderdaad wat ongelukkig uit: ik noemde wel expliciet Open Source licenses, maar vergat te vermelden dat alle OS licenses gebruik expliciet toestaan, anders voldoen ze niet aan de OS definitie van de OSI (die hou ik maar even aan als het om Open Source gaat).

[Herko_ter_Horst]

H!GHGuY schreef op zaterdag 09 oktober 2010 @ 16:31:
Als je bijvoorbeeld (GPL) dual-licensed code onder een proprietary license aankoopt, dan heb je ook nog altijd het recht om de code volgens de GPL te behandelen en te herdistribueren alsook het recht om volgens de proprietary license te handelen.

Ik ben het grotendeels met je eens, maar dit is volgens mij niet correct (of het staat er wat krom). Je krijgt dual-licensed code maar onder 1 license, in dit voorbeeld of de proprietary, of de GPL; niet allebei. Je hebt niet beide rechten tegelijkertijd, want je hebt ook niet beide plichten tegelijkertijd. Je kunt wel besluiten om bij intrekking van de proprietary license de GPL te gaan gebruiken (met alle rechten en plichten vandien), maar het kan niet tegelijkertijd (tenzij de twee licenties expliciet bedoeld zijn om tegelijkertijd te werken).

[H!GHGuY]

Herko_ter_Horst schreef op zaterdag 09 oktober 2010 @ 18:17:
[...]

Ik ben het grotendeels met je eens, maar dit is volgens mij niet correct (of het staat er wat krom). Je krijgt dual-licensed code maar onder 1 license, in dit voorbeeld of de proprietary, of de GPL; niet allebei. Je hebt niet beide rechten tegelijkertijd, want je hebt ook niet beide plichten tegelijkertijd. Je kunt wel besluiten om bij intrekking van de proprietary license de GPL te gaan gebruiken (met alle rechten en plichten vandien), maar het kan niet tegelijkertijd (tenzij de twee licenties expliciet bedoeld zijn om tegelijkertijd te werken).

Je mag niet de rechten en plichten combineren als dat is wat je bedoelt. Maar je mag voor zover ik weet wel per use-case een licentie kiezen en je dan aan zowel de rechten als de plichten van die license houden.
Bvb: bedrijf X kiest ervoor om Z (dual GPL/proprietary) aan te kopen om source code van Y te vrijwaren van GPL. X kan dus product Y op de markt zetten met Z, zonder (al dan niet aangepaste) broncode van Z of product Y vrij te geven. Bedrijf X kan, tegelijkertijd, kiezen om hun changes aan Z alsnog onder GPL vrij te geven los van product Y.

[ReTechNL]

Zoiezo je code scramble en ik raad aan een eigen licentie systeem te schrijven met licentie code etc.
zorg dat als de code niet klopt of bijv. niet overeen komt met jou gegevens dat je je software niet bruikbaar maakt todat de licentie klopt.

[Herko_ter_Horst]

@janstaal Heb je überhaupt gelezen waar het over gaat in dit topic of zag je bij thuiskomst uit de kroeg een leuke titel en dacht je: daar ga ik eens even wat op blaten?

offtopic:
Zelf een licentiesysteem schrijven zou ik sowieso niet doen, en code obfuscaten is security through obscurity en daarom onzinnig.

[Dorgaldir]

wow weer een hele boterham erbij voor op een maandag morgen te lezen
Ik vind het allemaal zeer interessant maar ook zeer ingewikkeld

Ik ben uit een paar dingen al uit:
- veel ingewikkelder dan ik dacht
- niet zelf een licentie schrijven, lijkt me veel en veel te ingewikkeld
- ik ga proberen elke stuk apparte code maar onder 1 licentie uit te brengen (welke ben ik nog altijd niet helemaal uit maar komt wel )
- ik denk dat ik eens een klein progammatje ga schrijven of zoeken om heel die boel te ordenen.

toch nog eens hartelijk bedankt aan iedereen die gereageerd heeft, ik heb hier vrij veel aan