We need your help!
Like many organizations, the FSF is suffering from inflation. Operational costs have risen and revenue has not kept up, because people all over the world are going through the same challenges as we are. The FSF has an important role to play for computer users globally for years to come, and we still have a lot of work to do.
Can you support our efforts by joining the FSF as an associate member for only $12/month ($6 for students), introducing a friend to free software, or gifting a membership?
By supporting us today, you help secure the future of software freedom!
Join | Convince a friend | Gift a membership
Skip to content , sitemap or skip to search .
Personal tools
- Members forum
Copyright assignment at the FSF
Editor's note (added 2024-01-12): Please see the additional relevant information in the two links below:
- FSF copyright handling: A basis for distribution, licensing and enforcement (published August 2021)
- Contributor's Frequently Asked Questions (FAQ) guide details the assignment process (published September 2021)
One of the services the FSF provides to the free software movement is license enforcement for the GNU Project. Our ability to enforce the license on packages like GCC or GNU Emacs begins with a copyright assignment. Put simply, this is the legal transfer of copyright on a program from the developers to the Free Software Foundation. Our copyright assignment program is crucial in promoting our mission “to preserve, protect and promote the freedom to use, study, copy, modify, and redistribute computer software, and to defend the rights of free software users.” The program is as old as the FSF itself; we started it almost thirty years ago in 1985.
Eben Moglen, director-counsel of Software Freedom Law Center, expounds that our copyright assignment program helps with our enforcement of the General Public License (GPL):
In order to make sure that all of our copyrights can meet the recordkeeping and other requirements of registration, and in order to be able to enforce the GPL most effectively, FSF requires that each author of code incorporated in FSF projects provide a copyright assignment, and, where appropriate, a disclaimer of any work-for-hire ownership claims by the programmer's employer. That way we can be sure that all the code in FSF projects is free code, whose freedom we can most effectively protect, and therefore on which other developers can completely rely.
While our assignment program is critical to our work, there are still some common misconceptions. We hope to explain some of the key protections put in place throughout our assignment program to help allay concerns contributors often have when deciding to make an assignment. Sometimes contributors are concerned about giving up rights to their work. As the assignment is a gift to the free software community, they don't want it to come at the expense of having flexibility in the use of their own code. Thus, we grant back to contributors a license to use their work as they see fit. This means they are free to modify, share, and sublicense their own work under terms of their choice. This enables contributors to redistribute their work under another free software license. While this technically also permits distributing their work under a proprietary license, we hope they won't.
Contributors also sometimes have concerns about what is being transferred. While they may be happy to submit some code to a particular package, there may be other elements of their work that they would prefer to keep separate. Free software is of course about freedom, and the freedom to not distribute some code you are working on is integral to that goal. So we frequently get requests to have a more fine-grained assignment contract. As our standard form covers all past and future contributions on a package, some contributors worry about later patches falling under the agreement. There is no need for concern, as our assignment contract already grants the contributor total control over what is transferred and what is not. The assignment requires that the contributor notify the FSF of what code they consider covered by the assignment. The simple and most common method for doing so is to simply contribute the code to the project. Contributors can of course take a more formal path and actually send a letter to the FSF stating which particular files are assigned, but this is much less common.
The copyright assignment program provides numerous benefits to the contributors as well as the community: it allows others to work on the code either to improve, educate, or evolve, while the contributors maintain full rights to their code. Willing contributors can also have their contributions announced in our Free Software Supporter newsletter, as well as being publicized on the FSF's microblog accounts. But the most important element of the assignment contract is the promise we make to every contributor and community member: We promise to always keep the software free. This promise extends to any successors in the copyright, meaning that even if the FSF were to go away the freedom of all users to share in the contributions wouldn't.
While not every GNU Project package is assigned to the FSF, many of the oldest and longest running projects have taken part in the assignment process. By assigning their copyright, the contributors on these projects enable the FSF to keep the software free. We hope we've helped you understand a bit more about this important program, and that perhaps you'll join the thousands of hackers from all around the world who have entrusted the copyright on their work to the Free Software Foundation.
Document Actions
- Share on social networks
The FSF is a charity with a worldwide mission to advance software freedom — learn about our history and work.
fsf.org is powered by:
Arabic Belarussian Bulgarian Catalan Chinese Cornish Czech Danish English French German Greek Hebrew Hindi Italian Japanese Korean Norwegian Polish Portuguese Portuguese (Brazil) Romanian Russian Slovak Spanish Swedish Turkish Urdu Welsh
Send your feedback on our translations and new translations of pages to [email protected] .
Next: How To Get Help with GNU Emacs , Previous: Reporting Bugs , Up: The Emacs Editor [ Contents ][ Index ]
54 Contributing to Emacs Development
Emacs is a collaborative project and we encourage contributions from anyone and everyone.
There are many ways to contribute to Emacs:
- find and report bugs; see Reporting Bugs .
- answer questions on the Emacs user mailing list https://lists.gnu.org/mailman/listinfo/help-gnu-emacs .
- write documentation, either on the wiki , or in the Emacs source repository (see Sending Patches for GNU Emacs ).
- check if existing bug reports are fixed in newer versions of Emacs https://debbugs.gnu.org/cgi/pkgreport.cgi?which=pkg&data=emacs .
- fix existing bug reports.
- implement a feature listed in the etc/TODO file in the Emacs distribution, and submit a patch.
- implement a new feature, and submit a patch.
- develop a package that works with Emacs, and publish it on your own or in GNU ELPA ( https://elpa.gnu.org/ ).
- port Emacs to a new platform, but that is not common nowadays.
If you would like to work on improving Emacs, please contact the maintainers at the emacs-devel mailing list . You can ask for suggested projects or suggest your own ideas.
If you have a feature request or a suggestion for how to improve Emacs, the best place to send it is to bug-gnu-emacs . Please explain as clearly as possible what change you would like to see, and why and how you think it would improve Emacs.
If you have already written an improvement, please tell us about it. If you have not yet started work, it is useful to contact emacs-devel before you start; it might be possible to suggest ways to make your extension fit in better with the rest of Emacs.
When implementing a feature, please follow the Emacs coding standards; see Coding Standards . In addition, substantial contributions require a copyright assignment to the FSF; see Copyright Assignment .
The development version of Emacs can be downloaded from the repository where it is actively maintained by a group of developers. See the Emacs project page https://savannah.gnu.org/projects/emacs/ for access details.
It is important to write your patches based on the current working version. If you start from an older version, your patch may be outdated (so that maintainers will have a hard time applying it), or changes in Emacs may have made your patch unnecessary. After you have downloaded the repository source, you should read the file INSTALL.REPO for build instructions (they differ to some extent from a normal build).
If you would like to make more extensive contributions, see the CONTRIBUTE file in the Emacs source tree for information on how to be an Emacs developer. That file is distributed as part of the source tarball of every released Emacs version, and can also be found on-line in the Emacs on-line source repository . If you cloned the Emacs repository, per the instructions in https://savannah.gnu.org/projects/emacs/ , you will find this file in the top directory of the source Emacs tree.
For documentation on Emacs (to understand how to implement your desired change), refer to:
- the Emacs Manual https://www.gnu.org/software/emacs/manual/emacs.html .
- the Emacs Lisp Reference Manual https://www.gnu.org/software/emacs/manual/elisp.html .
- https://www.gnu.org/software/emacs
- https://www.emacswiki.org/
- Coding Standards
- Copyright Assignment
53.2 Copyright Assignment
The FSF (Free Software Foundation) is the copyright holder for GNU Emacs. The FSF is a nonprofit with a worldwide mission to promote computer user freedom and to defend the rights of all free software users. For general information, see the website https://www.fsf.org/ .
Generally speaking, for non-trivial contributions to GNU Emacs and packages stored in GNU ELPA, we require that the copyright be assigned to the FSF. For the reasons behind this, see https://www.gnu.org/licenses/why-assign.html .
Copyright assignment is a simple process. Residents of some countries can do it entirely electronically. We can help you get started, including sending you the forms you should fill, and answer any questions you may have (or point you to the people with the answers), at the [email protected] mailing list.
(Please note: general discussion about why some GNU projects ask for a copyright assignment is off-topic for emacs-devel. See gnu-misc-discuss instead.)
A copyright disclaimer is also a possibility, but we prefer an assignment. Note that the disclaimer, like an assignment, involves you sending signed paperwork to the FSF (simply saying “this is in the public domain" is not enough). Also, a disclaimer cannot be applied to future work, it has to be repeated each time you want to send something new.
We can accept small changes (roughly, fewer than 15 lines) without an assignment. This is a cumulative limit (e.g., three separate 5 line patches) over all your contributions.
Navigation Menu
Search code, repositories, users, issues, pull requests..., provide feedback.
We read every piece of feedback, and take your input very seriously.
Saved searches
Use saved searches to filter your results more quickly.
To see all available qualifiers, see our documentation .
- Notifications You must be signed in to change notification settings
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
Implement a copyright assignment policy such that this could be upstreamed. #238
hammerandtongs commented Jul 16, 2017
|
Whether or not this project would ever be upstreamed it would seem like a mistake not to plan for it at this stage. |
| The text was updated successfully, but these errors were encountered: |
- 👍 9 reactions
| I'm not sure but maybe a workflow via this tool would suffice?
|
- 👍 1 reaction
Sorry, something went wrong.
Wilfred commented Jul 16, 2017
| Being inclusive is an important goal for Remacs. Copyright assignment is a significant hurdle to contribution. All our code is under GPLv3, so we're fully Free Software, but we benefit from people dropping by with small patches (even if they're >15 lines of code). Remacs is in a great position to explore different workflows, and this is an important way that we differ from GNU Emacs. Plenty of contributors do have copyright assignment to the FSF, myself included. We do upstream relevant elisp patches. We want to make Emacsen better and more accessible to everyone! |
- 👍 4 reactions
alphapapa commented Oct 15, 2017
| I think this decision should be reconsidered. If one of the goals of Remacs is actually to provide for the long-term future of Emacs, on the assumption that the core C-language devs will retire without replacements, then it is very important that Remacs could be adopted by the FSF. If Remacs can't take Emacs's place under the FSF umbrella in the future, it could end up being a "real" fork, which would likely lead to incompatibilities down the line. And if that happened, it would likely split the community, and that could actually be harmful to Emacs/Remacs's future as a whole. Emacs will surely face more competition from other projects in the future, not less, so I think it's important to plan ahead so that the Emacs/Remacs efforts could be consolidated someday. I appreciate your work on this, as it has a lot of potential, both technically and in attracting new users and developers. I would hate to see it held back by gradual divergence, leading to users having to eventually make a tough decision someday. As an Emacs package developer, I would want to see another XEmacs/Emacs-type split with minor incompatibilities (e.g. Org mode has a lot of old code for XEmacs support; let's not do that again!). Thanks for your consideration. |
- 👍 18 reactions
- 👎 1 reaction
vermiculus commented Jun 25, 2018
| I would add my voice to this -- I also do not want to see another XEmacs/Emacs split. Emacs should always be GNU Emacs -- and GNU Emacs should (IMO) move to Rust. That will be legally difficult if an existing Rust implementation is not assignable since it will be risky -- if not impossible -- for the FSF to say 'we definitely didn't use that code'. |
- 👍 10 reactions
No branches or pull requests
Get the Reddit app
The extensible, customizable, self-documenting real-time display editor.
ELI5: FSF copyright assignment
with the recent activity regarding RMS wishing that someone would come up and write a replacement for magit that could be bundled inside emacs, and give FSF the whole copyright assignment, I cannot help but be intrigued: what good do these required copyright assignments do to the free software community?
I really, really tried to understand but cannot. It's hard enough for a community to be graced with the luck of having someone as Jonas Bernoulli write the magit package, give away de code as GPLv3, and actually maintain it through years. You have to also sign like physical papers handing the copyright to the FSF. Now that becomes so much difficult. What's the gain?
So what if the copyright belongs to someone else. Isn't this free software? gplv3? don't you have the four liberties?
ELI5, please.
![[Home]](https://www.emacswiki.org/images/logo218x38.png "emacs copyright assignment")
Comments on Copyright Assignment
There are no comments, yet. Be the first to leave a comment!
Add your comment here:
Please make sure you contribute only your own work. IP numbers are made available via the page history. If you want to keep it a secret, you need to use Tor . See TextFormattingRules for how to format text. See StyleGuide for the suggested writing style on this wiki.
To save this page you must answer this question:
What is the greatest editor out there?
Username: Homepage URL:
Previous: Coding Standards , Up: Contributing [ Contents ][ Index ]
53.2 Copyright Assignment
The FSF (Free Software Foundation) is the copyright holder for GNU Emacs. The FSF is a nonprofit with a worldwide mission to promote computer user freedom and to defend the rights of all free software users. For general information, see the website https://www.fsf.org/ .
Generally speaking, for non-trivial contributions to GNU Emacs and packages stored in GNU ELPA, we require that the copyright be assigned to the FSF. For the reasons behind this, see https://www.gnu.org/licenses/why-assign.html .
Copyright assignment is a simple process. Residents of some countries can do it entirely electronically. We can help you get started, and answer any questions you may have (or point you to the people with the answers), at the [email protected] mailing list.
(Please note: general discussion about why some GNU projects ask for a copyright assignment is off-topic for emacs-devel. See gnu-misc-discuss instead.)
A copyright disclaimer is also a possibility, but we prefer an assignment. Note that the disclaimer, like an assignment, involves you sending signed paperwork to the FSF (simply saying “this is in the public domain” is not enough). Also, a disclaimer cannot be applied to future work, it has to be repeated each time you want to send something new.
We can accept small changes (roughly, fewer than 15 lines) without an assignment. This is a cumulative limit (e.g., three separate 5 line patches) over all your contributions.
Copyright Assignment Form
|
IMAGES
VIDEO
COMMENTS
We can help you get started, including sending you the forms you should fill, and answer any questions you may have (or point you to the people with the answers), at the [email protected] mailing list. (Please note: general discussion about why some GNU projects ask for a copyright assignment is off-topic for emacs-devel.
CONTRIBUTE of Emacs distribution. Assigning copyright for people under 18: If the person is under 18 years old their parent needs to also sign the contract. The biggest sticking point is that the assignment is only valid up until that person's 18th birthday. Insistent of Assignment of rights is met with mixed reaction in general.
Personally, I haven't contributed to Emacs for a few years because of this copyright assignment. There are two problems: the process is complicated, and it is additional process that requires external people. Let me outline how it went the last time I tried to do the assignment. The Emacs Documentation says to email [email protected], so I ...
If I remember correctly from a few of those discussions that I followed, the actual question was whether there is a purpose for the copyright assignment. Did the FSF ever go to court to protect the code of Emacs, and if it did, in the absence of copyright transfers, would there have been a challenge on that grounds?
The copyright assignment is required for any GNU project, not just Emacs; and they would need to enforce it if someone violated the license. The stock example is someone providing builds without also providing the source (not necessarily a closed-source fork), but there are other possible GPL violations.
One of the services the FSF provides to the free software movement is license enforcement for the GNU Project. Our ability to enforce the license on packages like GCC or GNU Emacs begins with a copyright assignment. Put simply, this is the legal transfer of copyright on a program from the developers to the Free Software Foundation.
If you would like to make more extensive contributions, see the CONTRIBUTE file in the Emacs source tree for information on how to be an Emacs developer. That file is distributed as part of the source tarball of every released Emacs version, and can also be found on-line in the Emacs on-line source repository .
Version 29.4 of Emacs, the extensible text editor, should now be available from your nearest GNU mirror. Emacs 29.4 is an emergency bugfix release; it includes no new features except a small number of changes intended to resolve a security vulnerability uncovered in Emacs 29.3 and earlier.
Dan Harms <[email protected]> writes: > I would like a copyright assignment for contributing to emacs. (Sent off-list.) > Also some elpa packages, like swiper and auto-complete. > Do I need to list all elpa packages? Do I need to request a different > assignment for every package I may want to contribute to in the > future?
The FSF (Free Software Foundation) is the copyright holder for GNU Emacs. The FSF is a nonprofit with a worldwide mission to promote computer user freedom and to defend the rights of all free software users.
Emacs should always be GNU Emacs -- and GNU Emacs should (IMO) move to Rust. That will be legally difficult if an existing Rust implementation is not assignable since it will be risky -- if not impossible -- for the FSF to say 'we definitely didn't use that code'.
> I assume this means, once we > cumulatively reach >=15 lines of sloc we then retroactively give our > copyright assignment to the work, but > then we need to reassign the copyright holding to fsf for future contribution? Yes. But this is a one-time procedure, there's no need to assign the copyright each time you submit a contribution.
I just want to confirm that Emacs manuals translations require a copyright assignment to the FSF for publication within Emacs, but not for publication in other places (as long as publication follows the licence).
The issue here is just that all parts of Emacs that are shipped with Emacs should have the same copyright holder. If you have your own project licensed under the GPL, you are the copyright holder and you are responsible to enforce the license. ... One other reason I see for requesting copyright assignment is related to license upgrades. For ...
This work is licensed to you under version 2 of the GNU General Public License.Alternatively, you may choose to receive this work under any other license that grants the right to use, copy, modify, and/or distribute the work, as long as that license imposes the restriction that derivative works have to grant the same rights and impose the same restriction.
Dear maintainers, I expect to spend some time working on Emacs and hopefully upstream my patches (of course, if people want them). Therefore, I'm humbly requesting to start the copyright assignment process. Thanks! Best regards, Kai
> From: Kai Ma <[email protected]> > Date: Sat, 3 Feb 2024 02:35:34 +0800 > > Dear maintainers, > > I expect to spend some time working on Emacs and hopefully upstream my > patches (of course, if people want them). Therefore, I'm humbly requesting > to start the copyright assignment process. Thanks!
Prev by Date: Re: Consideration for Rust contributions in Emacs Next by Date: Re: How to install documentation in sub-directory with Package VC? Previous by thread: Re: [elpa] externals/switchy-window 682bcec0a6: Release 1.2: no code changes but don't suggest adding lambdas to hooks
I'm looking to contribute to a package available in ELPA. Can someone send me the forms I have to sign and maybe some instructions on how to proceed?
(Please note: general discussion about why some GNU projects ask for a copyright assignment is off-topic for emacs-devel. See gnu-misc-discuss instead.) A copyright disclaimer is also a possibility, but we prefer an assignment. Note that the disclaimer, like an assignment, involves you sending signed paperwork to the FSF (simply saying "this ...
[Prev in Thread] Current Thread [Next in Thread]Copyright assignment, Artem Yurchenko <=. Re: Copyright assignment, Eli Zaretskii, 2024/03/27; Copyright assignment ...
I am interested in contributing to the Android development branch of emacs and I was told I need to fill out an assignment form to hand over my GPL enforcement rights to the FSF.