What you did is not deserving of pearl-clutching but it is a little naive, which is understandable given that this is your first open source project. I will try to explain to the best of my ability as someone who has worked in and contributed to open source projects for 15 years.

A license permits you to use, modify and redistribute code, but it does not allow you to change the ownership of a work for copyright purposes. This is why open source projects will use an attribution header at the top of each source file, so that it is clear which person or entity owns the copyright of that code, and therefore who is the person or entity giving you the license to use it.

When someone forks a project, all of the existing code remains the property (for copyright purposes) of the original author. All of the new code committed is owned by the new authors of the fork. When the authors of the fork distribute their derived work, they are licensing their users to use their work under their own license, while the original code contained in the derived work is still licensed for use by the original author. When both licenses are the same (which they frequently are), this may seem like an academic distinction that’s not important.

It is important however, particularly in the case where in the future the authors of the downstream project decide that they want to re-license their project. You can only change the license on code that you wrote, since only the copyright owner has legal authority to license their work. The original (upstream) code in the fork can be distributed under a different license only if that license is “compatible” with the original author’s license, and even so the attribution statements and mention of the original license must still be preserved, because that becomes important if the code is to be relicensed a second time under a license which is compatible with the second but not the first license. Distributing code under a different, compatible license does not change the license of the original code or magically change copyright ownership!

The same rules apply when an upstream project incorporates code from a downstream project.

In the event that you use code from a project which does not have attribution headers, it is a requirement that all code that you incorporate from external sources gets attribution headers added to it, so that it is clear to recipients of your work who the original author is and under which license it was given to you (and therefore also to the end-user). Just because source code is FLOSS licensed does not mean that you can copy and paste it as though it’s public domain.

This situation does not only occur with forks, but in fact it is a normal situation to deal with in any project that has more than one contributor, since the code of each committer is their own property, and must be licensed by them individually! This is why some open source projects that accept contributions from the wider community will have a Contributor License Agreement (CLA) which assigns copyright ownership of every contribution to the project, and every committer must agree to it. This ensures that the legal entity owning the copyright is the project itself and not the individual contributors, and so in the event that the project desires to relicense the code it can do so without having to retain approval from every contributor in the history of the project.

CLAs have a bad reputation though, as they go against the spirit of Free Software, where every contributor owns the product of their own work. They are frequently used by “faux-pen source” businesses who will start an OSS project with an open license and require a CLA for contributions, then later on when they want to get more investment, sell the company or IPO, they will rug-pull by using the CLA to re-license the project under a non-free business-friendly license that adds restrictions that are not compatible with open-source.

In summary, you can freely use the work of your downstream forks provided that you retain attribution statements (ie. who is the author and what license they provided the work under) or add attribution statements when any are missing. Technically speaking, having that information only in the commit message is sufficient, provided that the version control history is never lost or rewritten, but it is much safer to have the information in the file itself, since this survives all methods of source redistribution (such as tarball downloads etc.)

Hope this helps, and I think you do a fantastic job with Piefed.