Please consider a non-copyleft or data-specific license #1
Comments
|
I shall consider the license. Firstly, the LGPL is specifically designed for linking with code of any other license, including with code which is proprietary licensed. Not being familiar with open data license(s), I shall read about them now. Here's links:
The ODbL requires contributors to sign a contract. I wish to avoid this. If there were overwhelming intention for the ODbL, I would accept it, as it is FSF endorsed and the primary "negatives" appear to be the inconvenience of the signed licensing regime, and some difficulties regarding incorporating the data into documentation, or as I see it, automatically transforming the data in way in which it becomes documentation - this latter problem can probably be overcome with an specific licensing exception, which would mean a custom "ODbL++" license, which would be a license proliferation which I would also like to avoid. Overall, the ODbL looks to be quite cumbersome - more cumbersome even than assigned copyright to the FSF to make a project an official FSF project (which I do not propose to do). The ODbL is possibly what it is, in the intention to target corporations or government etities, in order to encourage them to release data, by ensuring their respective lawyers that there is a license which meets their needs. I intend to avoid the ODbL in the face of what I've just read. The "conditions" which the ODbL hopes to achieve are (see wiki above)
So the core principles of the ODBL are sound. My understanding of the MIT and BSD licenses is that they are very similar, with minor differences in attribution requirements, different license text (of course), and significant possible consequential outcomes from the ODBL and GPL/LGPL principles "share alike" and "keep open". Given the work involved - namely that work (possibly) yet to come by those who put in the elbow grease for their chosen $EDITORs, I am not inclined to dismiss the "share alike" principle enshrined in both the ODbL and LGPL. We in the "FLOSS" / libre software community, ought (IMEHO) hold to the intentions "share alike" and "keep open". MIT/BSD licenses allow the Apple's and Microsoft's of the world to fork and close up, whereas ODbL/LGPL allow them to use, fork, extend and link for any purpose, yet restrict their right to "close up". Yes, in a literal technical sense, such (MIT/BSD etc) licenses are, technically "more" free, but in a practical or pragmatic sense, the GPL and family insist on (as I once heard it) "the minimum restriction necessary, to achieve the maximum freedom overall". Simply, "why should we make the life of the mega corps easier?" Finally I'll take a quick look at a few EditorConfig projects (at github../editorconfig/) - I have yet to clone any, so here goes... (this is not exhaustive, just a quick peruse):
So far, the core is mostly a combo of BSD and Apache, and plugins are using various FLOSS licenses. There being no block, other than self-imposed blocks, to corporations linking LGPL code with proprietary code, on the face of it I see no reason to not choose a "share alike" style FLOSS license. From this perspective I would rather impose the sufferences of ODbL than to give up to "ask for share alike". I'll have a further think and more detailed read on ODbL - this is the first time I've had any real need to do so. Thanks for the question - really got an exploration happening here :) |
|
@zenaan Thanks for the consideration and detailed response! I agree that keeping openness is a valuable goal. My own hesitation, in more detail, is (from LGPL 3):
I don't know for sure what the LGPL considers "use of an interface" when the LGPLed code is a data file rather than source code. I suppose that this repo could include source files in the various plugins' languages that would read the lang-list and report the results. Then I would think this repo would be a library, and the plugins could make use of its interface to the data files rather than reading them separately. I also found a reference here (wayback) to GPL3, section 5 of which covers "aggregates". The linked reference relates to OpenOffice.org dictionaries under GPL, and permits OpenOffice.org itself to use them without becoming GPL. (I am not a lawyer) |
|
On Sun, Oct 27, 2019 at 03:40:14PM -0700, Chris White wrote:
@zenaan Thanks for the consideration and detailed response! I agree that keeping openness is a valuable goal. My own hesitation, in more detail, is (from [LGPL 3](https://www.gnu.org/licenses/lgpl-3.0.txt)):
> An "Application" is any work that makes use of an interface provided by the Library
I don't know for sure what the LGPL considers "use of an interface"
when the LGPLed code is a data file rather than source code.
For the purposes of lang-list, I consider all data files to be
"source code".
If there is a libre benefit for the files in lang-list to be
considered otherwise than as "source code", we should consider that.
The primary issue for proprietary software "linking" with this
library, is that either the full source of the library (for static
linking) or use "dynamic linking" such that the (proprietary program)
"b) will operate properly with a modified version of the Library that
is interface-compatible with the Linked Version" (quote from the
LGPL).
in other words, the user can update the library, fix bugs etc, and
have the proprietary software use the user's updated version.
As long as the lang-list YAML files are loaded on first use, and any
cached representation of those files is updated if and when the
originals are updated, then the user can readily fix bugs etc.
I suppose that this repo could include source files in the various
plugins' languages that would read the lang-list and report the
results. Then I would think this repo would be a library, and the
plugins could make use of its interface to the data files rather
than reading them separately.
I don't believe any special requirements are needed, just because
lang-list is YAML files rather than "source code" of some other
language.
The intention with the GPL and LGPL is to empower the user, in
particular, to empower the user to fix bugs, make modifications, and
share those fixes/modifications with other people.
A weak copyleft license such as LGPL (or even weaker licenses like
MIT), remove technical impediments to "use with proprietary
software", and for a project such as EditorConfig is, this seems
appropriate to me, rather than using a strong copyleft license such
as GPL which would be "cutting off our nose to spite our face" (at
least in respect of proprietary software, which would therefore
likely look elsewhere for a solution).
I also found a reference
[here](https://bz.apache.org/ooo/show_bug.cgi?id=65039#c16)
([wayback](https://web.archive.org/web/20180624133904/https://bz.apache.org/ooo/show_bug.cgi?id=65039))
to [GPL3](https://www.gnu.org/licenses/gpl-3.0.txt), section 5 of
which covers "aggregates". The linked reference relates to
OpenOffice.org dictionaries under GPL, and permits OpenOffice.org
itself to use them without becoming GPL.
This is a genuine consideration.
If EditorConfig folks in general prefer GPL with exception for use
with proprietary software, that might provide a stronger legal
protection over the long term, to EditorConfig (/ lang-list) - but I
too am not a lawyer, and I think LGPL has been carefully designed to
cater to this case, in particular we don't have to invent the wording
to allow an exception, and possibly stuff up that wording to cause a
problem for ourselves.
Great considerations, thank you.
|
I appreciate your hard work putting together this list! Would you be willing to consider an MIT or BSD license instead of LGPL? Or an open-data type of license? Since this is data and not code, I am not sure how the LGPL provisions related to linking might apply to various plugins with their various licenses (e.g., BSD 2-clause for editorconfig-vim).
Thank you for considering this request!
The text was updated successfully, but these errors were encountered: