QtCS2015 LicensePolicy: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(Created page with "QTCS 2015 - Qt Project Licensing Policy Discussion * 3rd Party Code ** We have a bunch and don't own it *** Identifying it can be a challenge *** Let the doc team know if the...")
 
m (Added Category)
 
Line 1: Line 1:
[[Category:QtCS2015]]
QTCS 2015 - Qt Project Licensing Policy Discussion
QTCS 2015 - Qt Project Licensing Policy Discussion



Latest revision as of 15:16, 11 June 2015

QTCS 2015 - Qt Project Licensing Policy Discussion

  • 3rd Party Code
    • We have a bunch and don't own it
      • Identifying it can be a challenge
      • Let the doc team know if there is undocumented 3rd part code!
    • Where we host a complete license things are mostly ok, but chunks that have been copy/pasted are more problematic
    • There are certain licenses that we know we don't want to use
      • We need a better process and clearer policy for tracking the situation
    • We can't use certain licenses
      • We like BSD, MIT, X11
      • Apart from these three we must be careful, the legalities are problematic for both FOSS and commercial licensing
      • Anything with an attribution clause adds a requirement for everyone
  • Contract with KDE Free Qt Foundation restricts us from doing certain things
    • We're currently talking with them about an updated agreement
    • We would like to use LGPLv3 more widely than we do now
    • KDE wants to be able to run GPLv2-only code -> conflicts with LGPLv3
      • GPLv2-only licenses are used in a lot of places without a clause that allows KDE e.V. to relicense
  • Some modules LGPLv2-only, e.g.WebKit/WebEngine
    • Try to keep these in separate modules/repos
  • Apache v2 is showing up more and more
    • This is due to Android influence and some patent protection clauses
      • Thiago: "Everything coming out now is Apache v2"
    • We use Apache v2 libraries in the Android styling code
    • Apache v2 is not compatible with LGPLv2 -> forces LGPLv3
    • Can be problematic for example with back-ends that use plugins (multimedia, sensors, etc)
      • If you happen to load a plugin that links to something licensed under Apache v2
  • Until things are clarified with KDE don't touch core modules, but entirely new functionality can be licensed with LGPLv3
  • Talked about doing something like the Linux kernel, tracking licenses of modules
    • Nobody seemed to like this, would push burden onto users
    • Difficult to maintain
    • It's turtles all the way down, you would have to mark everything, also outside Qt
  • We need policies and recommendations
    • When and where Apache v2 dependencies are OK?
      • Probably not to be used in Qt core
    • What is the recommended licensing?
      • The Qt Company would like LGPLv3, GPLv2 + Commercial for new modules
      • Through CLA things can in principle be relicensed
  • What about things other than libaries?
    • Examples are BSD-licensed so the code can be reused easily
    • It might be good to relicense the tools under GPL (without the L)
      • LGPL is increasingly seen as a free beer license and can result in misunderstandings - GPL is better understood
      • QtCreator plugin interface would still have a clause permitting plugins licensed under different license
      • KDevelop developers asked if this impacts them, consensus seemed to be no impact
  • The Qt Company has some modules that are currently closed and would like to open under GPLv3
    • Unclear whether contract with KDE Free Qt Foundation allows that or not, what is the KDE response?
    • Jokingly: "Just put it on github and pretend it came from someone else"
    • Thiago with his Intel hat on mentioned that GPL could be problematic in internal verification as people just say they use Qt, without specifying the modules individually
      • "Just don't put GPLv3 in Qt5 git"