-
Notifications
You must be signed in to change notification settings - Fork 13
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
Comments
Someone please suggest this to the debian guys to add it to the repos... |
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. |
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. |
GitLab is intended to be self-hosted, and self-hosted GitLab is the realest GitLab :P |
@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 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 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? |
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 |
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/ |
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) |
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 # 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. 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. |
I asked upstream about whether they’d accept a Python plugin for 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 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
|
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. 😊 |
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 |
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
The text was updated successfully, but these errors were encountered: