On Thu, 24 Mar 2022 06:47:34 -0400 bill-auger <[email protected]> wrote:
> several people have asked about this since 'jami-gnome' was > removed from arch - this post is for the sake of a shared "TLDR" > reference Thanks a lot for the reference. I really hope that at some point we will be able to really know the license of chrome/chromium based source code to solve this for good and/or bury chrome/chromium for good and have compatible API and/or other browsers backends instead. > the chromium web browser is on the "List of software that does > not respect the Free System Distribution Guidelines" wiki > page[1] - the presence of any software on that list, prevents > any distro from being endorsed by the FSF, if it distributes any > of the software on that list, without applying an accepted > liberation procedure; and puts the ongoing endorsement in > jeopardy for any distro which later accepts any of them > un-treated - currently, the only accepted liberation procedure > for chromuim is: "use icecat" The issue with that page is that it's not well maintained. Some information there seem really old and many packages are probably missing. We probably need people to help with that. > as far as i have been able to determine, this issue affects all > web browsers derived from chromium, simply because no one from > any of the popular forks i have looked at (such as > ungoogled-chromium and iridium) has claimed to address any > licensing issues (those projects address only privacy issues) - > also, this issue most likely affects all software which > includes, or is derived from chromium, qt-webengine, or electron That also doesn't seem very relevant by itself: if the issue is fixed upstream, browsers will probably not mention that they did address licensing issues. However as I understand it's really hard to know if it's fixed upstream or not given the huge amount of code and repositories. Android has a similar issue, so we probably need to collaborate in fixing that type of issues in some ways. As I understand, in both cases the build system doesn't have any package definitions and the build outputs aren't packaged in any ways. Instead all the source code is checked out in the same directory and everything is built from that. Though Android somehow generates a license list that is available in the settings. For Replicant 11 I've started making a quick and dirty script to find out the licenses of each repository but I need to improve it, try license scanners, etc. I also plan to document these tools in the libreplanet wiki at some point. When making packages, we really need to indicate the license under which the package is, and different distributions probably dealt with that more or less strictly in the past depending on the distribution. For instance Debian has a reputation of being strict and of finding and removing nonfree software from within packages they have in their main repository. So we can often find information there on new nonfree software being added to various projects. Finding nonfree code is probably also related to the will to do it and also the huge amount of Debian developers compared to other distributions (that we lack in Parabola for instance). I really wonder how distributions dealt with code of unknown licenses in the past. Did they simply remove the packages if the license was unknown. Are there situations in the past where the distribution wasn't under pressure of having something important not working? Do we have precedents where most distributions removed software because of mess like that? I recall that at some point we removed some OpenGL headers in Gnewsense and that at the end the FSF managed to make the author of these headers relicense them under free software. Could we somehow build pressure to have Google make sure that the code is at least legal to redistribute in ways that we can check? > some have tried[12]; but it is > probably never going to be completed satisfactorily - electron > seems to a hopeless cause for distros[8]; so the only reasonable > project to consider, is qt5-webengine - that is fortunate, > because qt5-webengine is used by hundreds of programs, making it > the one of the three with the greatest impact on distros, by far > - to focus on chromium would require orders of magnitude more > work, only for that one extra program We also need to take into account the maintenance of the license checks. We probably don't have enough time and people to review some source code based on chromium for each releases of that code. The ideal situation would be to have that software packaged as it is usually done: by having 1 package per dependency. But here that would probably mean packaging several hundreds or thousands of projects just for a browser that isn't even desirable. And these packages would also need to be maintained. Another option would be to somehow automatize the license checks with license scanners. I also wonder if we can somehow force Google to do that work? Like if there is a lawsuit for instance, would there be a way where it would be up to google to tell us the license and show to us (for instance in a document that shows the correspondence between licenses and files) that they didn't violate any free software license? Also did someone already try to work with upstream to somehow force upstream to put in place a process (similar to process in distributions) where the license are reviewed and licensing information is updated? Or did someone already discussed with upstream about the possibility of doing that? Denis.
pgpMDGyhZPAUu.pgp
Description: OpenPGP digital signature
_______________________________________________ Dev mailing list [email protected] https://lists.parabola.nu/mailman/listinfo/dev
