[kde-community] licence policy updates

[Thomas Pfeiffer]

On 16.02.2014 22:14, Michael Pyne wrote:
> On Sun, February 16, 2014 19:06:07 Lydia Pintscher wrote:
>> On Sat, Feb 15, 2014 at 2:03 AM, Michael Pyne <mpyne at kde.org> wrote:
>>> Perhaps something similar exists online as well.
>>
>> http://choosealicense.com/ (developed by github after people were
>> annoyed that so much unlicensed code is hosted there)
>> https://creativecommons.org/choose/
>
> Thanks for the advice.
>
> I've prepared a rough draft of something that could probably be beaten into
> shape by a few of us.
>
> This is literally a *rough* draft, I've done just a little bit of research by
> looking at the FLA, FRP, and Licensing Policy pages, so it's certainly
> possible I'm not accurately stating a KDE position right.
>
> Should we get it smoothed out though it could probably be posted to
> community.kde.org (or similar) and referenced in our "new contributor"
> literature (assuming we have some! ;)
>
> Regards,
>   - Michael Pyne
>
> --8<------
>
> # How to pick a copyright license for KDE source
>
> ## Purpose
>
> This guide is intended for the use of KDE contributors in selecting a license
> for new
> software in a way that helps the contributor meet their individual goals for
> the
> software, while keeping with the spirit of the KDE Project's purpose "... to
> promote the free exchange of knowledge and equality of opportunity in
> accessing software as well as education, science and research." (quoted from
> [the articles of association](http://ev.kde.org/whatiskdeev.php) of the KDE
> e.V.).
>
> The selection of an appropriate license is one of the more important decisions
> that a contributor can make with regard to the success of the software
> project, the KDE Project itself, and even the wider ecosystem of Free and
> open-source Software.
>
> Additionally, license selection is one of the first tasks that the
> contributor must complete, and becomes increasingly difficult to change (if
> needed) as more people contribute to the software in question.
>
> What that in mind, the KDE Project has prepared this guide to aid contributors
> in this process.
>
> ## KDE License Requirements
>
> KDE maintains a [list of acceptable software
> licenses](http://techbase.kde.org/Policies/Licensing_Policy), which you should
> briefly review before reading this guide.
>
> Of particular note:
>
> * The difference in emphasis on license requirements for software which is
>    intended to form a "library with a public API [Application Programming
>    Interface]" and for all other software (such as applications, simple
>    widgets, etc.).
> * The availability of license options that may change with approval of the
>    membership of the KDE e.V. (in other words, an agreement on your part, if
>    you wish to permit it, to allow the KDE e.V. to relicense your software
>    under certain terms).
> * The possibility of later adoption of your software into Qt (particularly for
>    library code).
> * The possibility of later adoption of your software into Qt by someone other
>    than yourself (which [requires](http://qt-project.org/legal.html) your
>    software use LGPL *v2.1* as of this writing).
>
> The list of acceptable licenses for KDE software is chosen in order to meet
> multiple (and sometimes conflicting) goals:
>
> 1. Above all, maintaining a source base that guarantees the KDE Project's
>     ability to deliver on its goal of developing software that can be freely
>     examined, modified, and redistributed.
> 2. Maximizing the ability of individual contributors to make contributions to
>     the KDE Project in a way that satisfies the contributor's concerns
>     regarding the eventual use of their software.
> 3. Enabling cooperation and source code sharing within the wider community to
>     the maximum extent possible, to ensure the overall health of Free and
>     open-source Software.
> 4. Minimizing the license compliance workload of our downstream packagers, to
>     the extent possible.
> 5. Maintaining the health of software essential to the overall KDE Project
>     even when the current copyright owner is unavailable.
>
> ## Contributor Viewpoint
>
> Of course, the individual contributor has views and ideas of their own
> regarding the proper use and licensing of their contribution. Many types of
> contributors have made important contributions to the Project.
>
> * Some contributors care only that their software is as widely available as
>    possible, and are willing to license permissively to make this happen.
> * Some contributors are concerned that their contribution is not adopted by a
>    business and "taken proprietary", and use a "copyleft" license to achieve
>    this.
> * Some contributors share the same concern as above, with the exception of the
>    Qt Project's commercial usage, and use "copyleft" licenses with specific
>    exemptions for usage with the Qt libraries.
> * Some contributors want to ensure that their software is automatically
>    protected from future threats to Free or open-source Software by
>    pre-emptively granting licenses for future versions of the GNU General
>    Public License (GPL) and/or Lesser General Public License (LGPL).
> * Some contributors want to ensure that their software can be used by the KDE
>    Project in the future even if conditions change, and assign copyright to the
>    KDE e.V. via the [Fiduciary License
>    Agreement](http://ev.kde.org/rules/fla.php) process.
> * Some contributors do not wish to give a license to an unknown future license
>    that may contain new provisions they don't support, and limit their license
>    to existing GPL and/or LGPL versions. They might also refuse to agree to the
>    KDE e.V. FLA (which is also permissible).
> * Some contributors wish to ensure that their software can be easily linked
>    with software under different (but still Free or open) licenses, and use one
>    specific license version while allowing linking to other specific license
>    versions.
> * Others do not wish to weaken the value of their chosen license by offering
>    linking exceptions to others.
>
> The way you feel about these points and others might also depend on the
> importance of the software project in question. A simple "one-off" script
> might not warrant any special protection in your mind whereas an application
> that performs a vital task might require a strong license.
>
> ## Advice
>
> These are inherently political decisions and the KDE Project cannot tell you
> "which way to vote".
>
> We can recommend you visit the [Choose a License](http://choosealicense.com/)
> advisor developed by [GitHub](http://www.github.com/) to aid software
> developers in selecting a license, after considering the viewpoints listed
> above.
>
> If your contribution comes in other forms you might also consider the
> [Creative Commons Choose a License](https://creativecommons.org/choose/)
> advisor.
>
> Remember that your choice should still conform to the KDE Licensing Policy for
> the type of contribution you are making.
>
> ## KDE's Position
>
> License selection is at the choice of the individual contributor, within the
> options determined under the Licensing Policy. We recommend also using the
> Fiduciary Licensing Agreement process to give the KDE e.V. the right to
> relicense in the event it becomes necessary, and also to give your
> contribution strong legal protection against licensing violations.
>
> Whatever license is chosen should be clear and unambiguous, and in accordance
> with the Licensing Policy.

Thank you for initiating this, and I really like the draft!
The only thing that I think should be clarified is that a new 
contributor to an existing project within KDE should talk to that 
project's maintainer before choosing a license for her specific 
contributions, as I don't think maintainers would like to have the code 
within their projects to be under a wild mix of licenses.

Cheers,
Thomas