[License-review] Approval submission for the Qlovatech License

[Lukas Atkinson]

The presented license is a weak copyleft license, broadly comparable 
with the LGPL but less focused on end user software freedom. 
Additionally, it tries to strengthen trademarks through contractual 
mechanisms, and makes a strong distinction between named copyright 
holders and unnamed contributors.

I do not think it is suitable for approval.

1. License proliferation. The terms that are OK seem somewhat redundant 
with other licenses. In particular LGPL-3.0 + additional permissions 
could achieve a similar weak copyleft effect in a much more legally 
dependable manner.

2. Confusing drafting. IANAL, but some clauses are written in a 
confusing or possibly contradictory manner. Some discussion below.

3. Potential software freedom or OSD compliance concerns, especially in 
condition 4.
3a. Asymmetry: personal vs other use.
3b. Asymmetry: implied contributor license agreement.
3c. GitHub-style forks are not practically possible.
3d. Modifications can accidentally lead to a license violation.


Details on confusing drafting
-----------------------------

* Per section 1, the license + copyright notices only have to be 
provided upon request. Without access to the license, recipients won't 
know that they have this right. Compare also the desert island test and 
OSD #7.

* In section 2, it is prohibited to “restrict the rights and/or grants 
this license gives to others” which is then explained as merely not 
suing users for exercising their rights under the license. Other 
restrictions of rights are more likely, e.g. making a service 
conditional on not exercising the rights or by imposing additional 
conditions on the license.

* In section 1, “corresponding source-code” is defined along similar 
lines as in the GPL-3.0, but excluding “larger work that this software 
is embedded in”. Yet in section 1, it is said that extracting a part of 
the covered work into a larger work would bring that larger work into 
the corresponding source code scope.

* In section 3, the statement “Each trademark must be declared by 
exactly one copyright holder” is non-sensical. Copyright and trademark 
are orthogonal.

* In section 3, it is permitted to move the list of copyright/trademark 
notices to another file. Retaining this file is not explicitly required. 
The Apache-2.0 NOTICE file is a better mechanism.

* In section 4, rules on trademark use are specified. Confusingly, 
certain exceptions are given. These exceptions seem to include 
non-trademark use and nominative use, but possibly in a way that would 
actually broaden permitted trademark use beyond the legal minimum.

* Authors do not give an explicit patent license to recipients. The only 
patent-related terms protect other copyright holders.

On to more fundamental concerns.


The license is asymmetric in two ways that require further discussion.
----------------------------------------------------------------------

(3a) The license allows modifications and copies for personal use 
without any restrictions, but applies the license terms only for other 
use. This might be a field of use restriction (OSD #6).

(3b) If an author omits or removes their copyright notice, this amounts 
to an unrestricted license agreement to the named copyright holders, 
which can unanimously relicense the software to “an open source 
license”, which is not defined more precisely. This reminds me of the 
Original Authors mechanism [1] in the “Convertible Free Software 
License”, which had previously raised concerns on this list. The given 
license may be more problematic since the given license discourages 
adding your copyright notice when making modifications, as discussed below.

[1]: https://opensource.org/LicenseReview012019


The license makes it difficult to create modified versions.
-----------------------------------------------------------

(3c) The license allows modifications under two options:

Either, the covered software is renamed to avoid infringing on any of 
the listed pseudo-trademarks. This may be fine considering OSD #4, 
though it's not realistic for software in source form in the current 
environment of open source collaboration.

Or, the software is not renamed BUT the person making the modification 
must not add a copyright notice (leading to a loss of rights as 
discussed previously, and possibly in violation of some international 
copyright laws), and must not “publicly promote this fork (except 
optionally to the listed copyright holders so that they can merge your 
changes)”. This is unreasonably restrictive and hinders the distribution 
of bug fixes to other users. Prohibition of promoting a fork might be an 
OSD #6 violation?

(3d) I consider this to be a license trap, since accidental 
non-compliance would be trivial. Am I in violation if I fork the 
software on GitHub, make a pull request to the original project, and 
tweet about my pull request? That might be considered “promoting my 
fork”. I also see no way to add a copyright notice in a contribution to 
an existing project unless the contribution is only submitted privately 
to one of the named copyright holders.


Conclusion
----------

Even if the drafting is improved with a legal review, the points 3a–3d 
would remain. I would like to see a much stronger argument for why these 
kind of terms are necessary and appropriate in the context of an open 
source license. Hand-waving into the direction of the SSPL is not a very 
convincing argument here.

My main objection is that the license offers various choices (renaming 
vs not renaming, adding a copyright notice vs not adding one), but some 
combinations lead to a disproportionate loss of rights for the 
contributor or to a license violation. This license may be convenient 
for a for a BDFL-style project, but it does not look like a good license 
for the open source community.


On 11/02/2021 08:01, Quentin Quaadgras wrote:
> Hi,
> 
> I'd like the Open Source Initiative to consider approving the Qlovatech 
> License. I have developed the license to fill a gap in the open source 
> licensing sphere for use in projects I am developing that are intended 
> to be open source and I want other developers to be able to adopt this 
> license for their projects.
> 
> International trademark protection is expensive and nothing stops a 
> large company from taking an open-source project from a small to medium 
> community and stealing the 'brand' and/or title of that project in order 
> to make money from that brand. The Qlovatech license is a strong 
> library-level copyleft license and is designed to automatically protect 
> the brand and/or title of any project it covers, whilst preserving the 
> rights of every user of the software. The author and any contributors to 
> the project can be confident that the brand they establish for their 
> project and/or the brands of any forks will not be exploited by other 
> companies or organizations for commercial gain. Everyone has the right 
> to create a new brand from their copy of the software, or to rename 
> and/or rebrand the software so that it will be protected by this license.
> 
> The Qlovatech License is attached in plaintext below and I believe that 
> it is a special-purpose open-source license that meets the OSI's 
> definition. The license fits somewhere between:
> The GNU Affero General Public License version 3 (AGPL-3.0), the Artistic 
> License 2.0, the Mozilla Public License 2.0 (MPL-2.0) and the The 
> 3-Clause BSD License (BSD3).
> 
> I am aware that existing open-source licenses can have additional terms 
> added to them in order to protect the Integrity of The Author's Source 
> Code, however I wanted an open-source license that any developer can 
> apply to their software without any license modification, so that it 
> automatically protects their brand and the brand of any derivatives of 
> that software. As far as copyleft goes, I wanted this to apply to the 
> scope of a project/library rather than the entire program or to 
> individual files. This allows the license to be a suitable choice for 
> projects who want to leave the possibility open to be ported 
> to proprietary platforms such as video-game consoles or vehicle displays 
> but still want any extended functionality or bug fixes to be released in 
> source-code form.
> 
> The license hasn't gone through any legal review yet as I do not have 
> the required funds to do so and I hope this doesn't block the approval 
> process. I think a license like this is desperately needed by the open 
> source community to address some of the issues behind why licenses such 
> as the Server Side Public License were created. Please let me know if 
> anything is unclear about the license and/or if you believe that it 
> doesn't meet the OSI's definition so that I can take steps to clarify 
> and/or adjust it.
> 
> Best Regards,
> Quentin Quaadgras
> 
> 
> 
> _______________________________________________
> The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Communication from the Open Source Initiative will be sent from an opensource.org email address.
> 
> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>