Kiezen van een FOSS-licentie voor een library: MPL & GNU

[Basje]

Omdat er extra tijd is om hobbyprojecten op te zetten wil ik aan een nieuw project beginnen en dat gelijk open source maken. Als developer maak ik veel gebruik van open source projecten en zou ik het liefst een zo copyleft mogelijke licentie kiezen. De reden dat ik dat waarschijnlijk toch niet ga doen is omdat ik het eventueel ook in (gesloten) software van opdrachtgevers wil kunnen gebruiken. Het nadeel van minder copyleft is dan dat het dan juist weer moeilijker wordt om het in bijvoorbeeld (L)GPL-software te gebruiken. Inmiddels zit ik in een vicieuze cirkel qua redenatie, dus wellicht kunnen jullie helpen bij het gedachtenproces.

Mijn redenatie is in het kort als volgt:

• Deze library gaat geschreven worden in C# (.NET Standard).
• LGPL 3 staat het toe om in gesloten software de library dynamisch te linken als een DLL. Dat is gunstig, want dan kan het closed source programma gedistribueerd worden zonder problemen te veroorzaken, maar moeten aanpassingen aan de library wel openbaar worden gemaakt onder de LGPL-licentie.
• .NET is een beweging aan het maken naar single-binary deployments, wat maakt dat closed source programma's bij die manier van distribueren niet gebruik kunnen maken van de library.
• MPL 2 is een veel zwakkere copyleft licentie die een single-binary distributie wel toestaat.
• (L)GPL-projecten kunnen nu lastiger mijn code gebruiken?

Vanaf hier komt het probleem. Ik loop nu met de volgende vragen:

• Is MPL2 goed genoeg, of kan ik beter ook een (L)GPL opnemen in een dual license? Volgens mij kan MPL2-code zonder problemen worden opgenomen in GNU-projecten, en dat wil ik ook, maar is dit voldoende?
• Als ik kies voor dual license, hoe gaat GitHub om met dual license code? Ik kan dat niet echt terugvinden. (Bij een enkele license wordt dat netjes gemeld en kan je er op filteren.)

Wat zouden jullie doen? Welke overwegingen mis ik, of maak ik het juist complexer dan het is? Hoe zijn jullie ervaringen met deze en andere licenties bij het maken van open source software?

Update: Ik probeer dus deze belangen te balanceren:

1. Zo copyleft mogelijk (wijzigingen moeten gepubliceerd worden)
2. Bruikbaar in single-binary closed (proprietary) software
3. Zo laagdrempelig mogelijk te gebruiken in GPL-software

[ Voor 6% gewijzigd door Basje op 27-05-2020 14:09 . Reden: Afweging van belangen toegevoegd ]

[RobIII]

Basje schreef op woensdag 27 mei 2020 @ 13:56:
Als ik kies voor dual license, hoe gaat GitHub om met dual license code?

Kun je daar iets op uitwijden? Wat bedoel je hier met "omgaan met..."? Puur of je er op kunt filteren?

Ikzelf doe eigenlijk alles MIT, maar ik heb er niet zo'n moeite als wijzigingen/verbeteringen niet gedeeld worden. Heel begrijpelijk als jij dat wel belangrijk vindt hoor.

[ Voor 3% gewijzigd door RobIII op 27-05-2020 14:22 ]

[Basje]

RobIII schreef op woensdag 27 mei 2020 @ 14:20:
Kun je daar iets op uitwijden? Wat bedoel je hier met "omgaan met..."? Puur of je er op kunt filteren?

Als je zoekt op GitHub dan komt de licentie er gelijk bij te staan. Dat is wel zo duidelijk. En je kunt dus inderdaad filteren bij Advanced Search. Niet dat dit nu de doorslag gaat geven in mijn overwegingen, maar ik zou graag zoveel mogelijk gebruik maken van de functies die GitHub biedt, inclusief het gevonden kunnen worden op licentie.

RobIII schreef op woensdag 27 mei 2020 @ 14:20:
Ikzelf doe eigenlijk alles MIT, maar ik heb er niet zo'n moeite als wijzigingen/verbeteringen niet gedeeld worden.

Ja, snap ik. Het is alleen dat ik soms het idee krijg dat "het internet" langzaam de verkeerde kant op beweegt en soms wil ik dan een klein beetje bijdragen aan "een betere wereld". Wellicht een beetje naïef om te denken dat mijn library ook maar iets verschil gaat maken, maar wil in ieder geval bewust hierover nadenken voordat ik een licentie kies.

[DJMaze]

Basje schreef op woensdag 27 mei 2020 @ 14:33:
Ja, snap ik. Het is alleen dat ik soms het idee krijg dat "het internet" langzaam de verkeerde kant op beweegt en soms wil ik dan een klein beetje bijdragen aan "een betere wereld". Wellicht een beetje naïef om te denken dat mijn library ook maar iets verschil gaat maken, maar wil in ieder geval bewust hierover nadenken voordat ik een licentie kies.

Kijk hier dan ook eens naar: https://creativecommons.org/licenses/by-sa/4.0/

[Daedalus]

DJMaze schreef op woensdag 27 mei 2020 @ 14:48:
[...]

Kijk hier dan ook eens naar: https://creativecommons.org/licenses/by-sa/4.0/

Creative Commons is niet bedoeld voor software

[DJMaze]

Daedalus schreef op woensdag 27 mei 2020 @ 16:04:
Creative Commons is niet bedoeld voor software

Definieer software...
Als je broncode vrij geeft, dan is het net als tekst uit een boek. Het werkt pas zodra je het compileert.
Een DLL is gecompileerde code.
Vaak toont software grafische elementen en tekst, en dat is niet de software/firmware maar een onderdeel van...

En zo definieert iedereen het anders en heb je niet genoeg aan één licentie waar alles onder valt.

[Creepy]

Sorry DJMaze, maar als je kijkt waar Daedalus naar linkt dan kan je echt niet serieus voorstellen om dit als licentie te gebruiken voor een library.

Unlike software-specific licenses, CC licenses do not contain specific terms about the distribution of source code, which is often important to ensuring the free reuse and modifiability of software. Many software licenses also address patent rights, which are important to software but may not be applicable to other copyrightable works. Additionally, our licenses are currently not compatible with the major software licenses, so it would be difficult to integrate CC-licensed work with other free software.

En dat voldoet dus in elk geval niet aan punten 1 en 3 die ms.hamar noemt.

[eamelink]

Wil je nou dat jíj het alleen in een closed source product kan gebruiken, of iedereen?

Als dat eerste je doel is, dan is het wellicht simpeler dan je denkt; als jij de code hebt geschreven mag je ermee doen wat je wilt. Je kunt het dus publiceren onder een OSS licentie, en zelf ook nog in closed source software gebruiken.

Iets lastiger wordt het als je bijdragen van anderen verwacht; die mag jij natuurlijk niet zomaar in jouw closed source software verwerken. Om dat op te lossen is een Contributor License Agreement de gebruikelijke weg; je vraagt iedereen die bijdraagt om jou het recht te geven te doen wat je wilt met die code.

Als je wilt dat iedereen je library in een closed source product mag gebruiken, dan kan een een willekeurige MIT of Apache licentie pakken lijkt me.

[Basje]

DJMaze schreef op woensdag 27 mei 2020 @ 14:48:
Kijk hier dan ook eens naar: https://creativecommons.org/licenses/by-sa/4.0/

Bedankt voor de link! Na wat verder zoeken en doorklikken vond ik CC BY-SA 4.0 now one-way compatible with GPLv3 en begon het dus serieus te overwegen.

Daedalus schreef op woensdag 27 mei 2020 @ 16:04:
Creative Commons is niet bedoeld voor software

Dit is dan voor mij helaas een breekpunt. Ik ben geen jurist, maar als de makers zelf aangeven dat het eigenlijk niet voor software is bedoeld, wie ben ik dan om dat te betwisten? Op dat punt sluit ik me dus aan bij Creepy. Hier wordt dat nog eens extra benadrukt:

Version 4.0 of CC’s Attribution-ShareAlike (BY-SA) license is one-way compatible with the GNU General Public License version 3.0 (GPLv3). This compatibility mechanism is designed for situations in which content is integrated into software code in a way that makes it difficult or impossible to distinguish the two. There are special considerations required before using this compatibility mechanism.

Blijkbaar gaat dat dus over niet-software (wat daar dan ook onder verstaan wordt) die gecombineerd kan worden met GPLv3-software.

Hoe dan ook, het bracht me wel op een idee. Blijkbaar kunnen licenses "one-way compatible" zijn met GPLv3, dus daar is vast een lijst van. Inderdaad, GNU houdt zelf een lijst bij met geschikte licenties. Daarop staan bekende namen als Apache License 2.0 maar dus ook Mozilla Public License (MPL) version 2.0! Opvallend is dat MIT van de lijst van GNU lijkt te ontbreken. Wel vond ik dit onder de X11 License:

Some people call this license “the MIT License,” but that term is misleading, since MIT has used many licenses for software. It is also ambiguous, since the same people also call the Expat license “the MIT License,” failing to distinguish them. We recommend not using the term “MIT License.”

Nu geloof ik niet dat dat helemaal eerlijk is naar de MIT License toe, want ik denk dat de meeste mensen er dezelfde licentie onder verstaan en als je de tekst in je repo opneemt is er ook geen onduidelijkheid over, maar aangezien MPLv2 meer copyleft is dan MIT en Apache is dat de voorlopige kandidaat-licentie voor mijn nieuwe library.

Uiteraard sta ik open voor andere standpunten.

eamelink schreef op woensdag 27 mei 2020 @ 23:44:
Wil je nou dat jíj het alleen in een closed source product kan gebruiken, of iedereen?

Goede vraag, maar ik bedoelde eigenlijk iedereen die de library wil gebruiken. Het wordt al snel een ingewikkeld verhaal als je het alleen zelf onder andere voorwaarden wil gebruiken maar wel PR's gaat accepteren van anderen.

[ Voor 7% gewijzigd door Basje op 28-05-2020 07:52 . Reden: Reactie op eamelinks vraag toegevoegd ]

[DJMaze]

@Basje @Creepy het klopt dat de CC niet aansluit bij zijn wensen.
Hij heeft nu wel uitgezocht hoe de hele wirwar zit.

Ik gebruik zelf vaak GPL en CDDL.
Bij de CDDL (gebaseerd op MPL) wordt nog wel steeds betwist of het compatible is met GPLv3.