Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add it by default to gedit #12

Open
rugk opened this issue Oct 13, 2016 · 15 comments
Open

Add it by default to gedit #12

rugk opened this issue Oct 13, 2016 · 15 comments

Comments

@rugk
Copy link

rugk commented Oct 13, 2016

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

@TriMoon
Copy link

TriMoon commented Mar 27, 2017

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

@rugk
Copy link
Author

rugk commented Mar 27, 2017

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
Copy link
Author

rugk commented Oct 1, 2019

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

@TriMoon
Copy link

TriMoon commented Oct 3, 2019

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 😉

@rugk
Copy link
Author

rugk commented Oct 3, 2019

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

@xuhdev
Copy link
Member

xuhdev commented Oct 3, 2019

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

@Freso
Copy link

Freso commented Aug 29, 2023

@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.

@xuhdev
Copy link
Member

xuhdev commented Sep 1, 2023

@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?

@Freso
Copy link

Freso commented Sep 2, 2023

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.

@rugk
Copy link
Author

rugk commented Sep 5, 2023

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/

@xuhdev
Copy link
Member

xuhdev commented Sep 7, 2023

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)

@treyhunner
Copy link
Member

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.

@Freso
Copy link

Freso commented Sep 7, 2023

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 legal1.

Footnotes

  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…

@treyhunner
Copy link
Member

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. 😊

@Freso
Copy link

Freso commented Sep 7, 2023

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. 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants