Update CONTRIBUTING.md to broaden the intent of the contributor agreement

[RalphSteinhagen]

• Merged DCO Signing and Contributor License Agreement sections for clarity.
• Clarified the authority required for code submissions and the potential rights of employers.
• Simplified the DCO signing instructions and emphasized the need for legal compliance.
• Streamlined language to reduce redundancy and maintain legal soundness.
• Added explicit confirmation of rights granted by contributors, including employer permissions.
• Emphasized GNU Radio’s principles of remaining free/libre and compliant with evolving laws.
• Highlighted the support for public-private partnerships and commercial contributions without disclosing proprietary stacks.
• Maintained the spirit of open-source contributions and community collaboration.
• Ensured the guidelines are clear, concise, and foster an inclusive environment.

See the updated CONTRIBUTING.md for details.

Signed-off-by: Josh Morman [email protected]
Signed-off-by: Ralph J. Steinhagen [email protected]

[flynn378]

Should this for the Linux kernel standard (and many other projects), a SPDX entry on each file with copyright per file. It removes the ambiguity and clearly labels each file. https://reuse.software/ is a tool that helps with this process.

Based on conversions with the lawyers at one entity which supports and contributes to open source projects, assigning a copyright when a license term can be changed so that they cannot use it in the future will prevent submitting code. It stopped submissions to GNU Radio when copyright had to be given to the FSF.

I could be misreading the language, but it looks like this includes an agreement the license could be changed, and in essence a copyright is being assigned, which allows this.

[daniestevez]

The paragraph "Notably by contributing to GNU Radio" to me looks very much like a CLA that we don't have in GNU Radio 3. "You grant this project" is hardly legalspeak, because it isn't clear what legal entity is "the project", especially since at the moment GNU Radio is an unincorporated association which perhaps cannot even hold the rights that are said to be granted. In the way that this is written, it appears to me that the project would get the rights to re-license the contributed code in any way (including under a closed-source license), despite the motivations given below saying that the intention is that GNU Radio shall ever remain open source (these intentions are not legally binding). I don't think the project would ever abuse this position, but given the number of open source projects that have suddenly become closed, I think this is a valid concern to express.

Why not exactly the same licensing scheme we have in GNU Radio 3? (This is: a DCO, the contribution must be under GPLv3 or later or compatible, and the contributor remains the only copyright holder).

Moreover, probably having a CLA would require some form of signed document by contributors, as GNU Radio 3 used to do in the FSF days, instead of just a simple Signed-off-by in git commits. This requirement turned out to be problematic for several contributors.

As a more practical example of why this kind of CLA is bad, I think I cannot take some GR 3 that I haven't written (or any other open source code, for that matter), adapt it to GNU Radio 4, and contribute it. This is because my contribution is a derived work and I can't grant rights for the original work.

[mormj]

Hope this isn't overkill, but added more detail about copyright assignment so it is clear that we are not requiring or dealing with CLAs. Also another sentence on irrevocability as this was one of the concerns with not having copyright assignment

[daniestevez]

Since 3882ef7, the SPDX for the core is LGPL-3.0-linking-exception rather than LGPL-3.0.

I'm just marking this as an item to review and keep in sync with the core LICENSE file before merging.

[RalphSteinhagen]

We can safely revert this to the vanilla LGPL-3.0 w/o additional disclaimer. We got meanwhile the info that this has been explicitly confirmed for another header-only C++ library (Eigen) by Brett Smith (Licensing Compliance Engineer, Free Software Foundation).

For more practical details, see here.

I hope this concludes this legal semantic debate.

EDIT: corrected primary link.

[daniestevez]

Is the link to the eigen mailing list correct? For me it goes to a thread "[eigen] problem to contact svn repository".

I'm not sure that eigen is a good example to advocate for LGPL-3.0 w/o linking exception for a header-only library. In 2012 they changed their license to MPL 2.0. In their own words, when eigen was LGPL they had a long FAQ about the implications that it isn't needed anymore with the MPL. It would be good to know more about the background and reasons for the license change.

The old LGPL FAQ mentions in two places that they asked the FSF about what happens with a header-only library, but the links they give to the mailing list are wrong (or most likely have become broken): http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2009/01/msg00083.html and http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2008/02/msg00008.html (one of these is the link you mentioned, the other points to a thread that does speak about FSF and licensing, but there are no clear answers there).

I think that in practice it doesn't matter if someone from the FSF in 2008 or 2009 said something about header-only libraries under the LGPL-3.0. What matters if we want to promote/simplify using GNU Radio 4.0 in closed source applications in industry is whether a legal department can review the license terms and have high confidence that there is no "GPL-like viral contamination" of the company's closed source code. If there is any reasonable doubt, they'll err on the side of caution and treat the license as a GPL-like viral license.

[RalphSteinhagen]

@daniestevez corrected the link. We could also opt for a more liberal license, but the decision of whether LGPLv3, or more liberal one is not mine to make and should be moderated/coordinated by the GR leadership team.

The repo is technical, and we should find a different platform to discuss the nuances of GNU Radio Project leadership and roadmap issues.

[daniestevez]

Thanks for finding the correct link. Still Brett Smith's response looks unconvincing to me. The question he is answering to is "I would like to know if the LGPLv3 can be suitable for a C++ pure template library, where all the code is in headers?", which is vague since "suitable" can mean any number of things. Brett simply says "yes, it is suitable, because of LGPLv3 Section 3".

The question that needs an answer is "can a closed-source application use an LGPLv3 header-only library, and if so, which requirements need to be followed". I know about section 3 in the LGPLv3, but it says "Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License". My reading is that Section 4 d) is still applicable, so users need to have a means to modify the Library in the Combined Work (and that's impossible if the Combined Work is a closed-source application and the Library is header-only).

The repo is technical, and we should find a different platform to discuss the nuances of GNU Radio Project leadership and roadmap issues.

Happy to take the discussion somewhere else. I think the reason we're discussing in this PR is that this got brought up in the Architecture Matrix channel and between discussing it in the channel or discussing it in the PR, it was decided that it was better to discuss it in the PR.

[RalphSteinhagen]

On a similar note as above:

In my view, it's important to keep licensing and (c)lean, maintainable code as separate concerns. Including a mandatory copyright header in every file doesn’t necessarily add value but does increase maintenance overhead and refactoring complexity.

Moreover, such headers can create unnecessary ambiguity, leading to questions about whether changes or add-ons conflict with top-level licensing agreements and a lot of bikeshedding. This ambiguity can require further reviews from legal experts, increasing the burden on contributors and maintainers.

To simplify this process, we already have a contributor list, which acknowledges contributions equally, regardless of the size or nature of the improvement. In line with the principle of "Keep It Simple, Stupid" (KISS), I believe we avoid legalese in the source code and focus on the core utility and quality of the library itself.

[daniestevez]

I get your point, but GNU Radio 3.10 does this and it doesn't seem to generate much burden.