editorconfig-gedit icon indicating copy to clipboard operation
editorconfig-gedit copied to clipboard

Add it by default to gedit

Open rugk opened this issue 8 years ago • 15 comments

I have opened a bug in GNOMEs issue tracker arguing for including this plugin or a general editorconfig implementation into gedit by default.

See https://bugzilla.gnome.org/show_bug.cgi?id=772873

rugk avatar Oct 13 '16 15:10 rugk

Someone please suggest this to the debian guys to add it to the repos... (I have no idea howto do that)

TriMoon avatar Mar 27 '17 09:03 TriMoon

I've fine this in the GNOME issue I've linked. So first it had to be included in GNOME and maybe in Debian later. Including it into the packages of Debian is another good idea. However you've to suggest this directly to Debian.

rugk avatar Mar 27 '17 14:03 rugk

New issue (moved to GitLab): https://gitlab.gnome.org/GNOME/gedit/issues/220

rugk avatar Oct 01 '19 16:10 rugk

New issue (moved to GitLab): https://gitlab.gnome.org/GNOME/gedit/issues/220

Nice but i can't seem to login, maybe forgot my credentials and don't want to create a new one. Why didn't you move it to real gitlab? That way we could have used our accounts there instead of yet another account... Anyway keep up the nice work :wink:

TriMoon avatar Oct 03 '19 08:10 TriMoon

Decentralization is important, so they have their own GitLab.

And if you want, you can still re-use your account by signing in with it, via OAuth2: image

rugk avatar Oct 03 '19 19:10 rugk

GitLab is intended to be self-hosted, and self-hosted GitLab is the realest GitLab :P

xuhdev avatar Oct 03 '19 19:10 xuhdev

@editorconfig Would you be okay with licensing the code of this plugin under GPL2+? I’m looking into making a merge request of this for gedit-plugins but AFAICT everything else in there is GPL2+, so I’d reckon they’d want any additional contributions to also be GPL2+. (It shouldn’t be a problem to depend on editorconfig-core-py under a different (esp. GPL‐compatible) license as gedit-plugins allows for external dependencies.)

This would also be the case if it were to be contributed to gedit core, though it seems it would then have to be rewritten in C first, so at least for that it might make more sense to write a new plugin from scratch.

Freso avatar Aug 29 '23 13:08 Freso

@Freso There are multiple authors of this repo. Why would it be a problem if we don't relicense here? Do you mean we would have problems pulling changes back from gedit to this repo?

I think an easier solution would be to archive this repo and direct all future contributions to gedit's own repo. Would this be a problem for you?

xuhdev avatar Sep 01 '23 23:09 xuhdev

As I understand things (note: I am not a lawyer) you can’t take code released under one license and publish it under another, even if the new license is more restrictive. The code continues to be under the license it was granted under.

If I were to take this repository and "massage" it a bit to make it applicable for gedit-plugins it would still be under the current (Simplified BSD) license while everything else in gedit-plugins is GPL2+ licensed. This wouldn’t be a legal issue (as long as you kept the appropriate LICENSE file and notices together with the code) since you can include BSD licensed code in GPL’d software (hence "GPL compatible") but it could be a political/policy issue as it opens up for the licensing of the gedit-plugins repository being a lot more complex than just the "everything is GPL2+" it is now.

Freso avatar Sep 02 '23 11:09 Freso

What you can do though is ask all authors/contributors if a relicensing would be okay. If they all agree you can do it. If one does not, you de jute need to recreate their code. IANAL of course.

For how it was done in a bigger project see e.g. OpenSSL, they had this problem: https://www.openssl.org/blog/blog/2017/03/22/license/

rugk avatar Sep 05 '23 19:09 rugk

That's exactly the hassle I'm trying to avoid here.

Per my understanding, as long as you keep this original BSD license notice, you are free to take the project as it is and relicense the whole code under GPLv2. It's just that the user can trace back here and take the code under the BSD license.

(I'm not a lawyer)

xuhdev avatar Sep 07 '23 06:09 xuhdev

I agree with @xuhdev that contacting each contributor sounds like a hassle (I know I don't want to do it).

Looking at the actual code, I think that maintaining a dual license might be easiest. The license is already in most of the code files (see license, gedit2, and gedit3).

If this comment is stuck at the top of shared.py, then all of those files should be copy-pasteable into a GPL project without issue:

# Copyright (c) 2011-2012 EditorConfig Team
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
# 1. Redistributions of source code must retain the above copyright notice,
#    this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright notice,
#    this list of conditions and the following disclaimer in the documentation
#    and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.
#

As @xuhdev noted, the current license is GPL compatible so relicensing under GPL won't need consent from the current contributors as long as the current license is also maintained at the top of each file. We could even update the comment in each file to note that the code is dual licensed under the license of the gedit-plugins project as well as the below BSD 2-clause license.

If for some reason a dual license is discouraged for the gedit-plugins repo, I would be up for relicensing all of my contributions. Someone else would need to volunteer to contact each contributor (publicly if possible) and publicly record their response and replacing any code if certain contributors cannot be reached or do not consent to a relicense.

treyhunner avatar Sep 07 '23 14:09 treyhunner

I asked upstream about whether they’d accept a Python plugin for gedit-plugins at all and also indirectly made a note about the licensing “conflict”: https://gitlab.gnome.org/GNOME/gedit/-/issues/220#note_1839053

I’m willing to put in some leg work both to massage the repository for upstream acceptance and also to seek out contributor consent for relicensing… and I had a GitHub issue almost all written out starting to get these consents, but I stopped myself since I want to be sure that gedit-plugins would be interested in the Python plugin at all. No need to poke a bunch of people about this if the gedit people only want their C plugin/extension/library and are not interested in this Python one.

Also, as I noted before, I realise that there would be no legal issue in taking the Permissive BSD licensed code and checking it into a GPLv2+ repository and have new contributions to it be GPLv2+ licensed. The issue is entirely social/political, not legal[^1].

[^1]: At least up until the point where someone then tries to take the files out of gedit-plugins in the future and tries to figure out which of the code is under which license, if their project is not GPL‐compatible…

Freso avatar Sep 07 '23 16:09 Freso

Given how little Python code is in this plugin, it might make sense to rewrite it in C (the editorconfig-core-c library should be of help, just as the editorconfig-core-py library has been for this one). I'd welcome anyone who may be interested in porting the existing features to a C plugin. That might also remove the need to contact anyone about licensing.

Thank you for working with the Gedit folks on this @Freso! 💗 The prospect of EditorConfig being a built-in Gedit plugin (or even a built-in feature eventually) is exciting. 😊

treyhunner avatar Sep 07 '23 18:09 treyhunner

They want some additional things for proper native EditorConfig support though, beyond what this Python plugin does (and can do?), which is why I’m not sure whether they’d accept the Python plugin at all, even for the -plugins repository. I don’t know how much of an all‐or‐nothing mentality the gedit maintainer(s) generally have, but we’ll see. Just trying to not let my ADHD get me to do a ton of work before they’ve actually given the go‐ahead that it might at all be acceptable. :sweat_smile:

Freso avatar Sep 07 '23 19:09 Freso