What is the best way to help free software developers that de-blob non-free things upstream?
- Vous devez vous identifier ou créer un compte pour écrire des commentaires
At
I saw parts of an ongoing discussion.
First I hope this will end well for everyone involved in any discussion.
Your people initially tried to steal the name Libreboot for their own project
Is the Libreboot name trademarked?
I thought even though the Linux kernel does have a trademark anyone can use it when making a fork.
I may wish to make a fork of many free software things, though I do not wish to be thought of as a thief for just using a name.
I think most software under a free license is like pizza, anyone can use the name pizza, the websites and repositories show who made what. So trademarks may not even be needed.
I saw the darknet program Trisquel uses has many people making forks that still use the same name, so I thought that was how freely shareable program development works.
And also I thought when making a GNU_Savannah thing,
https://en.wikipedia.org/wiki/GNU_Savannah
there are 2 parts of that site.
Savannah's website is split into two domain names: savannah.gnu.org for software that is officially part of the GNU Project, and savannah.nongnu.org for all other software.
https://savannah.gnu.org/register/requirements.php
https://savannah.nongnu.org/register/requirements.php
I thought the programs "officially part of the GNU Project" are mostly controlled by GNU and the things not GNU are under separate hosting requirements.
As shown on Wikipedia.
Project owners do not have the freedom of deleting their submitted projects on their own wish and the staff has a policy of refusing all deletion requests, unless the project was approved by mistake or has always been empty.
So I think the name Libreboot was not trying to be taken from anyone, though I did not research that yet, like the darknet is not being taken when hosted on any site, but only that a fork using the same name, even a hard fork could be made.
As forks can be made by anyone, as I thought that was what was done with free software.
Even if people like the program that was forked better than the first program.
If anyone, posts/hosts a program on on the "officially part of the GNU Project" I thought it will be controlled by GNU, but the nongnu part will still be controlled by the poster.
Though both may not remove the program as I see In order to preserve history and complete transparency, we will not remove projects with substantive content.
I do not know much about posting there, or anywhere, though.
If any law was broken, maybe a court case could be opened. But if court cases are opened against anyone who tries to fork Libreboot, than it may make Libreboot look like non-free software and people may not wish to even copy the code. So as not to be called a thief.
Maybe that is why a pull/push(?) I think, I do not use git much, may not be done by some people for even patches, so as not to be called a thief for using the same name.
I do not know how to get started working with any free software project, but I did not think it was against the law to use the name Libreboot.
What should anyone forking Libreboot call the fork so as not to be taken to court by the Libreboot developers or called a thief by them, as that may surprise people who wish to fork GPL licensed things?
Even companies may not wish to be called a thief for trying to fork Libreboot, as even I did not think that was what using the name Libreboot would get any called a thief.
If there is proof of GNU/FSF breaking a law anyone should show that, or that could be thought of, even if not true, as defamation by some upstream developers against GNU/FSF or maybe the other why around. I'm not a lawyer.
Though I do not think much of any reputation, so not many if any thing, will at this time be thought of as defamation by me.
A nice public discussion could help explain what, if any, problem with using a name caused. Maybe just a misunderstanding, not the GNU/FSF or Libreboot developers meaning to cause any problem intentionally.
I'm not a lawyer, though I really do not wish to be sued for just using a name.
I may not wish to fork or use any software if it can quickly get me taken to court or called a thief by the developers.
Though I hope "your people" does not mean every user of free software. I was not a part to any of this, as also many others are also not part of this.
If I use/fork software I may use fork/use software that is not likely going to get me called a thief, or taken to court.
How can I work with any free software project without being called a thief or being taken to court?
I could try working with developers of any free software project, though I really do not wish to be sued or thought of as a thief.
I also do not wished to be sued by non-free software projects made by Intel, or other companies when trying to get GNU boot to work with more computers.
Though I see in the GNU boot repository at
https://git.savannah.gnu.org/git/gnuboot.git
All new coreboot development should be done in coreboot (upstream), not
GNU Boot. For example, if you wanted to add a new board to GNU Boot, you
should add it to coreboot first. GNU Boot would then receive your code at
a later date, when it updates itself.
and also at
https://en.wikipedia.org/wiki/Coreboot
that there is reverse engineering efforts on firmware-specific problems
it is mostly done with NSA made Ghidra, but that also has in
https://github.com/NationalSecurityAgency/ghidra
## Security Warning
**WARNING:** There are known security vulnerabilities within certain versions of Ghidra. Before
proceeding, please read through Ghidra's [Security Advisories][security] for a better understanding
of how you might be impacted.
Maybe Radare2 would work better, so backdoors are not put in the binary blobs that run when using Coreboot and Libreboot.
Though backdoors may already be run with blobs used by Coreboot and Libreboot, as those may (I think) run binary blobs somehow.
https://en.wikipedia.org/wiki/Radare2
I see GNU Boot and many other things are mostly started/pulled/pushed from upstream.
Though as upstream Coreboot developers and Libreboot developers do work around non-free software(maybe slowly removing/(not using) non-free software or putting/using more non-free software in it), and with "maybe even freeish software/free license but only binary code, no source" I do not know the best way to avoid legal/technical/trademark problems to get GNU Boot or Canoeboot working on more computers.
I'm glad upstream/these_4 likely know how do avoid getting sued and/or cracked when working around non-free firmware/software, though I do not yet.
I have never heard that "Libreboot" is trademarked, that reusing that name is against the law or that there has been any suit threat. Unless you bring references, I will keep believing none of that is true.
On one hand, it is confusing that a project named *Libre*boot includes blobs. On the other hand, having a fork under the exact same name confuses the users too... and it is what trademarking would help to avoid. Trademarks are compatible with free software, as long as the related policies are not overreaching (adding restrictions to the distribution of exact copies, in particular). The free software definition even specifically says it is OK to impose a change of name/logo for derivative works: https://www.gnu.org/philosophy/free-sw.en.html#packaging
In my humble opinion, it is understandable (even expected) that the author of the original project will bitch those behind a fork that reuses the same name. Here, the fork has been renamed GNU Boot. Case closed.
When I saw Your people initially tried to steal the name Libreboot for their own project
I thought libreleah was typing about something that was not legal.
I also saw I speak plainly and honestly so that could also be why I thought of it as a statement of fact about theft of something.
I do not think having a fork with the same name may confuse most users, as users can also see the repository and/or the website, to see who made what.
Like if there was libreleah's pizza and GNU's pizza I could see who made what, even though pizza was the same name, as the website would not be the same, and so the pizza may or may not be the same.
I also did not wish to make any "hostile-fork" of upstream code, though I did not think using the same name would be called a hostile-fork.
Maybe there was more to it than just the same name. I do not know much about the months-long dispute with the Free Software Foundation which oversees GNU.
https://en.wikipedia.org/wiki/Libreboot
I see at the link you, Magic Banana, typed
A special issue arises when a license requires changing the name by which the program will be invoked from other programs. That effectively hampers you from releasing your changed version so that it can replace the original when invoked by those other programs. This sort of requirement is acceptable only if there's a suitable aliasing facility that allows you to specify the original program's name as an alias for the modified version.
So seeing GNU Boot can work even with a name change, it even can comply with that policy.
Does anyone have information about how to not make a free software "hostile-fork" type of fork, but a nice fork for any free software project?
>"Does anyone have information about how to not make a free software "hostile-fork" type of fork, but a nice fork for any free software project?"
My understanding is that the proper and courteous thing to do is to contact the developer of the original project and offer them a pull request with the changes you would like to make. If they deny your pull request, then you could make a fork, being sure to credit the work of the original dev and being sure to follow the license requirements. I've only gone through the process once, and my pull request was accepted, so there was no need to fork.
In cases where the original developer has clearly abandoned their work on the project, with no commits for a lengthy period of time, my understanding is that it would be proper and courteous to try to contact the dev if possible and discuss taking over the project or forking it to a new name. If they are hostile to the idea of you taking over the project, then you would still have the option of forking it if the license allows that.
These are just general ideas of courtesy and respect among devs that I've heard about, and they probably aren't followed this way in all cases.
Thank you for the information, andyprough.
I did not know what was the best or customary way of making a fork among devs.
I saw some forks like darknet and some minetest mods that use the same name, but I did not know if that way the customary way of doing a fork.
I think credit the work of the original dev and being sure to follow the license requirements was done, but I did not know if this was the way it was normally done.
I think the minetest mod names, like smart shops, have forks under the same name so as to be compatible with the craft recipes to make them, so as not to need a replacement in code of all the other mods that use them.
But forking it to a new name could also work if a large amount of other programs that use it did not need the name of the program to be the same name.
I think an alias for the modified version could also work, but like you typed talking about it to the developers who are working on the first project first may be a nice idea.
And also talking to anyone who may be using that name for anything in their program, so as not to need a code change in those developers code.
https://www.gnu.org/philosophy/free-sw.en.html#packaging
Somewhat like Trisquel has packages from other developers, but may have some changes from upstream in the Trisquel programs.
Here are the links to the shops forks pages
https://content.minetest.net/packages/AiTechEye/smartshop/
https://content.minetest.net/packages/rheo/smartshop/
at least 2 of them.
>"I saw some forks like darknet and some minetest mods that use the same name, but I did not know if that way the customary way of doing a fork."
I think game mods would be a different matter. Like you say, they might need to have a certain name so that the rest of the game can call on them. But also, game mods, if they are anything like icon packs and themes, may have a different kind of license like a version of the creative commons license. The productivity software that I am used to modifying would be under a license like the GPL most commonly.
I see in the book
Producing Open Source Software: How to Run a Successful Free
Software Project
by Karl Fogel
Copyright © 2005-2018 Karl Fogel, under the CreativeCommons Attribution-ShareAlike (4.0) license.
Version: 2.3098
Home site: http://producingoss.com/
Sometimes a fork becomes so successful that, even though it was regarded even by its own instigators
as a fork at the outset, it becomes the version everybody prefers, and eventually supplants the original
by popular demand. A famous instance of this was the GCC/EGCS fork. The GNU Compiler Collec-
tion (GCC, formerly the GNU C Compiler) is the most popular open source native-code compiler, and
also one of the most portable compilers in the world. Due to disagreements between the GCC's official
maintainers and Cygnus Software,11 one of GCC's most active developer groups, Cygnus created a fork
of GCC called EGCS. The fork was deliberately non-adversarial: the EGCS developers did not, at any
point, try to portray their version of GCC as a new official version. Instead, they concentrated on mak-
ing EGCS as good as possible, incorporating patches at a faster rate than the official GCC maintainers.
EGCS grew in popularity, and eventually some major operating system distributors decided to pack-
age EGCS as their default compiler instead of GCC. At this point, it became clear to the GCC maintain-
ers that holding on to the "GCC" name while everyone switched to the EGCS fork would burden every-
one with a needless name change, yet do nothing to prevent the switchover. So GCC adopted the EGCS
codebase, and there is once again a single GCC, but greatly improved because of the fork.
so GCC/EGCS fork went from GCC to EGCS than to GCC. The fork was deliberately non-adversarial
Though I think the LibreBoot fork was not intentionally adversarial.
So maybe Coreboot(with blobs) to Libreboot(with blobs) to GNU Boot(without blobs) to Canoeboot(without blobs) may be like that
The Canoeboot becomes so successful that the name Gnu Boot name like the GCC/EGCS fork names
that holding on to the "GNU Boot" name while everyone switched to the Canoeboot (if the Canoeboot fork is thought of as better) fork would burden every-
one with a needless name change, yet do nothing to prevent the switchover
It may be that GNU Boot may adopt the Canoeboot codebase, and there is once again a single GNU Boot(without blobs), or something, but greatly improved because of the fork.
Though that will likely take time to see what is better. Or what may happen, maybe both names will be used.
I do not know if EGCS had or used any binary blobs like Libreboot used though, as that may also be why the fork was made in the first place.
https://web.archive.org/web/20240224003004/https://www.gnu.org/software/gnuboot/web/
I think people did not know if the blobs had a backdoor or worse could get them sued by Intel or others for copyright infringement.
I hope all parties involved in the making of free software can have friendly discussions, or at least not have too large of a problem even if others may make "adversarial" forks.
As the programming skill of the programmers can show who made the best things for each person.
Maybe a fork will work well for some people but not for everyone.
I am a translator!
Canoeboot advertises having a patched GRUB that supports argon2id, allowing to have encrypted /boot, but this wasn't tested with Trisquel, there are no step-by-step instructions to do it and this is a version of GRUB not supported upstream, so it looks like an experimental feature that one would rather not use on a computer expected to boot reliably at all times.
Apart from the support of the Dell E6400, I don't see any clear advantage of Canoeboot over GNU boot.
However, if there would be any problem affecting Trisquel with Canoeboot, but not affecting Debian that Minifree installs by default, I don't know whether the maintainer would provide support.
I am a translator!
.