Commits een andere licentie geven

[Loller1]

Hallo iedereen,

Ik vroeg mij af, is het toegestaan om commits die jezelf hebt gemaakt voor een GPL project te relicenseren onder MIT? En zo ja, als het hele project wordt herschreven met commits die ik publiceer onder MIT, is het dan toegestaan om het project zelf, dat origineel GPL was en dus in de beschreven situatie volledig is herschreven met MIT-gelicenseerde commits, te licenseren als MIT in zijn geheel?

Vriendelijke groeten,
Yannick

[Barryvdh]

Wat wil je nou doen dan, een heel project importeren via nieuwe commits? Je mag alsnog niet zomaar stukken code van andere gebruiken en onder je eigen licentie gooien lijkt me.
Hier misschien interessante discussie over het omzetten van Twitter Bootstrap naar MIT, daar hebben ze elke contributor toestemming gevraagd om de licentie van zijn stukje code om te zetten: https://github.com/twbs/bootstrap/issues/2054

[Koenvh]

Nee. Zonder toestemming is het niet mogelijk een licentie aan te passen. Je kunt de GPL code gebruiken, maar dan moet je alle aanpassingen en toevoegingen aan die code ook onder de GPL-licentie uitbrengen.

[windwarrior]

Het werkt geloof ik zo:

• Iedere copyright houdende partij moet het eens zijn met de relicentie
• Commits waarvan de copyright houdende partij het er niet mee eens is moeten herschreven

Een licentie is niets dan een afspraak tussen twee partijen voor het gebruiken van code. De licentie wordt versterkt door het copyright, want omdat jij copyright hebt op code mag iemand anders er niets mee tenzij hij een licentie met jou sluit (in dit geval dus GPL)

[Freeaqingme]

Op zich mag je nieuwe code in eenzelfde repo prima onder een andere licentie vrijgeven. Echter, als het werk in die commit een afgeleide (derivative work) is, dan moet je dat volgens de GPL licentie ook onder de GPL vrijgeven.

[Loller1]

Waar ik op doel is het volgende:

Commits die ik zelf heb geschreven, mag ik die relicenseren onder een andere licentie?

Zo ja, wat als een GPL project van iemand anders, door mij wordt aangepast, en eindigt dat geen enkele lijn code meer hetzelfde is, mag ik dan ook bepalen of die code MIT wordt (onder een andere naam enzo, natuurlijk).

[D-Raven]

Loller1 schreef op woensdag 12 maart 2014 @ 16:47:
Waar ik op doel is het volgende:

Commits die ik zelf heb geschreven, mag ik die relicenseren onder een andere licentie?

Zo ja, wat als een GPL project van iemand anders, door mij wordt aangepast, en eindigt dat geen enkele lijn code meer hetzelfde is, mag ik dan ook bepalen of die code MIT wordt (onder een andere naam enzo, natuurlijk).

Nee. Dat zou wel een hele makkelijke manier zijn om onder Licentie Restricties uit te komen nietwaar?

Als jij Commit naar een project welke onder de GPL licentie valt, dan zijn jou commits dit automatisch ook. Hiermee ga je automatisch akkoord op het moment dat je commit naar die repos.

Dit laatste geld overigens ongeacht de licentie van het project waar aan je contribute, tenzij expliciet anders wordt aangegeven door de oorspronkelijke auteurs.

[ Voor 9% gewijzigd door D-Raven op 12-03-2014 17:03 ]

[Loller1]

Wel, de mensen bij Bootstrap deden iets gelijkaardigs, ze herschreven commits van commiters die geen toestemming gaven om over te schakelen op MIT ook, vandaar.

[D-Raven]

Het grote verschil is dat dit geïnitieerd werd en gedaan door de oorspronkelijke auteurs van Bootstrap zelf...
en niet door een committer die de huidige licentie maar onhandig vind.

Je bent eigenlijk op zoek naar een juridisch legale manier om de code van iemand anders te kunnen gebruiken, zonder je te hoeven houden aan de licentie welke is bepaald door de oorspronkelijke auteur.

Zou makkelijk zijn als dat kan/mag. Kan ik lekker RavenDB forken, hier de licentie check uit slopen, vervolgens overal de code formatting aanpassen, alle variabele namen aanpassen (en nog wat andere dingen aanpassen), en vervolgens uitbrengen onder de MIT licentie. Hoppa, hoef ik er lekker niet voor te betalen.

[Loller1]

Dat bedoel ik niet, ik wil niet gewoon de namen van variabelen, etc. aanpassen maar het project echt volledig herschrijven (mag ook wel na 11 jaar van stilstand). Na de herschrijving blijft er echt niks meer over van het originele project, tenzij het gewoon niet anders kan, zoals een config.php bestand, nogal moeilijk anders te doen.

[pedorus]

Voorbeeld van een project waarbij eerst in delen dingen zijn aangepast, en uiteindelijk alles wat niet was aangepast herschreven is om een andere licentie te kunnen gebruiken: http://epplus.codeplex.com/releases/view/79802

Als je zelf op ALLES het copyright hebt, kun je willekeurig een licentie uitkiezen. Op dezelfde manier dat je je eigen code onder meerdere licenties kan uitgeven.

[D-Raven]

Loller1 schreef op woensdag 12 maart 2014 @ 17:58:
Dat bedoel ik niet, ik wil niet gewoon de namen van variabelen, etc. aanpassen maar het project echt volledig herschrijven (mag ook wel na 11 jaar van stilstand). Na de herschrijving blijft er echt niks meer over van het originele project, tenzij het gewoon niet anders kan, zoals een config.php bestand, nogal moeilijk anders te doen.

Als het project echt al zolang stil staat, en je wilt er echt mee aan de gang, waarom vraag je dan geen toestemming van de oorspronkelijke auteur om het project over te nemen?

[Gerco]

Loller1 schreef op woensdag 12 maart 2014 @ 17:58:
Dat bedoel ik niet, ik wil niet gewoon de namen van variabelen, etc. aanpassen maar het project echt volledig herschrijven (mag ook wel na 11 jaar van stilstand). Na de herschrijving blijft er echt niks meer over van het originele project, tenzij het gewoon niet anders kan, zoals een config.php bestand, nogal moeilijk anders te doen.

Als je alles herschrijft is het toch gewoon een nieuw project? In dat geval kun je iedere licentie kiezen die je wilt. Dat het nieuwe project compatible is met het oude lijkt me verder geen probleem (IANAL, natuurlijk).

Volgens mij zegt de Nederlandse of Europese wet dat je voor compatibiliteit bijvoorbeeld mag reverse engineeren en dat het resultaat daarvan geen copyright schending is van het origineel, dat zou hier wel eens van toepassing kunnen zijn als je nieuwe project de database of fileformat van het oude project kan lezen en bewerken.

[Loller1]

Gerco schreef op woensdag 12 maart 2014 @ 18:23:
[...]


Als je alles herschrijft is het toch gewoon een nieuw project? In dat geval kun je iedere licentie kiezen die je wilt. Dat het nieuwe project compatible is met het oude lijkt me verder geen probleem (IANAL, natuurlijk).

Volgens mij zegt de Nederlandse of Europese wet dat je voor compatibiliteit bijvoorbeeld mag reverse engineeren en dat het resultaat daarvan geen copyright schending is van het origineel, dat zou hier wel eens van toepassing kunnen zijn als je nieuwe project de database of fileformat van het oude project kan lezen en bewerken.

Ja, dit is eigenlijk de bedoeling, ik behoud de oude source code alleen maar vanwege database compatibliteit, zo herschrijf ik het project stuk voor stuk, maar heb ik wel een werkende database en weet ik dat het gewoon compatibel is.

D-Raven schreef op woensdag 12 maart 2014 @ 18:20:
[...]


Als het project echt al zolang stil staat, en je wilt er echt mee aan de gang, waarom vraag je dan geen toestemming van de oorspronkelijke auteur om het project over te nemen?

Dat is niet echt wat ik bedoelde, ik bedoelde eerder dat het project gebaseerd is op code van 11 jaar geleden en sindsdien niks meer is veranderd, alleen enkele features toegevoegd en nieuw ontwerpje, het maakt nog steeds gebruik van oude technieken om code te schrijven, object-oriented valt niet te bespeuren, etc. Daarom, de codebase is zo verouderd dat het gewoon een volledige rewrite nodig heeft om acceptabel te zijn.

D-Raven schreef op woensdag 12 maart 2014 @ 17:56:
Het grote verschil is dat dit geïnitieerd werd en gedaan door de oorspronkelijke auteurs van Bootstrap zelf...
en niet door een committer die de huidige licentie maar onhandig vind.

Bedankt voor de reactie, anyway, ik denk niet dat het veel verschil maakt of het nu de originele maker is die commits die nog GPL zijn herschrijf of een commiter die commits die GPL zijn herschrijft, lijkt me nogal oneerlijk.

[ Voor 41% gewijzigd door Loller1 op 12-03-2014 18:36 ]

[begintmeta]

Code die jij zelf schrijft (en m.n. waarover jij de auteursrechten hebt) kan je onder de licenties beschikbaar maken die jij kiest. Je kan dezelfde code best onder verschillende licenties uitgeven. Over andermans code mag die ander beslissen.

[ Voor 10% gewijzigd door begintmeta op 12-03-2014 18:41 ]

[Freeaqingme]

begintmeta schreef op woensdag 12 maart 2014 @ 18:40:
Code die jij zelf schrijft (en m.n. waarover jij de auteursrechten hebt) kan je onder de licenties beschikbaar maken die jij kiest. Je kan dezelfde code best onder verschillende licenties uitgeven. Over andermans code mag die ander beslissen.

Tenzij dus, het een afgeleide werk is van een ander GPL-werk. Dan zal je je aan de GPL moeten houden.

[Gerco]

Loller1 schreef op woensdag 12 maart 2014 @ 18:32:
Ja, dit is eigenlijk de bedoeling, ik behoud de oude source code alleen maar vanwege database compatibliteit, zo herschrijf ik het project stuk voor stuk, maar heb ik wel een werkende database en weet ik dat het gewoon compatibel is.

Ik zou eens onderzoeken of het DB schema onder de GPL valt. Er zijn verschillende bronnen op internet die daar anders over denken, zoals dit forumtopic en deze vraag op Stack Exchange

Uiteindelijk is het enige antwoord wat je hier echt kunt krijgen: Praat met een advocaat. En zelfs die kan je geen goed antwoord geven tot deze materie in de rechtbank ergens getoetst is.

[D-Raven]

Loller1 schreef op woensdag 12 maart 2014 @ 18:32:
[...]
Ja, dit is eigenlijk de bedoeling, ik behoud de oude source code alleen maar vanwege database compatibliteit, zo herschrijf ik het project stuk voor stuk, maar heb ik wel een werkende database en weet ik dat het gewoon compatibel is.

[...]

Dat is niet echt wat ik bedoelde, ik bedoelde eerder dat het project gebaseerd is op code van 11 jaar geleden en sindsdien niks meer is veranderd, alleen enkele features toegevoegd en nieuw ontwerpje, het maakt nog steeds gebruik van oude technieken om code te schrijven, object-oriented valt niet te bespeuren, etc. Daarom, de codebase is zo verouderd dat het gewoon een volledige rewrite nodig heeft om acceptabel te zijn.

[...]

Bedankt voor de reactie, anyway, ik denk niet dat het veel verschil maakt of het nu de originele maker is die commits die nog GPL zijn herschrijf of een commiter die commits die GPL zijn herschrijft, lijkt me nogal oneerlijk.

Ah zo, Nouja je zult toch met de repos owner moeten gaan praten, helemaal vanwege de virale eigenschappen van de GPL. (afgeleide werk enzo wat Gerco ook al aangeeft).
Want als jij als committer zijnde zijn werk helemaal wilt gaan herschrijven.... uiteindelijk zal hij toch jou pull-request moeten accepteren, en als hij dat niet doet... tjah.

Alternatief is om een fork te maken en deze te herschrijven, dan heb je altijd nog de mogelijkheid om het later weer te mergen met het origineel, maar dan is je werk in ieder geval niet voor niks.

[Gomez12]

Loller1 schreef op woensdag 12 maart 2014 @ 18:32:
[...]
Ja, dit is eigenlijk de bedoeling, ik behoud de oude source code alleen maar vanwege database compatibliteit, zo herschrijf ik het project stuk voor stuk, maar heb ik wel een werkende database en weet ik dat het gewoon compatibel is.

Het probleem is het stuk voor stuk. Dat werkt slecht met een virale licentie.

In wezen als jij vandaag vanaf nul begint en alles herschrijft en pas een versie uitgeeft als je alles herschreven hebt dan heb je een nieuw werk gemaakt (zitten wel wat haken en ogen aan, maar in basis)

Alleen als jij nog maar de helft herschreven hebt en je brengt dan een versie uit dan infecteert de nog aanwezige GPL-helft je herschreven helft en als je dan uitendelijk de boel compleet herschreven hebt dan infecteert je 1e herschreven helft (die onderhand GPL is) je complete werk. En dan is je complete werk dus GPL.
Alhoewel jij het dan wel weer mag herlicenseren aangezien jij alle rechten hebt, alleen blijft er dan een kopie bestaan die GPL is en blijft en die mogen anderen dan weer forken.

Qua GPL naar MIT lijkt me dit een acceptabele weg, maar voor bijv GPL -> closed source is dit een erg vervelende weg

Het enige wat je mogelijk nog moet inschatten is wat de kans is dat de originele copyright-houders je gaan aanklagen... Als je namelijk een aanklacht krijgt dan heb je met dit soort trajecten een drama-procesgang, want dan moet je opeens gaan bewijzen dat het geen afgeleid werk is, dat alles zelf geschreven is (en niet Ctrl-C -> Ctrl-V om je eigen naam bij de commits te krijgen) en dat is een dramatische rechtsgang.

[begintmeta]

Freeaqingme schreef op woensdag 12 maart 2014 @ 19:01:
[...]

Tenzij dus, het een afgeleide werk is van een ander GPL-werk. Dan zal je je aan de GPL moeten houden.

Nee hoor, als het een afgeleid werk is, is het niet volledig jouw werk. Over wat precies een afgeleid werk zou zijn, bestaan weer wat verschillende opvattingen.

Je 'eigen code' kan je in principe rustig gebruiken.

[ Voor 20% gewijzigd door begintmeta op 12-03-2014 22:10 ]

[Freeaqingme]

begintmeta schreef op woensdag 12 maart 2014 @ 19:57:
[...]

Nee hoor, als het een afgeleid werk is, is het niet volledig jou werk.

Waarom? Het een sluit het ander niet uit?

[begintmeta]

Freeaqingme schreef op woensdag 12 maart 2014 @ 21:06:
[...]

Waarom? Het een sluit het ander niet uit?

Als je heel strikt zou kijken is denk ik praktisch gezien elk programma een afgeleid werk., maar ergens moet een grens worden getrokken.

Een afgeleid werk bevat in principe altijd iets van het werk waarvan het is afgeleid. Dat iets is dan niet van jezelf, dus daarom sluit het een het ander uit. Het blijft natuurlijk enigszins vage materie, want je moet toch bepalen of/in welke zin of in welke mate iets iets anders bevat....

[ Voor 24% gewijzigd door begintmeta op 12-03-2014 22:07 ]

[drm]

En om het nog een klein beetje aan te scherpen, gaan alle open source licentievormen over distributie, en niet eens zozeer over het gebruik van de code of het ervan afhankelijk zijn (alleen GPL v3 is daar vaag over, voor zover ik het begrepen heb). Dus als je een afgeleide werk publiceert en wilt gaan distribueren wordt het pas moeilijk. Zo lang jij aan het werk bent om iets te bouwen wat compatibel is met een oud database schema, dan is er niks aan de hand en kun je jouw deel van de code gewoon onder MIT distribueren. Je kunt het alleen niet gecombineerd distribueren en als geheel ergens aanbieden, want dan overruled de GPL eigenlijk de MIT license. Maar dat neemt natuurlijk niet weg dat je een README kunt posten waarin je instructies plaatst over hoe je het MIT-licensed project gebruikt samen met een GPL-licensed basis. Dat kan prima.

[Gomez12]

begintmeta schreef op woensdag 12 maart 2014 @ 22:05:
[...]

Als je heel strikt zou kijken is denk ik praktisch gezien elk programma een afgeleid werk., maar ergens moet een grens worden getrokken.

Een afgeleid werk bevat in principe altijd iets van het werk waarvan het is afgeleid. Dat iets is dan niet van jezelf, dus daarom sluit het een het ander uit. Het blijft natuurlijk enigszins vage materie, want je moet toch bepalen of/in welke zin of in welke mate iets iets anders bevat....

Het probleem is dat TS het beetje bij beetje wil doen en dan verschuift de grens steeds een beetje.

Heb je een bestaand programma en vervang je 1 regel toe dan is dat een afgeleid werk van het 1e product.
Vervang je nu nog 1 regel dan is het gedeeltelijk een afgeleid werk van het 1e programma, maar meer een afgeleid werk van de versie voordat je deze regel verving.

En dat soort geintjes maakt het complex bij stukje bij stukje vervangen.
Als ik even als voorbeeld een programma van 3 regels neem wat onder de GPL valt :
- Je vervangt regel 1, dit eindproduct is een afgeleid werk en valt dus compleet onder GPL
- Je vervangt regel 2, dit eindproduct is een afgeleid werk van de vorige stap en dus een afgeleid werk van een GPL prog dus valt dit ook onder GPL
- Je vervangt regel 3, dit eindproduct is een afgeleid werk van de vorige stap en dus een afgeleid werk van een GPL prog dus valt dit ook onder GPL ook al heb je nu alle code zelf geschreven. Nu kan je het wel herlicenseren (want jij hebt alle rechten op alle regels) naar MIT en dan onder de MIT licentie regel 4 en 5 toevoegen. Maar als iemand dan jouw GPL versie van 3 regels forked en daar heel handige regel 4 en 5 toevoegt dan mag jij die niet zomaar meer overnemen in jouw MIT licensie want dan wordt je MIT-licensie automatisch weer GPL.

[Gomez12]

drm schreef op woensdag 12 maart 2014 @ 23:44:
En om het nog een klein beetje aan te scherpen, gaan alle open source licentievormen over distributie, en niet eens zozeer over het gebruik van de code of het ervan afhankelijk zijn (alleen GPL v3 is daar vaag over

De GPL gaat ook zeker wel over het gebruik van de code, daarvoor is juist een LGPL toendertijd noodzakelijk geworden.

Zo lang jij aan het werk bent om iets te bouwen wat compatibel is met een oud database schema, dan is er niks aan de hand en kun je jouw deel van de code gewoon onder MIT distribueren. Je kunt het alleen niet gecombineerd distribueren en als geheel ergens aanbieden, want dan overruled de GPL eigenlijk de MIT license. Maar dat neemt natuurlijk niet weg dat je een README kunt posten waarin je instructies plaatst over hoe je het MIT-licensed project gebruikt samen met een GPL-licensed basis. Dat kan prima.

Over het algemeen is een readme twijfelachtig, wil je het zekere voor het onzekere nemen dan bied je jouw gedeelte aan, een link naar de GPL-code en laat je het de gebruiker zelf combineren.
Enige nadeel is dat je dan niet 1 programma aanbied, maar meer source code of een soort van plugin. en dat is weer ingewikkeld voor de casual gebruiker.

[H!GHGuY]

Gomez12 schreef op woensdag 12 maart 2014 @ 23:49:
[...]

De GPL gaat ook zeker wel over het gebruik van de code, daarvoor is juist een LGPL toendertijd noodzakelijk geworden.

Nee hoor. Het gaat over distribueren; het is immers een "contract" tussen 2 partijen die plaatsvind tijdens distributie van de code. Met dat contract komen rechten en plichten.

ZFS en de Linux kernel zijn niet license-compatible. Niemand belemmert echter het ZOL (ZFS-on-Linux) project doordat ze hun code niet samen distribueren met de kernel. Het is de eindgebruiker die de 2 werken combineert, het afgeleide werk maakt en gebruikt (maar _niet_ distribueert).
PC's in mekaar steken met ZOL en verkopen is een license violation.

Je mag trouwens wel proprietary code linken met GPL code. Pas bij het distribueren van de combinatie wordt de combinatie volledig GPL.

Ik denk dat je beste opties hier al aangestipt zijn:
- vraag aan de originele auteurs (allemaal!) of ze de code onder een MIT license willen vrijgeven.
- begin helemaal van scratch
- graduele rewrite

Deze laatste is eigenlijk licensewise een idioot idee. Je moet echt de volledige source herschrijven zodat _elke_ regel in de code uiteindelijk volledig nieuw door jou is geschreven. Je mag geen for/while-loop of if-conditie overlaten... Voor veel logica is dit gewoon idioot aangezien je hetzelfde algoritme wil implementeren.
Bovendien kun je pas een nieuwe license kiezen eens de laatste regel GPL vervangen is. Je project kan dus best 11jaar GPL (+stukken dual-licensed met MIT) zijn tot aan de laatste commit.
Op dat moment is de code van jou en kun je er alle kanten mee op, tot zelfs closed source.
Echter blijf je bij MIT, dan kan iedereen zomaar jouw code alsnog onder GPL vrijgeven.
Daarnaast kan iedereen de (laatste commit-1) onder GPL forken en verder developen, mocht je een restrictievere license kiezen.

Ik vind trouwens de keuze van MIT bizar. Waarom wil je een open-source programma volledig herschrijven onder een minder restrictieve license. Het _is_ al open-source. En dan blijf je nog zitten met de open vraag of een database schema licensed is of niet. Sommigen vinden namelijk dat 'intieme kennis over de gebruikte datastructuren' automatisch leidt tot een afgeleid werk (zie bvb linken met GPL code). In hoeverre is een database schema 'intieme kennis over de datastructuur' ???

Je blijft, zelfs na een rewrite, in een dubieuze situatie achter. Mijn persoonlijk advies zou zijn: laat het GPL. Als je echt vindt dat het project de foute richting uit gaat of niet snel genoeg gaat of dat jouw bijdragen niet aangenomen worden, fork het dan.

[Loller1]

@H!GHGuY - Waarom ik het wil herschrijven en dan onder een minder restrictieve licentie wil uitbrengen? Wel, ergens is het "gewoon, omdat het kan". Maar dat is zeker niet mijn drijfveer, ik vind GPL het virus van de licenties, eens het er op zit, gaat het er maar moeilijk van af. En GPL op zich is al erg restrictief, ik wil meer kracht leggen bij de community en meer toestaan, en daar is MIT beter geschikt voor dan GPL.

Ook voor de duidelijkheid: ik praat hier over een fork. Mijn project is een fork van een fork van het project dat ik herschrijf (de eerste fork werd ook door mij gedaan, ik ontwikkel nu 2 programma's parallel, de eerste staat onder GPL en is gebaseerd op de oude codebase, de 2de, waar dit topic over gaat, moet volledig vervangend zijn).

[Gomez12]

Loller1 schreef op donderdag 13 maart 2014 @ 20:13:
Ook voor de duidelijkheid: ik praat hier over een fork. Mijn project is een fork van een fork van het project dat ik herschrijf (de eerste fork werd ook door mij gedaan, ik ontwikkel nu 2 programma's parallel, de eerste staat onder GPL en is gebaseerd op de oude codebase, de 2de, waar dit topic over gaat, moet volledig vervangend zijn).

Tja, licensie technisch heb je nu zo ongeveer een nachtmerrie gecreeerd als er iemand kwaad op je wordt.

Strikt gezien heb je straks 1 GPL versie en 1 MIT versie. En strikt gezien kan er op dat moment (als jij nieuwe functionaliteit uitbrengt voor alletwee de versies) aan jou gevraagd worden waarin je het gecode hebt.

Puur strict gezien mag jij namelijk niet een regel code in de GPL versie typen en die Ctrl-C / Ctrl-V in je MIT versie overzetten (want dan wordt je MIT werk een afgeleid werk van het GPL-project waar je niet alle rechten voor bezit of je moet je eigen code in het GPL project weer apart gaan opslaan (zodat het een project wordt waar je wel alle code van bezit) en dan dat subproject weer onderdeel maken van het grotere GPL-project), andersom mag weer wel

De kans dat je je hiervoor openstelt is miniem, maar het is wel een kans en dan mag jij gaan uitleggen hoe het nou ook alweer zat.

[drm]

Gomez12:
(...) dan bied je jouw gedeelte aan, een link naar de GPL-code en laat je het de gebruiker zelf combineren.

Dat bedoelde ik ook

[H!GHGuY]

Loller1 schreef op donderdag 13 maart 2014 @ 20:13:
@H!GHGuY - Waarom ik het wil herschrijven en dan onder een minder restrictieve licentie wil uitbrengen? Wel, ergens is het "gewoon, omdat het kan". Maar dat is zeker niet mijn drijfveer, ik vind GPL het virus van de licenties, eens het er op zit, gaat het er maar moeilijk van af. En GPL op zich is al erg restrictief, ik wil meer kracht leggen bij de community en meer toestaan, en daar is MIT beter geschikt voor dan GPL.

MIT laat ook proprietary maken van de code toe. Persoonlijk vind ik GPL net een goede licentie omdat je code free blijft.

Gomez12 schreef op donderdag 13 maart 2014 @ 21:41:
[...]

Tja, licensie technisch heb je nu zo ongeveer een nachtmerrie gecreeerd als er iemand kwaad op je wordt.

Strikt gezien heb je straks 1 GPL versie en 1 MIT versie. En strikt gezien kan er op dat moment (als jij nieuwe functionaliteit uitbrengt voor alletwee de versies) aan jou gevraagd worden waarin je het gecode hebt.

Niet waar. Voor de code die hij zelf schrijft heeft hij copyright en kan hij kiezen welke licenties erop rusten.
Het moment dat hij de code distribueert, in combinatie met GPL code, is hij echter verplicht om de code _ook_ onder GPL licentie vrij te geven. Maar niets verhindert hem om te zeggen dat zijn regels code dual-licensed is onder MIT+GPL.

Puur strict gezien mag jij namelijk niet een regel code in de GPL versie typen en die Ctrl-C / Ctrl-V in je MIT versie overzetten (want dan wordt je MIT werk een afgeleid werk van het GPL-project waar je niet alle rechten voor bezit of je moet je eigen code in het GPL project weer apart gaan opslaan (zodat het een project wordt waar je wel alle code van bezit) en dan dat subproject weer onderdeel maken van het grotere GPL-project), andersom mag weer wel

Dat mag hij wel. Hij heeft namelijk copyright op zijn code.
JIJ en IK mogen dit echter niet. Wij hebben immers geen copyright op zijn code.

[drm]

Gomez12 schreef op donderdag 13 maart 2014 @ 21:41:
Puur strict gezien mag jij namelijk niet een regel code in de GPL versie typen en die Ctrl-C / Ctrl-V in je MIT versie overzetten

H!GHGuY schreef op vrijdag 14 maart 2014 @ 20:40:
Dat mag hij wel. Hij heeft namelijk copyright op zijn code.
JIJ en IK mogen dit echter niet. Wij hebben immers geen copyright op zijn code.

Jullie begrijpen mekaar hier even verkeerd. Wat Gomez12 bedoelt is dat je niet onderdelen van de oorspronkelijke source code mag copy-pasten en die onder een nieuwe licentie mag distribueren, en daar zijn we het wel over eens.

Het copy/pasten is echter waar het al mis gaat, want het kopiëren heeft mogelijk twee dingen tot gevolg:

1. Als je vervolgens de code onder nieuwe licentie distribueert dan schend je het copyright. Dat heeft opzich niks met GPL of MIT of wat dan ook te maken, dat heeft te maken met het feit dat jij in principe geen recht hebt om de source code te kopiëren, uberhaupt.
2. De GPL staat echter het kopiëren toe, dus als je de code distribueert onder de voorwaarden waaronder de code aan jou ter beschikking is gesteld, moet je je houden aan de GPL en moet je de GPL dus meenemen in je nieuwe distributie. Het gevolg daarvan is dat de GPL het wint van elke andere licentie die jij op je eigen source code hebt, die in diezelfde distributie zitten.

[H!GHGuY]

drm schreef op vrijdag 14 maart 2014 @ 20:53:
Jullie begrijpen mekaar hier even verkeerd. Wat Gomez12 bedoelt is dat je niet onderdelen van de oorspronkelijke source code mag copy-pasten en die onder een nieuwe licentie mag distribueren, en daar zijn we het wel over eens.

Misschien denkt hij het goed maar zegt hij het fout, maar ik lees toch echt:

Puur strict gezien mag jij namelijk niet een regel code in de GPL versie typen en die Ctrl-C / Ctrl-V in je MIT versie overzetten

Maw, hij heeft het volgens mij over code die je zelf schrijft. Daar heb je copyright op en mag je mee doen wat je wil.

Het copy/pasten is echter waar het al mis gaat, want het kopiëren heeft mogelijk twee dingen tot gevolg:

1. Als je vervolgens de code onder nieuwe licentie distribueert dan schend je het copyright. Dat heeft opzich niks met GPL of MIT of wat dan ook te maken, dat heeft te maken met het feit dat jij in principe geen recht hebt om de source code te kopiëren, uberhaupt.
2. De GPL staat echter het kopiëren toe, dus als je de code distribueert onder de voorwaarden waaronder de code aan jou ter beschikking is gesteld, moet je je houden aan de GPL en moet je de GPL dus meenemen in je nieuwe distributie. Het gevolg daarvan is dat de GPL het wint van elke andere licentie die jij op je eigen source code hebt, die in diezelfde distributie zitten.

Correct, tot op het punt dat je álle GPL code hebt vervangen met je eigen code, dan kun je het gewoon licensen onder wat je ook wil.

[Freeaqingme]

H!GHGuY schreef op zaterdag 15 maart 2014 @ 22:10:
[...]

Maw, hij heeft het volgens mij over code die je zelf schrijft. Daar heb je copyright op en mag je mee doen wat je wil.

Niet als dat werk een afs dat werk een afgeleide is van een GPL werk. Dan zal je je toch echt aan de voorwaarden van de GPL moeten houden (als je het verspreidt). Copyright staat daar los van; bij het maken van een afgeleid werk van een GPL-werk ga je akkoord met de GPl-licentie, en daar staat dat nou eenmaal in..

You may not propagate or modify a covered work except as expressly provided under this License

Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License.

A “covered work” means either the unmodified Program or a work based on the Program.

[D-Raven]

Ik krijg koppijn van dit topic GPL(x) gerelateerde discussies zijn altijd moeilijk.

[H!GHGuY]

Freeaqingme schreef op zaterdag 15 maart 2014 @ 23:38:
[...]
Niet als dat werk een afs dat werk een afgeleide is van een GPL werk. Dan zal je je toch echt aan de voorwaarden van de GPL moeten houden (als je het verspreidt). Copyright staat daar los van; bij het maken van een afgeleid werk van een GPL-werk ga je akkoord met de GPl-licentie, en daar staat dat nou eenmaal in..

Correct, door het te verspreiden ben je verplicht de code _ook_ als GPL te verspreiden.
Niemand kan echter bezwaar maken dat de TS de code die hijzelf schreef (en _enkel_ die code) markeert als dual-licensed onder MIT/GPL. Maw: hij kan er mee doen wat hij wil. Echter bij de keuze om het te verspreiden in combinatie met een GPL werk, valt zijn code ook onder GPL.

[ Voor 9% gewijzigd door H!GHGuY op 16-03-2014 12:00 ]

[RayNbow]

H!GHGuY schreef op vrijdag 14 maart 2014 @ 20:40:
[...]

MIT laat ook proprietary maken van de code toe. Persoonlijk vind ik GPL net een goede licentie omdat je code free blijft.

En met MIT niet?

[H!GHGuY]

RayNbow schreef op zondag 16 maart 2014 @ 12:24:
[...]
En met MIT niet?

Right..., op populaire aanvraag, nuancering:
"Dat afgeleide werken ook free blijven"