search

FOSSRIT / infrastructure

Set of scripts, Ansible playbooks/roles, and other tools to automate and manage FOSS@MAGIC infrastructure
BSD 3-Clause "New" or "Revised" License
5 stars 3 forks source link

Consider project license change to BSD 3-Clause License #39

Closed jwflory closed 5 years ago

jwflory commented 5 years ago

Summary

Change project license from Mozilla Public License 2.0 to BSD 3-Clause License

Background

This project is licensed under the Mozilla Public License 2.0 (MPLv2), a copyleft license. The MPLv2 requires changes made to upstream software to also be released open source. This license promotes the practice of participating in an upstream project.

However, given this repo contains configurable assets that must be changed to be useful (e.g. variables and config files), the MPLv2 is a restrictive license for reuse. Some may steer away because the license implies they must release their automation infrastructure tools as open source, which is an unfair pre-requirement.

Details

I suggest changing to a permissive BSD 3-Clause License for this project. It asserts these requirements for legal reuse and redistribution:

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.

3. Neither the name of the copyright holder nor the names of its
   contributors may be used to endorse or promote products derived from
   this software without specific prior written permission.

Outcome

Less reluctance to use this repository for someone else's proprietary project, hopefully more engagement with us as an upstream because it's useful for other people than ourselves too

ghost commented 5 years ago

Standard disclaimers apply: IANALATDNCLOFA

1) Pretty much the only thing that remains in HEAD is from you, so you can change the license on that to whatever you want. Permissive, non-reciprocal licenses are the shortest to read and easiest to understand and carry the fewest obligations and restrictions, and are generally the most generous license one can offer.

2) The very little that's in this from previous contributors, @ralphbean and @decause, had no license at all from what I can see. You can't add a license to their stuff without their assent, but I don't think that's much at issue here or what you're trying to do. The stuff that remains from them in early commits is very modest in scope, but if they want to advocate for a course of action with regard to licensing that stuff it's up to them.

3) While license information is good to put in a project-wide file up front as a convenience to newcomers, I think the standard to follow is putting in one-line, per-file SPDX IDs, because different files can and do have different licenses, and the re-use we seek to support can see them get mixed in with files that have other licenses from other projects.

https://spdx.org/ids-how

This is more of a do-as-I-say, not-as-I-do sort of thing, though. Alas.

4) I've been saving the most painful thing for last. I think you misunderstand something pretty fundamental about how copyleft generally works and what copyleft aims to do. I feel I bear some responsibility for this misunderstanding, so I'm going to see what work I can do to identify the misunderstanding and correct it as best I can.

Copyleft is meant to prevent the establishment of a dependency of the downstream on upstream. Its originators see that dependency as an injustice. The context here was largely pre-Internet, when most code was run in isolation or at most on small networks, in contrast to today's situation of code being passed around in great volume at great frequency and speed.

Code at the time was increasingly being distributed as runnable object binaries only, separate from the source code and build systems used to create the object code. These object binaries were, for most practical purposes, not human readable. The build system tooling and the human readable source files were, in many cases, held back. In some cases, this may have been a convenience: It takes fewer floppy disks to distribute only object binaries, many more to distribute source code, and way, way more to distribute compilers and libraries and the like. Practical considerations like these are why copyleft terms generally do not require one provide the source up front, but rather requires only that one provide an offer* to provide the source on request (and even then, only requires that that offer be good only for a limited time, and only need be made to one's downstream recipients, not to everybody). That so many distributors of FOSS now make code available through the network to everyone goes far beyond most copyleft requirements. This is generous for them to do, but it seems people infer too much about copyleft from it.

Still, on just this point alone, we see that configuration files that are not rendered into a non-readable object code form are not in scope of copyleft.

But there's more: Copyleft does not restrict standalone, internal use in any way (freedom 0 in FSF parlance). Anyone who downloads these is free to use them for their own systems internally however they like, and to make whatever changes to them they like. They have no obligation to share those changes or the upstream originals due to having received them under the MPL.

Copyleft triggers only on redistribution, because that's the step where source and object code can become separated, and the point at which a dependency of downstream on upstream becomes established. And again, since these are configuration files, any redistribution is going to be in a human readable, human editable "source" form. Copyleft demands no more than that human-readable form. So, no problem.

Newer copyleft licenses like AGPL do attach some obligation to use--if the code is used to provide a networked service. Even here, the scope of the obligation is limited.

The SSPL reaches very broadly in this regard, and it is this very broad reach that has made it so controversial.

Were other copyleft licenses so broad in scope as it looks like you're claiming here, the SSPL would have been redundant.

jwflory commented 5 years ago

Copyleft triggers only on redistribution, because that's the step where source and object code can become separated, and the point at which a dependency of downstream on upstream becomes established.

@ritjoe A big "TIL" moment for me! I see now by changing the license, the effect I want isn't really achieved. Given the context of this repository and considering some of the points you mentioned, I still believe a permissive license like the BSD 3-Clause License is a better fit for this project anyways.