4 ms·

> GNU project status discourages new contributors because of the paperwork requirements Can somebody elaborate this point? Does that mean I need to go through

> GNU project status discourages new contributors because of the paperwork requirements Can somebody elaborate this point? Does that mean I need to go through paperwork even for contributing a bug fix?

ebiester 6y ago
If it hasn't changed recently, you have to send in paperwork assigning your contribution to GNU as to maintain a single copyright owner.
- lmm 6y ago
  Plenty of projects require a CLA, which seems pretty similar paperwork-wise?
  - rleigh 6y ago
    Absolutely similar, but don't underestimate the friction this introduces, and the number of potential contributors you cut off by doing this. Getting corporate sign-off for such things can take months while it wends its way through legal departments and upper management. Many people won't even bother, it's such a hassle. Last one I did was for Apache. It took at least six months. Previously did several for GNU which were much quicker (in a different company).
rleigh 6y ago
Yes. You have to assign copyright to the FSF in order to contribute anything. This is one reason for its demise. I've done the copyright assignment for both Autoconf and Automake. It's one reason why there are external macro archives (e.g. Autoconf Archive), when much of this functionality could be in the core projects. Example: Why, in 2021, should you have to rely on external support to do something as trivial as enabling multithreading [ACX_PTHREAD]. It's not even portable to non-pthreads platforms. So much for portability. Contrast with CMake [find_package(Threads); use Threads::Threads]. Compared with CMake, which doesn't require copyright assignment, and anyone can contribute to. It has hundreds of contributors, tons of built-in functionality, and more third-party extensions than Autotools could ever dream of. Copyright assignment is a big part of that, but also so is upstream attitude to third-party contributions. Kitware do this very well. The Autotools maintainers not so much; partly down to their own historical bad choices which prevented change to the internals due to the potential for breaking compatibility.

ebiester 6y ago

If it hasn't changed recently, you have to send in paperwork assigning your contribution to GNU as to maintain a single copyright owner.

lmm 6y ago
Plenty of projects require a CLA, which seems pretty similar paperwork-wise?
- rleigh 6y ago
  Absolutely similar, but don't underestimate the friction this introduces, and the number of potential contributors you cut off by doing this. Getting corporate sign-off for such things can take months while it wends its way through legal departments and upper management. Many people won't even bother, it's such a hassle. Last one I did was for Apache. It took at least six months. Previously did several for GNU which were much quicker (in a different company).

rleigh 6y ago

Yes. You have to assign copyright to the FSF in order to contribute anything. This is one reason for its demise. I've done the copyright assignment for both Autoconf and Automake. It's one reason why there are external macro archives (e.g. Autoconf Archive), when much of this functionality could be in the core projects. Example: Why, in 2021, should you have to rely on external support to do something as trivial as enabling multithreading [ACX_PTHREAD]. It's not even portable to non-pthreads platforms. So much for portability. Contrast with CMake [find_package(Threads); use Threads::Threads]. Compared with CMake, which doesn't require copyright assignment, and anyone can contribute to. It has hundreds of contributors, tons of built-in functionality, and more third-party extensions than Autotools could ever dream of. Copyright assignment is a big part of that, but also so is upstream attitude to third-party contributions. Kitware do this very well. The Autotools maintainers not so much; partly down to their own historical bad choices which prevented change to the internals due to the potential for breaking compatibility.