#5 · closed · 11 comments
Bevor die ganze Gruppe loslegt und es kompliziert wird sollten wir uns eigentlich eine Lizenz für die Arbeit hier überlegen um den Code auch rechtlich (anstatt nur praktisch) offen zu machen. Ich kenn mich nur oberflächlich aus, aber zum Beispiel: - [GPL-3](https://tldrlegal.com/license/gnu-general-public-license-v3-(gpl-3)) - [MIT](https://tldrlegal.com/license/mit-license) Der Einfachheit halber würde ich MIT vorschlagen. @Casputin, @mschnetzer, Meinungen?
Servus, also MIT ergibt irgendwie mehr Sinn. Außer wir wollen unbedingt sublicensing verhindern. Dafür sehe ich aber nicht direkt einen Grund.
Erstmal danke für den eigenständigen Einsatz, auch das mit den Rechten mitzubedenken. Für mich ist es noch eine offene Frage, ob wir das Repo und den Code frei verfügbar machen. Aber vielleicht müssen wir das unterscheiden: - Den Code für die Seminararbeiten und die Wiki-Artikel hätte ich aktuell nicht öffentlich gemacht. Da war das Repo nur für die Kooperation gedacht. - Beim Code für das Shiny-Tool kann man sich schon überlegen, den auch öffentlich zu machen. Ich kenn mich bei Lizenzen leider auch nicht aus, aber das MIT klingt vernünftig. Habt ihr (v.a. bzgl. Punkt 1) eine andere Einschätzung?
Die Lizenzfrage und die öffentliche Verfügbarkeit muss man getrennt sehen. - Ein öffentliches Repo wäre bezüglich Transparenz der Ergebnisse interessant, aber nachdem die Arbeit getan ist nicht notwendig. - Eine Lizenz ist theoretisch schon für Zusammenarbeit (bzw. falls jemand aus der LV Code von hier woanders anwenden will) notwendig. Sobald einige Leute mitgearbeitet haben wird es außerdem umständlich noch eine anzuwenden. Mit einer MIT oder BSD Lizenz hätte man da maximale Freiheit den Code weiterzuverwenden, mit GPL-3 könnte man den Code von hier nur in offenen Projekten verwenden. Siehe [Pick a License](https://blog.codinghorror.com/pick-a-license-any-license/), [Licensing & GitHub](https://opensource.com/law/13/8/github-poss-licensing)
OK, danke für den Hinweis. Bitte noch @stefanhumer zum Projekt hinzufügen - er hat sich gerade einen Account gemacht. Dann kann er auch noch seine Meinung zur Lizenz kundtun.
Ich überlege nun seit einiger Zeit, ich tu mir nicht ganz leicht. Alles was wir hier machen (Code + Seminararbeiten) ist für jeden einsehbar, dh. öffentlich in einem gewissen Sinn. Wenn wir das nicht wollen sollten wir uns noch schnell überlegen ob die Plattform die richtige ist. Die Lizenz würde sich auf das ganze Repo beziehen, ist das korrekt? Dh. wir müssten auch aufpassen was an sonstigen Dokumenten/Daten/Literatur hochgeladen wird.
Man könnte das Repository jetzt oder später privat machen, dann ist der Code nur mehr für Eingeladene einsehbar. Mit sonstigen Dokumenten und Daten müssen wir sowieso aufpassen, aber da wäre unsere Lizenz nicht gültig (da wir das Recht eine darauf zu vergeben nicht haben). Im Endeffekt sollte dieses Repository ja auch nur Code, Reports und bearbeitete Daten beinhalten. Fürs Erste können wir auch den Daten-Ordner komplett zu `.gitignore` hinzufügen. Momentan werden alles PDFs auch ignoriert.
Private repo setzt zumindest bei github einen paid plan voraus. Wobei habe das hier gerade gefunden: https://classroom.github.com/ Hat da vielleicht jemand schon Erfahrung?
Als Student oder akademische Einrichtung bekommt man auch private repos. Mit Classroom hab ich noch nichts gemacht.
Ich finde den Vorschlag von @nk027 sehr gut: Im Repo nur Code und Seminararbeit, keine Daten (brauchen wir dazu überhaupt einen Ordner, die Daten sollten ohnehin gecached werden [cache nicht commiten]) und keine Literatur; das Ganze mit der MIT Lizenz. Auf den ersten Blick bietet Classroom Github auch nur einen Discount auf private Repos. Ganz andere Frage: Könnt ihr, @nk027 und @Casputin, übermorgen kurz eure bisherige Arbeit vorstellen. Es ist vorerst unser letzter Termin bevor die Gruppen mit der Arbeit beginnen. Bitte kurz das Markdown-Template vorstellen und was man beachten sollte. Wir werden dann gemeinsam in der Klasse (das bereite ich vor) das Repo testweise forken, etwas verändern und dann einen pull request machen. Ist das in Ordnung?
Ja können wir machen - ich hoffe das Template und die Struktur passt so? Den `data` Ordner würde ich lassen damit Daten in lokalen Repos konsistent gespeichert werden (und damit man sie mit `.gitignore` konsequent ignorieren kann).
Closed in 65fa9102c531c06ec563ccc5ac9688d1d6a9cf5b