Login
Newsletter
Werbung

Thema: Qt 5.11 als Betaversion erhältlich

11 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von Absahner am Sa, 3. März 2018 um 19:18 #

Für die CS Entwicklung benötigt man somit immer eine wirklich freie Lizenz, wie bsp. die BSD Lizenz.
Qt ist nicht frei genug

Ich ärgere mch auch immer warum Typen wie du nicht umsonst für mich arbeiten. Du könntest deine Arbeit ja unter die BSD-Lizenz stellen und mir dann das Geld zukommen lassen.

[
| Versenden | Drucken ]
  • 0
    Von Lizenz nicht frei genug am Sa, 3. März 2018 um 19:34 #

    Nein, du ärgerst dich nicht, du schreibst nur unqualifizierten Müll und hast in deinem Leben noch nie eigenen Code geschrieben.

    Es geht nämlich nicht um das Geld, sondern um die Freiheit.
    Das Abomodell ist das Problem, eine für die CS Entwicklung geeignete Qt Lizenz bekommt man nämlich schon jetzt, nur eben im Abo, nicht als Pauschalbetrag.
    Einem Unternehmen kann es allerdings egal sein, wenn der Kunde die Software gekauft hat, warum sollte es das Abo weiterbezahlen, nur um in der Lage zu sein Sicherheitslücken zu stopfen?
    Das macht kein unternehmen, also kriegt der User langfristig seine Sicherheitslücken.

    Richtig freie Lizenzen sind da besser und in der professionellen Softwareentwicklung auch üblich.
    Du kannst gerne mal deine Windows Partition nach der zlib Lizenz durchsuchen, du wirst dutzende Einträge finden, eben weil die zlib unter einer richtig freien Lizenz steht.
    Genauso lag die SDL 1.0 wie Blei im Regal, eben weil kein Unternehmen bei Verstand die LPGL anrührt.
    Damit gab es keine Rückmeldungen aus dem professionellen Bereich und die Entwicklung der SDL stagnierte.
    Deswegen hat man das bei der SDL 2.0 besser gemacht, man hat die Lizenz geändert und jetzt tragen professionelle Entwickler aktiv zur Entwicklung bei, da sie diese Version unter der freieren Lizenz auch nutzen.


    Lies dazu vor allem auch mal folgenden Artikel durch, als Nichtprogrammierer wirst du zwar nur die Hälfte verstehen, aber dann kannst du wenigstens nicht mehr sagen, dass du davon nichts gewusst hast:

    https://www.freebsd.org/doc/en_US.ISO8859-1/articles/bsdl-gpl/article.html

    [
    | Versenden | Drucken ]
    • 0
      Von Absahner am Sa, 3. März 2018 um 21:41 #

      Es geht nämlich nicht um das Geld, sondern um die Freiheit.

      Um die "Freiheit" die Software anderer in deinen eigenen Closed Source Projekten verwenden zu dürfen? :D

      Lies dazu vor allem auch mal folgenden Artikel durch, als Nichtprogrammierer wirst du zwar nur die Hälfte verstehen

      "Link is expiered". Das einem "Programmierer" wie dir so etwas passieren kannn, tststs...

      Eein Vorschlag: Warum setzt du dich als "Programmierer" nicht hin, programmierst etwas ähnliches wie Qt und stellst das dann unter deine geliebte "freie" BSD Lizenz? Dann können Typen wie du nach herzenslust Cloed Source Software mit deinem Code bauen?

      Oder geht's dir etwa garnicht um die "Freiheit"? ;)

      [
      | Versenden | Drucken ]
      0
      Von The_Roadrunner123 am So, 4. März 2018 um 22:12 #

      CS Proramme, die mit einer LIB, welche unter LGPL steht, gelinkt wurden, können sehr wohl andere LIBS statisch linken. Das wird nirgends verboten; auch nicht in der LGPL.

      Und Probleme mit anderen Qt-Versionen umgehe ich im schlimmsten Fall mit .bat-File, bei dem ich einfach mein Verzeichnis anspringe bzw. die Path-Variable innerhalb meiner Shellumgebung anpasse.

      Alles, was du deinem Kunden nur zur Verfügung stellen musst, ist die Möglichkeit, dass er die LIBS selbst übersetzt und zur Software packen können muss. Thatäs it.
      Ich habe bei mir in der Software ein Verweis auf die LGPL und bisher hat mich noch nie ein Kunde nach dem Source gefragt. Ich ändere auch nichts an den offiziellen Source, so dass ich genüsslich auf das Qt-Projekt "zeigen" kann.

      Macht euch das Leben nicht schwerer, als es ohnehin nicht ist. ;-)

      [
      | Versenden | Drucken ]
      • 0
        Von Zusammenfassung am Di, 6. März 2018 um 04:17 #

        Auf folgenden Kommentaren bringt es jemand auf den Punkt:

        Link 1


        Sowie hier:
        Link 2

        Die Essenz daraus ist für einen Chef einer kleinen Softwarefirma für kommerzieller Closed Source Software:

        1. Benutze nicht eine Lib die auf der LGPL aufbaut, denn das wäre ein rechtliches Minenfeld. Anwälte haben kleine Softwarefirmen nicht inhouse.

        2. Wenn es die Lib auch unter einer anderen Lizenz gibt, z.b. einer kostenpflichtigen proprietären Lizenz, dann nutze lieber die, damit ist Rechtssicherheit geschaffen.

        3. Da nun die proprietäre Lizenz erworben wird und das Projekt irgendwann fertig ist und man sich das Lizenz Abo nach der Entwicklung sparen kann, endet der Support.

        4. Nun greifen die Sicherheitslücken mit denen der Endnutzer dann leben muss.

        5. Andere Systeme werden zur Zielscheibe, weil das System des Endnutzers kompromittiert ist.

        Dabei könnte alles so einfach sein:
        A) Entweder man ändert die Lizenz zu einer wirklich freien Lizenz. Z.b. BSD, MIT usw.
        oder
        B) Man bietet die proprietäre Lizenz zu einem Pauschalbetrag an, damit die Sicherheitslücken auch noch später gestopft werden können.

        [
        | Versenden | Drucken ]
        0
        Von Zusammenfassung am Di, 6. März 2018 um 04:19 #

        Auf folgenden Kommentaren bringt es jemand auf den Punkt:

        Link 1

        Sowie hier:
        Link 2

        Die Essenz daraus ist für einen Chef einer kleinen Softwarefirma für kommerzieller Closed Source Software:

        1. Benutze nicht eine Lib die auf der LGPL aufbaut, denn das wäre ein rechtliches Minenfeld. Anwälte haben kleine Softwarefirmen nicht inhouse.

        2. Wenn es die Lib auch unter einer anderen Lizenz gibt, z.b. einer kostenpflichtigen proprietären Lizenz, dann nutze lieber die, damit ist Rechtssicherheit geschaffen.

        3. Da nun die proprietäre Lizenz erworben wird und das Projekt irgendwann fertig ist und man sich das Lizenz Abo nach der Entwicklung sparen kann, endet der Support.

        4. Nun greifen die Sicherheitslücken mit denen der Endnutzer dann leben muss.

        5. Andere Systeme werden zur Zielscheibe, weil das System des Endnutzers kompromittiert ist.

        Dabei könnte alles so einfach sein:
        A) Entweder man ändert die Lizenz zu einer wirklich freien Lizenz. Z.b. BSD, MIT usw.
        oder
        B) Man bietet die proprietäre Lizenz zu einem Pauschalbetrag an, damit die Sicherheitslücken auch noch später gestopft werden können.

        [
        | Versenden | Drucken ]
    0
    Von Lizenz nicht frei genug am Sa, 3. März 2018 um 19:37 #

    Beschwere dich bitte auch nicht, wenn du mehr Spam E-Mails bekommst und deine Server ständig von Botnetzen angegriffen werden

    Du bist schließlich gegen das Stopfen von Sicherheitslücken und für die Verbreitung von Software mit solchen Lücken.

    [
    | Versenden | Drucken ]
    0
    Von Lizenz nicht frei genug am Sa, 3. März 2018 um 19:39 #

    Auch solltest du dich nicht beschweren, wenn die Entwickler bei Windows bleiben und für dein Linux gar nichts entwickeln.
    Denn die GUI APIs bei Windows kann man mit ausreichender Freiheit nutzen und jederzeit Sicherheitslücken der eigenen Software stopfen, eben weil man die Lizenz für die API nicht teuer abonnieren muss.

    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung