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

Relicense {fmt} to make it more friendly for standard library vendors #1073

Closed
43 tasks done
vitaut opened this issue Mar 8, 2019 · 27 comments
Closed
43 tasks done

Relicense {fmt} to make it more friendly for standard library vendors #1073

vitaut opened this issue Mar 8, 2019 · 27 comments

Comments

@vitaut
Copy link
Contributor

vitaut commented Mar 8, 2019

According to Billy O'Neal, the standard library vendors (including libstdc++) all can't look at BSD-licensed code. To fix this we need to drop all requirements on binary redistribution, e.g. introduce a clause similar to "LLVM Exceptions to the Apache 2.0 License":

As an exception, if, as a result of your compiling your source code, portions
of this Software are embedded into an Object form of such source code, you
may redistribute such embedded portions in such Object form without complying
with the conditions of Sections 4(a), 4(b) and 4(d) of the License.

In addition, if you combine or link compiled forms of this Software with
software that is licensed under the GPLv2 ("Combined Software") and if a
court of competent jurisdiction determines that the patent provision (Section
3), the indemnity provision (Section 9) or other Section of the License
conflicts with the conditions of the GPLv2, you may retroactively and
prospectively choose to deem waived or otherwise exclude such Section(s) of
the License, but only in their entirety and only with respect to the Combined
Software.

See also http://llvm.org/foundation/relicensing/

Also might be a good time to introduce CLA: https://github.com/cla-assistant/cla-assistant

List of current library contributors from blame:

@mjcaisse
Copy link

mjcaisse commented Mar 9, 2019

Boost Software License (BSL) also has no binary requirement.

Boost Software License - Version 1.0 - August 17th, 2003

Permission is hereby granted, free of charge, to any person or organization
obtaining a copy of the software and accompanying documentation covered by
this license (the "Software") to use, reproduce, display, distribute,
execute, and transmit the Software, and to prepare derivative works of the
Software, and to permit third-parties to whom the Software is furnished to
do so, all subject to the following:

The copyright notices in the Software and this entire statement, including
the above license grant, this restriction and the following disclaimer,
must be included in all copies of the Software, in whole or in part, and
all derivative works of the Software, unless such copies or derivative
works are solely in the form of machine-executable object code generated by
a source language processor.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.

@DanielaE
Copy link
Contributor

That's fine with me!

@eliaskosunen
Copy link
Contributor

I agree to the changes

@riccozzz
Copy link
Contributor

By the way, I am the artist formerly known as just "Brian" on this list, so you can remove it.

@mwinterb
Copy link
Contributor

As a note, mwinterb and Michael Winterberg are the same. Unless there's another Michael Winterberg out contributing :)

@niosHD
Copy link
Contributor

niosHD commented Mar 21, 2019

Hi @vitaut, thank you for the ping in #513. I am fine with changing the license to drop all requirements on binary redistribution.

@LarsGullik
Copy link

I agree to the changes.

@alabuzhev
Copy link
Contributor

No objections.

@dean0x7d
Copy link
Contributor

dean0x7d commented Apr 9, 2019

I agree with changing the license!

@medithe
Copy link
Contributor

medithe commented Apr 10, 2019

I agree to the changes!

@abolz
Copy link
Contributor

abolz commented Apr 10, 2019

I agree to the changes.

@Remotion
Copy link
Contributor

I agree to license changes as well.

@Rakete1111
Copy link
Contributor

I agree as well :)

This was referenced Apr 19, 2019
@0x8000-0000
Copy link
Contributor

I agree to the changes.

1 similar comment
@morinmorin
Copy link
Contributor

I agree to the changes.

@CarterLi
Copy link
Contributor

That's ok with me.

@Naios
Copy link
Contributor

Naios commented Apr 26, 2019

I agree to the changes.

@stryku
Copy link
Contributor

stryku commented May 12, 2019

LGTM, I agree +1

@mikelui
Copy link
Contributor

mikelui commented May 30, 2019

Late to the party. Agreed!

@nightlark
Copy link

nightlark commented Jun 17, 2019

Please stay far, far, far away from CLAs -- they are a huge pain that can add significant hurdles to contribution or even make it legally impossible to contribute.

My own experience with this has been with Microsoft/vcpkg; they require signing a CLA in order to open a PR to add a package. I sent the legal department at work an email asking for permission to sign the CLA at the beginning of the year -- it has not been approved because of some "indemnity clause", and they have offered no alternatives for how we can get a package submitted (nearly 6 months later). To be clear, the code for adding a package could legally be open sourced, but because of the CLA it's impossible for me to contribute that change upstream. I've even asked if I could prepare the package and open the PR on my own time so that I could sign the individual CLA instead, and the answer was basically no (submitting the package would be too similar to the project I was getting paid to work on). And this restriction applies no matter how trivial the change is.

Some of the writing on the subject (DCO would be much easier for contributors at companies than a CLA):
https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-add-a-cla-to-your-open-source-project/
https://opensource.com/article/18/3/cla-vs-dco-whats-difference
https://about.gitlab.com/2017/11/01/gitlab-switches-to-dco-license/
https://software.llnl.gov/about/licenses/#developer-certificate-of-origin

Beyond that, an unmodified license that fulfills the requirements you're looking for (Boost as suggested above?) might be easier to get past corporate legal departments than one with exceptions added (ZeroMQ LGPL with static linking exception raised some questions) -- at least as far as upstreaming any changes go. I know where I work legal gives a bit more scrutiny to contributions to OSS projects if their chosen license also covers patents.

@vitaut
Copy link
Contributor Author

vitaut commented Jun 19, 2019

BSD will continue to be an option so exception is not a problem.

@vitaut
Copy link
Contributor Author

vitaut commented Jun 23, 2019

All current contributors to fmt/core.h and format.cc accounted for except for authors of two small commits:

fmt/format.h:

fmt/format-inl.h:

fmt/time.h:

@teajay-fr
Copy link

I have no objections to changing the license terms.

@ghost
Copy link

ghost commented Aug 15, 2019

I agree to the changes.

@AndreasSchoenle
Copy link
Contributor

I do of course agree to changing license terms in any way you see fit.

@tnovotny
Copy link
Contributor

I am fine with the changes.

@vitaut
Copy link
Contributor Author

vitaut commented Aug 21, 2019

The new license draft: https://github.com/fmtlib/fmt/blob/master/LICENSE.rst

@vitaut vitaut closed this as completed Aug 22, 2019
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