mboost-dp1
What motivates open source software contributors?
Ikke rigtig overraskende, men alligevel fint at have noget statestik på det.
Jeg synes dog det er fjollet at de skriver FOSS så mange gange. De fleste i dag ser ikke på om noget er FOSS eller "kun" OSS. Der er (heldigvis) meget få GNU-like aktivister tilbage, og de fleste fokusere på slutresultatet.
MIT licensen i sig selv er vel 50% af alting på GitHub. Der er ingen som vil røre ved GPL kode mere.
Specielt os som har jobs. At kontributere til GPL kode er et potentialt mareridt som ingen har lyst til.
Jeg synes dog det er fjollet at de skriver FOSS så mange gange. De fleste i dag ser ikke på om noget er FOSS eller "kun" OSS. Der er (heldigvis) meget få GNU-like aktivister tilbage, og de fleste fokusere på slutresultatet.
MIT licensen i sig selv er vel 50% af alting på GitHub. Der er ingen som vil røre ved GPL kode mere.
Specielt os som har jobs. At kontributere til GPL kode er et potentialt mareridt som ingen har lyst til.
#5
Apple som virksomhed ja. Apple udviklere som folk der skriver open source Swift/ObjC vælger typisk MIT.
Og de fleste nye Open Source projekter nu om dage er MIT. Det er kun de gamle projekter der bruger GPL.
Hvilket måske er de mindst relevante projekter for open source, når man snakker om hvad der motivere udviklerer.
De projekter er jo udviklet af folk der har det som fuldtidsarbejde (og typisk ret velbetalte jobs, Google's top Android udviklere tjener nok på den pæne side af $300-400k)
Apple som virksomhed ja. Apple udviklere som folk der skriver open source Swift/ObjC vælger typisk MIT.
Og de fleste nye Open Source projekter nu om dage er MIT. Det er kun de gamle projekter der bruger GPL.
Linux inkl. Android, MySQL og GCC er alle under GPL
Hvilket måske er de mindst relevante projekter for open source, når man snakker om hvad der motivere udviklerer.
De projekter er jo udviklet af folk der har det som fuldtidsarbejde (og typisk ret velbetalte jobs, Google's top Android udviklere tjener nok på den pæne side af $300-400k)
#licensvalg
Statistik resultater varierer noget efter hvor man kigger.
2015 Github
https://github.blog/2015-03-09-open-source-license...
MIT 45%
GPL 13% + 9%
Apache 11%
BSD 5% + 2%
LGPL 1%
2016/2019 Black Duck
https://www.synopsys.com/blogs/software-security/t...
MIT 32%
GPL 18% + 7%
Apache 14%
BSD 6% + 1%
LGPL 4% + 2%
2020 WhiteSource
https://resources.whitesourcesoftware.com/blog-whi...
Apache 28%
MIT 26%
GPL 10% + 10%
BSD 5% + 2%
LGPL 4% + 1%
Statistik resultater varierer noget efter hvor man kigger.
2015 Github
https://github.blog/2015-03-09-open-source-license...
MIT 45%
GPL 13% + 9%
Apache 11%
BSD 5% + 2%
LGPL 1%
2016/2019 Black Duck
https://www.synopsys.com/blogs/software-security/t...
MIT 32%
GPL 18% + 7%
Apache 14%
BSD 6% + 1%
LGPL 4% + 2%
2020 WhiteSource
https://resources.whitesourcesoftware.com/blog-whi...
Apache 28%
MIT 26%
GPL 10% + 10%
BSD 5% + 2%
LGPL 4% + 1%
Claus Jørgensen (2) skrev:
Der er ingen som vil røre ved GPL kode mere.
Specielt os som har jobs. At kontributere til GPL kode er et potentialt mareridt som ingen har lyst til.
Her må være en god lejlighed til at gentage det basale for kommerciel brug:
strong copy left (bl.a. GPL) = hele programmet skal være under GPL => OK for standalone programmer, ikke OK for biblioteker
weak copyleft (bl.a. LGPL og GPL med linking exception) = open source for sig og resten for sig - open source inklsuive ændringer skal forblive open source - resten påvirkes ikke => OK hvis man ikke vil ændre koden, måske OK måske ikke OK hvis man vil ændre koden
permissive (MIT, Apache, BSD etc.) => gør som du vil bare du ikke sagsøger for mangler => OK
Bidrag er noget helt andet.
Store/forsigtige open source projekter vil sikre sig juridisk at en bidragyders bidrag ikke er ejet af det firma som bidragsyder er ansat hos. Ofte skal bidragsyder og/eller firmaet underskrive en erklæring.
Om licensen er strong copyleft, weak copyleft eller permissive betyder mindre.
Eksempler:
https://apache.org/licenses/contributor-agreements...
https://cla.developers.google.com/about/google-ind...
https://www.python.org/psf/contrib/contrib-form/
https://cla.dotnetfoundation.org/
#11
Du bruger ikke meget open source (kode) på arbejde hvis alt du kan tænke på er store hele-løsninger som dem du nævner... Git, Linux og MySQL er ikke særlig relevant når vi snakker Open Source licenser for KODE.
Jeg snakker om mindre biblioteker, brugerflade komponenter, etc. De meste open source er den slags komponenter.
Størstedelen af NuGet, NPM, CocoaPods, RubyGems, etc. er den slags komponenter, og de repræsentere langt størstedelen af open source som professionelle udviklere arbejder med fra dag til dag.
Du bruger ikke meget open source (kode) på arbejde hvis alt du kan tænke på er store hele-løsninger som dem du nævner... Git, Linux og MySQL er ikke særlig relevant når vi snakker Open Source licenser for KODE.
Jeg snakker om mindre biblioteker, brugerflade komponenter, etc. De meste open source er den slags komponenter.
Størstedelen af NuGet, NPM, CocoaPods, RubyGems, etc. er den slags komponenter, og de repræsentere langt størstedelen af open source som professionelle udviklere arbejder med fra dag til dag.
#12
Der er næsten ingen biblioteker/komponenter under GPL. Fordi GPL ikke duer til biblioteker/komponenter men kun til standalone programmer (medmindre ens program er under GPL).
Men der er masser af GPL standalone programmer som bliver brugt.
Biblioteker under GPL er ekstremt sjældne. Jeg kan umiddelbart kun huske en ren GPL (GNU readline) og et par med dual license GPL og commercial (MySQL client libs*, BerkeleyDB) - og det sidste er mere en forretnings-model.
*) MySQL client libs er GPL med FOSS exception, hvilket er vigtigt for nogen, men ikke så vigtigt i relation til kommercielle licenser.
Den berygtede virale effekt af strong copyleft som GPL er ægte nok, men det er et fænomen med meget lille praktisk betydning. Fordi GPL stort set aldrig bruges til open source, hvor det er relevant**.
**) For ærlig brug såsom biblioteker - GPL fanger en del ripoffs af standalone programmer.
For biblioteker eksisterer der LGPL (og GPL med linking exception, hvilket er stort set det samme).
Og den bruges en del til biblioteker: glibc, GTK, Qt, MariaDB client libs ***, Hibernate/NHibernate.
***) Ja - MariaDB har nye clients libs med en mere business venlig licens.
At konstatere at der ikke er mange biblioteker under GPL er sandt, men sandt på samme måde som at der ikke er mange lastbiler på cykel-stierne.
Der er næsten ingen biblioteker/komponenter under GPL. Fordi GPL ikke duer til biblioteker/komponenter men kun til standalone programmer (medmindre ens program er under GPL).
Men der er masser af GPL standalone programmer som bliver brugt.
Biblioteker under GPL er ekstremt sjældne. Jeg kan umiddelbart kun huske en ren GPL (GNU readline) og et par med dual license GPL og commercial (MySQL client libs*, BerkeleyDB) - og det sidste er mere en forretnings-model.
*) MySQL client libs er GPL med FOSS exception, hvilket er vigtigt for nogen, men ikke så vigtigt i relation til kommercielle licenser.
Den berygtede virale effekt af strong copyleft som GPL er ægte nok, men det er et fænomen med meget lille praktisk betydning. Fordi GPL stort set aldrig bruges til open source, hvor det er relevant**.
**) For ærlig brug såsom biblioteker - GPL fanger en del ripoffs af standalone programmer.
For biblioteker eksisterer der LGPL (og GPL med linking exception, hvilket er stort set det samme).
Og den bruges en del til biblioteker: glibc, GTK, Qt, MariaDB client libs ***, Hibernate/NHibernate.
***) Ja - MariaDB har nye clients libs med en mere business venlig licens.
At konstatere at der ikke er mange biblioteker under GPL er sandt, men sandt på samme måde som at der ikke er mange lastbiler på cykel-stierne.
Ja, i dag. Men licenser som MIT blev jo netop populære _fordi_ at GPL var elendigt til formålet.arne_v (13) skrev:Der er næsten ingen biblioteker/komponenter under GPL. Fordi GPL ikke duer til biblioteker/komponenter men kun til standalone programmer (medmindre ens program er under GPL).
Og der findes stadigvæk folk som licenser deres biblioteker under GPL - heldigvis meget få i dag i forhold til for 10 år siden.
MIT kræver heller ikke attribution, hvilket er praktisk når man levere software direkte til slutbrugerene.
Men jeg gætter på dette her ikke er problemstillinger du skal løse på din arbejdsplads :p
Claus Jørgensen (14) skrev:Ja, i dag. Men licenser som MIT blev jo netop populære _fordi_ at GPL var elendigt til formålet.arne_v (13) skrev:Der er næsten ingen biblioteker/komponenter under GPL. Fordi GPL ikke duer til biblioteker/komponenter men kun til standalone programmer (medmindre ens program er under GPL).
GPL synes at fungere fint til dets formål. Mange projekter stortrives med licensen.
Claus Jørgensen (14) skrev:
Og der findes stadigvæk folk som licenser deres biblioteker under GPL - heldigvis meget få i dag i forhold til for 10 år siden.
GPL var ikke almindelig til biblioteker for 10 år siden. Og heller ikke for 25 år siden.
Der er en grund til at LGPL eksisterer.
Oprindeligt stod LGPL for Library General Public License. Det var først senere at den blev omdøbt til Lesser General Public License.
Det var den licens som GNU tiltænkte for biblioteker.
(de har så sidenhen ændret præferance fra LGPL til GPL med linking exception)
Claus Jørgensen (14) skrev:
MIT kræver heller ikke attribution, hvilket er praktisk når man levere software direkte til slutbrugerene.
Hvis det er en mobil app, så kunne en help about med en liste af alt open source software godt blive lidt lang.
Ja. Vi kan heldigvis autogenerate dem....arne_v (15) skrev:Hvis det er en mobil app, så kunne en help about med en liste af alt open source software godt blive lidt lang.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund