[License-review] Approval submission for the Qlovatech License

Thu Feb 11 16:43:53 UTC 2021

Agree with observations below that this is a poorly written license and really does need someone with legal drafting skills to be involved (which I tend to think ought to be a requirement of submission to license-review, given how often this issue comes up). I'm not sure I even agree this is weak copyleft but the drafting is so opaque it's hard to say; this is potentially stronger copyleft than AGPL.

I also find the enforcement clause (after paragraph 4) problematic, as it appears to be assigning right to enforce (and collect damages) to any copyright holder on behalf of all copyright holders. I think we've seen how problematic that can be when a copyright holder engages in enforcement activities in contravention of the desire of the majority of other copyright holders. Also, it doesn't address how any damages would be allocated.

> -----Original Message-----
> From: License-review <license-review-bounces at lists.opensource.org> On
> Behalf Of Lukas Atkinson
> Sent: Thursday, February 11, 2021 5:40 AM
> To: license-review at lists.opensource.org
> Subject: Re: [License-review] Approval submission for the Qlovatech License
> 
> 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
> >
> 
> _______________________________________________
> 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