mooooin

Moorgen!

https://twitter.com/ralf/status/1377127671017054212 So viel zum Thema Open Source Lizenzierung :face_palm:

Guten Morgen. Nun, das ist wohl jemand etwas überfordert.

Aktueller Stand ist, dass sie auf einen Schlag das gesamte Repo unter “echte” GPL gestellt haben. 🍿

ist zumindest ein GPL3-file im root inkludiert

Seit ~45 Minuten erst

Wie macht ihr das bei euch mit Audits auf Libraries?

“Das macht Infosec” 😛

Oh ganz heikles thema. Aktuell nutzen wir SonarQube bzw. DependencyCheck und irgendwelche Auditoren für Docker-Images

Aber dieses Jahr steht noch eine Zertifizierung an und das wird alles bestimmt noch ganz lustig werden. Alle installierte Software, samt Update-Zyklen muss dann auditiert werden

Für Lizenzen haben wir eine Liste, was erlaubt ist

Was macht ihr wenn, eine Lizenz eine bestimmte essenzielle lib verbietet?

Clean room?

jetzt musste ich ersmtal "Reinraum-Implementierung" nachschlagen 😄

Klingt nach FFP2-Maske 😛

ne, ist bisher eigentlich nicht vorgekommen. Wir implementieren auch im Wesentlichen eine Web-Anwendung, ohne exotische libs

Ansonsten muss man sich nach einer kommerziellen Lizenzvariante der Lib erkundigen oder schlimmstenfalls nach einer Alternative umsehen

ja, da gibt’s alles auch immer in irgendeiner kompatiblen Lizenz.

Für Web Plattformen ist ja höchstens die AGPL ja nicht so der Hammer, oder?

Manche Lizenzen sind ja untereinander nicht kompatibel.

Ich frage mich, wie das für SASS oder Webdienste aussieht. Ich redistributiere ja nicht. Aber wenn Luca “plötzlich” open source machen will, kann das ein Hindernis sein.

Außerdem bei clojure/java: dynamic linking zur Laufzeit, ach das ist doch alles etwas kompliziert.

ich blicke da irgendwie auch nicht richtig durch…

Am besten keine Software veröffentlichen und nur betreiben/nutzen. Solange kein AGPL dring ist, ist alles safe 😛

Und wo wir hier gerade bei “Testing und Lizenzen” gelandet sind. Wie stellt ihr bei euren Web Apps vorab sicher, dass das nächste Browser Release die App nicht kaputtmacht? Eine Pipeline mit den Preview-Versionen? Im Kundenprojekt klappt gerade was nicht seit der neuesten Chrome Version, die natürlich unternehmensweit ausgerollt wird, ohne die Projekte zu fragen :thinking_face:

“Lernen durch Schmerz” ist die übliche Strategie. Aber ich hatte das nur sehr selten, daß sowas vorkam.

Meistens im Bereich Browser-Security, und das is eh so ein Minenfeld

Ja, das war jetzt auch das erste Mal. Betrifft dummerweise die Auth Library

Hurra.

Kann man schlecht überbrücken 🙂

Das ist korrekt. Weitergedacht wäre also eine Pipeline mit UI Regressionstests pro Browser mit einer Preview Version zumindest keine schlechte Idee, oder?

Auf jeden fall. Ist wie immer eine Kosten/Nutzen-Abschätzung.

Vielleicht einfach als Developer auch mal mit Canary testen 🙂

Oder was auch immer die nächste Browserversion sein wird.

Ich war jetzt mehrere Jahre bequem im Backend unterwegs, von daher ist UI Testing für mich momentan eh ziemliches Neuland. Danke!

Es ist auf jedenfall etwas frustrierend. Ich hab ca. 2010 mal mobile app test automatisierung gemacht. Das was ein gruseliges Feld mit gruseliger proprietärer testsoftware 🙂

Den Teil mit Mobile Apps hab ich bisher noch mit gutem Gewissen verdrängt

Trololololo

Ich glaube, das ist sogar übersichtlicher, weil “nur” Android und iOS und ich glaube da gibt es OK-ish tool support inwzischen.

Moin! Ich komm nochmal auf euren Stammtisch von letzter Woche zurück. War das per Webcam? Welche Plattform habt ihr genutzt? (EDIT: 1-Wort-Antworten reichen dicke.)

Mal was zum Thema Clojure 😉 Ist das idiomatisch? (condp apply [x] string? "STRING" integer? "INTEGER") Ich möchte gerne die Wiederholung von x vermeiden.

hab ich so noch nie gesehen, ich find's aber cool.