Re: [GNU-linux-libre] license of 'yggdrasil' software
7;t help being driven by my conscience, and I struggle to imagine how someone could possibly ever expect that reinforcing a cancellation supported by lies could possibly serve a cause that's effectively inseparable from the target. But I suppose this is all OT here. A true politician probably would refrain from even posting this, for reasons I can't foresee. > - ok, ill bite - how long should a reasonable person wait? - another 5 > years? - that is already how long the FSDG process has been stalled Just waiting is really not ideal indeed. I mean, adding pressure on the FSF doesn't help solve the problem, but maybe resources and efforts that would otherwise be idle could be directed to solving the problem, rather than just waiting. I'm not even talking of each one's looking into the matter and deciding for oneself, though as proponents of autonomy, that should always be a fallback last-resort possibility. But maybe picturing the FSF as yet another volunteer in the movement (taking its self-imposed legal mandate to do so along the same lines as equivalent to the self-determination of most of our human movement supporters) and helping it carry out the jobs we expect of it would be a more helpful way to frame it? I don't know a solution and I haven't talked to the FSF about it, but perhaps there are ways to offer help to the FSF on this matter, help that would enable the situation to be resolved. Thinking a little outside the box, maybe crowdfunding to commission an attorney to look into the issue and provide the FSF with the needed legal opinion? Encouraging lawyers knowledgeable in the field to volunteer their help to the FSF? Asking the FSF what it needs and how we could help it solve this problem? I suspect such approaches might be more fruitful than calling it out. > that would be a reasonable statement, except that the position > _was_ occupied during the first two years since the FSDG process > has been stalled - i started stating and re-stating the problems > which need attention, while the position was occupied I see. That changes some past facts, suggesting there might have been ways to avoid the present situation (though I'm not aware of the facts at the time). But that didn't happen, and given that, this information doesn't seem to help us find a solution for the present situation, does it? I mean, I don't wish to invalidate, dismiss or grow your frustration. It is understandable. My focus is not on finding out or exposing whoever was behind it and could possibly be held accountable for it. That doesn't seem very useful to me, given how much everything has changed. I'd much rather focus on finding steps that could be taken now towards solving the problem. Thanks for listening, -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>
Re: [GNU-linux-libre] review of uruk
Hello, Ali, On Mar 24, 2023, alimiracle wrote: > These requirements were developed in order not to use repositories > from non-free distributions I don't speak for the FSF and I don't know exactly what motivated the inclusion of this requirement in the FSDG, but I can think of reasons that go beyond what you suggest above: - free distros need to take responsibility for what they recommend and offer to users, outsourcing that responsibility to third parties, even ones committed to observing the same rules, is a potential pitfall when an upstream distribution changes its own alignment. A free distro must be able to fix freedom problems itself, without depending on a third party to do so. - if an upstream distribution changes its alignment, the downstream distro may find itself needing to urgently find hosting for a sizable repository. that creates a potential conflict of priorities. it pays to work on that ahead of time. - self hosting one's own computing and data sets a good example for the community at large. the growing disregard for this aspect of computing autonomy in parts of the larger free software communities is a serious problem that drives a lot of people into behaviors that promote dependency rather than freedom. There is likely a lot more, but these are ones that come to mind immediately. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>
Re: [GNU-linux-libre] license of 'yggdrasil' software
the recommendation to refrain from distributing the package identified as a potential problem seems as sound as it can get. Otherwise, redistributing under the GPL packages received under the GPL, in compliance with its terms, can probably be counted on in general. > if i did not enjoy working on parabola so much, if i were doing > it only "for the cause" (the FSF's cause) I wouldn't put it that way. It's our movement, our cause. The FSF is an important part of the movement, but I don't see that it "owns" the cause. When we volunteer our efforts to the movement, even when it's some activity the FSF organizes, we do (or IMHO should do) so for our own collective sake. Still, I can relate with your dissatisfaction, and share in the lamenting that this has been so. I appreciate your sustained efforts and dedication to the cause, and thank you for them. I also appreciate the FSF's, and thank it for them. Our movement has been through some particularly challenging times, and I hope we can keep on counting on your support, tolerance and patience with these difficulties a while longer. Restating demands that still can't be met due to circumstances that are outside the control of the demanded party, or adding to the pressure about them, unfortunately neither fills the position nor qualifies other staff to issue the legal opinion that would back the demanded statement. Even after the position is filled, there will surely be quite a backlog to go through, so please bear with them. Thank you very much, -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>
Re: [GNU-linux-libre] license of 'yggdrasil' software
On Mar 13, 2023, bill-auger wrote: > On Mon, 13 Mar 2023 16:03:29 -0300 Alexandre wrote: >> > me - isnt this effectively granting permission to proprietarize >> > the (supposedly) LGPL library? >> >> How's that fundamentally unlike the LGPL itself, allowing (as an >> additional permission over the GPLv3) its code to be included in a >> program that is nonfree? > it is different, because the LGPL ensures that everyone can get > the source code yeah, but the GCC Runtime Exception, for one (another set of additional permissions) doesn't, and AFAIK that's never been thought of as being in conflict with the FSD or the FSDG. (Some hold a mistaken belief that software under pushover licenses does not fit the FSD, but such licensing arrangements don't conflict with the requirements of the FSD.) > this is problematic, for example, because i noticed that > archlinux (and therefore parabola) and debian (and therefore > trisquel and pureos) denotes this license as 'LGPL' ISTM that it follows that Arch [GNU/]Linux took up the permission granted by the GPL, and thus by the LGPL, and dropped the additional permissions, so the license that remained is indeed the LGPL. That is in line with the permissions, and it removes any of the doubts you appear to have with the license with additional permissions. The copyright holders have permitted the distribution of the software under the LGPL, and some distros are doing so, and including the corresponding sources, so it is indeed Free Software. So what is the issue? It seems to be a non-issue to me. > the same is true for 'nmap' - those distros give the license as > GPL2, where is definitely is not = the license itself explicitly > declares that it is _not_ the GPL2 - yet most people believe > that it is That is slightly more problematic or convoluted, because the GPLv2 does not have GPLv3's wording that explicitly permit dropping the additional permissions and distributing the software without them. Because of the wording of the GPLv2, however, it is often understood that modified versions of the GPLv2 that attempt to add permissions or even restrictions while retaining the original wording do indeed grant permission for the program to be distributed under the GPLv2, so one could conclude that those who name GPLv2 as the license have relied on that permission. Once again, the result appears to be a program distributed under GPLv2, with corresponding sources. What is the problem, then? (again, I haven't looked at specifics of the nmap licensing arrangements, I'm speaking in general terms, IANAL, and I don't speak for GNU or for the FSF) -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>
Re: [GNU-linux-libre] license of 'yggdrasil' software
Hello, Bill, I haven't looked at the license, I'm responding about a general situation, that I'm familiar with, rather than the specifics of this case. Also, please bear in mind that IANAL, and I don't speak for GNU or for the FSF, I'm only sharing my (somewhat informed) understanding of these issues. On Mar 13, 2023, bill-auger wrote: > the license > embeds the entire GPL license (LGPLv3 in this case), but with an > addendum, which cancels some of the GPL most important terms - > this one allows statically-linked binary distribution with no > obligation to provide any source code nor support for > re-installation These are additional permissions indeed. Some activities that are not allowed by the LGPL alone, and that depend on permission from the copyright holder, are allowed by this other license. It doesn't take freedom away from the licensees. It adds to the actions the licensee is permitted to take. Yeah, in these cases, it allows licensees to constrain the activities that downstream recipients might be allowed to take, to the point that the software may reach those downstream recipients as nonfree software. But all this means is that this is not a copyleft license. It is still a free software license, because all of the freedoms are respected, as much as in the original license: you, as a licensee who receive the software under its original terms, can still do everything that the LGPL allowed you to do, and then a little more. Other downstream recipients may not be so lucky, depending on intermediaries. That's not entirely unlike pushover licenses, and even weak copylefts. It's exactly how additional permissions under the GPL were designed to operate. Indeed, the LGPLv3 is just such a set of additional permissions. > my main question is this: doesnt the removal of the obligation > to provide source code, and also the removal of the ability to > re-install the LGPL library (aka: tivoization), amount to added > restrictions? No, it's a permission (you're allowed to, as in you're no longer forbidden from), not an obligation or a restriction. What's more, under the terms of additional permissions, you're allowed to drop them and distribute the software under the license without those additional permissions. If that respects your freedom (and it does), how could allowing you to do even more no longer respect your freedom? > me - isnt this effectively granting permission to proprietarize > the (supposedly) LGPL library? How's that fundamentally unlike the LGPL itself, allowing (as an additional permission over the GPLv3) its code to be included in a program that is nonfree? > understanding why anyone would choose the GPL, only then to > remove the unique provisions which distinguish the GPL from > permissive licenses Some reasons that come to mind are to begin from a known and familiar starting point; making it crystal clear that combining the program with GPLed software is permitted (though the additional permissions may have to be dropped), pretty much ensuring contributors keep it that way; leaving no doubt that redistributors can behave just as they would under the GPL, even to the point of being allowed to redistribute the work, with or without modifications, under the GPL (or, as in this case, also under LGPL). The additional permissions are of no concern for themselves unless they would like to do those things, which freedom-respecting distributors normally wouldn't want to do anyway. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>
Re: [GNU-linux-libre] Good practices for removing nonfree code found in source code.
On Oct 1, 2021, "Denis 'GNUtoo' Carikli" wrote: > What are the best practice to fix cases like u-boot or fix other > nonfree code found in free software source code for the various FSDG > compliant distributions? IMHO the platinum standard to aim for, of not participating in the distribution or promotion or endorsement of nonfree software, involves not carrying the nonfree bits in our own source or packaged repositories at all. The way GNU Linux-libre used to deal with it was to publish cleaned up tarballs, without history, and binaries built out of them. More recently, we've started publishing a git repository with cleaned up sources, still without history: each one of our releases is an initial commit. These approaches have the advantage of ease of withdrawing releases found to be problematic without affecting even subsequent releases that are ok. Without history binding them together, each release can be handled independently. OTOH, the loss of commit history, though acceptable from the FSD compliance POV, is undesirable for various oher reasons. So we're now working on a git repository rewrite that carries history but removes nonfree software and other objectionable bits from the point of introduction. It's a parallel-universe history, in a way, but with git commit mapping, one could even use the rewritten repo for upstream development. We haven't quite worked out how this is going to work, but the goal is that, as commits as added upstream, they can be incrementally verified and integrated, in a mostly automated fashion. If/when we find a freedom bug in a previously-accepted commit, we'd have to re-rewrite that commit and all subsequent ones. Given some script along the lines of deblob-check, the checking-and-integration is mostly automatable. Once I grow up code for progressive integration of commits, I shall turn that into a free software project so that others can use it to maintain freed-history repositories of other blob-ridden projects. In case anyone has already done anything along these lines, I'd definitely be interested in having a look, and probably building upon it and contributing to it. All this said, it doesn't seem to me that this platinum standard should be a requirement for FSDG compliance. E.g., we don't seem to require projects to withdraw all past releases upon finding a freedom bug. For compliance, fixing the bug and issuing updates with the fix appears to be enough to meet the requirements. More than that, though IMHO desirable, appears to be beyond what could (should?) be considered as mandatory, given what's reasonably doable with existing tools. Maybe with newer tools that make the process of cleaning history more convenient, we can eventually bump the requirements. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>
Re: [GNU-linux-libre] linux ppc micropatch.c: why keep it?
On Aug 31, 2021, Jeff Moe wrote: > In the end, I didn't use gNewsense's tools, nor review their work. Thanks, that's useful information, that makes it clear I misplaced trust on the double-checking I had assumed. > I *started* to go thru their kernel, but it was false positive after > false positive, since they had been using the Ubuntu kernel, not the > Linus kernel. Well... AFAIK Ubuntu backports drivers and stuff, but I don't know that they integrate stuff that isn't going to eventually get merged, so recognizing false positives present in their kernel versions may not be useful for corresponding upstream release, but it's likely that it would be useful for subsequent upstream releases, so it wouldn't be wasted work if automated. IIUC you did that mostly manually (an heroic job IMHO; I can't ever thank enough you and others who went through it), though, so... Yeah, frustrating and pointless. > I should also point out, I'm a sysadmin, not a kernel programmer or > gcc maintainer or anything like that. I'd never state a kernel "ground > truth"! Fair enough. I hope you don't mind that I trusted your review though. Trust and verify, as they say. What I saw when I took up Linux-libre was so solid that after enough double- (triple-, I thought then) checking, I came to believe it was correct. And, despite this one mistake, and your clarification, I still place a great deal of trust in it, and would face a hard time challenging analyses from back then. >> I'm now inclined to believe that leaving this file alone was one >> of very few mistakes (perhaps the only one) made in the initial >> cleaning-up, > If I only made one mistake in the initial release, I was lucky! ... and modest, after doing such a superb job ;-D Thank you very much! -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>
Re: [GNU-linux-libre] linux ppc micropatch.c: why keep it?
On Aug 24, 2021, Jeff Moe wrote: > Hi Alexandre, it looks like you BCC'd me to a list post. Indeed. Sorry I didn't say so explicitly. > https://lists.autistici.org/message/20080221.002845.467ba592.en.html > It does not mention the CPM code. Exactly. It mentions bits that were removed. The ppc microcode was retained, so it wasn't mentioned. It must have been flagged by find-firmware, though. The important question for me was why it was retained. I figured there was a good reason for that. Though I used to take gNewSense's review double-checked by you as ground truth, I'm now inclined to believe that leaving this file alone was one of very few mistakes (perhaps the only one) made in the initial cleaning-up, and that we've been carrying over under the assumption there had been good reason to keep it. vs6624_p1 in vs6624.c seems to have been another such mistake, tough this one I made myself, and I'm about to correct it. I'm also asking for broader opinions on arch/parisc/kernel/perf_images.h and on cx11646_fw1 in drivers/media/video/gspca/conex.c. The former looks like data rather than code, so it could be fine, but though the file states GPL, it also states it was borrowed from HP-UX. The latter amounts to 64 bytes of firmware that could very well be code (though it might as well be pure data), and it's so small that it is believable that there's no other source form. Both have been retained over several releases, but since I've made mistakes myself, and I'm respinning releases, and working on the git history rewrite, I thought it would be a good time to revisit these if needed. Thanks, -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>
[GNU-linux-libre] linux ppc micropatch.c: why keep it?
When I got involved with Linux-libre back in 2008, a file named
micropatch.c already existed in the Linux source tree, in
arch/powerpc/sysdev/micropatch.c. It's now in
arch/powerpc/platforms/8xx/micropatch.c.
The initial version, added back in 2007, had two sets of binary
"patches". Comments stated:
/* Microcode patches for the CPM as supplied by Motorola.
(CPM stands Communication Processor Module)
Despite the appearance that these "patches" could be code rather than
configuration data, gNewSense (and then BLAG) appear to have decided
that it could be left in, for reasons unknown to me. I assumed there
were good reasons for that, even though I didn't know them, so the
binary "patches" have remained in Linux-libre releases since then.
For most of the time, they've remained unchanged, except for
reformatting of the arrays containing them. Back in Jun 14, 2019, a new
set of binary "patches" were added. It was quite similar in appearance
and spirit, so I also retained it, assuming the same reasons applied.
Part of the commit message that introduced the new bits states:
This microcode is provided by Freescale/NXP in Engineering Bulletin
EB662 ("MPC8xx I2C/SPI and SMC Relocation Microcode Packages")
dated 2006. The binary code is public. The source is not available.
Recently, someone asked in the GNU Linux-libre discussion list why we
didn't remove these bits. I don't know the answer. I wish I did. I
find myself wondering whether it should really have been left alone.
Does anyone have any insights to share as to why this might have been
left in? Absent more information, if I were to come across it today,
I'd most certainly have removed it from Linux-libre, so I'm leaning
towards doing so in the git history rewrite project I've been slowly
working on.
thanks in advance for any information you may provide,
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about <https://stallmansupport.org>
Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.
On Feb 16, 2019, Marius Bakke wrote: > Despite years of searching, I have not found any proprietary parts in > first party code! Could you please summarize what you did in your searching? Maybe you have actually completed the steps that were missing in the auditing or Chromium to conclude it's Free, or at least some of the remaining tasks can be checked off. -- Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain EngineerFree Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe
Re: [GNU-linux-libre] PureOS added to endorsed distro list - what about the kernel?
On Jan 20, 2018, bill-auger wrote: > i must say though that it did not address what is the actual > behavior preventing the debian kernel from being acceptable, I didn't try to address that, and I'm afraid I don't know the answer myself, not having looked at the Debian kernel in detail any further than to get slightly acquainted with the general approach. I'm told it is Free Software, which is good, but I had got the idea that it did not meet the GNU FSDG until PureOS, AFAIK carrying the (Debian main only?) bits of the Debian kernel, made the endorsed distro list. I'll defer judgment and clarification to the FSF. If I had to guess, I'd say the fact that the distro controls the hotplug script, the repositories, the package installer, and whatnot, places them at an advantage over what we have to do in GNU Linux-libre to ensure it behaves within the FSDG, and maybe the requesting and logging of firmware, even non-Free, is not deemed a problem because the other system components take care of them, and the non-Free bits are not available for installation anyway, unless other repos containing those bits are configured. But that's just a personal guess. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Re: [GNU-linux-libre] add uruk gnu/linux
On Jan 20, 2018, bill-auger wrote: > the purism situation is notably different from that and when i saw > that the pureos website makes no mention of the puri.sm repos, i > decided that there was no problem with that Indeed, thanks for bringing that to my attention. I had not realized pureos had its own separate website, and for some reason I'd assumed all of pureos was right there next to the nonfree repos I linked to (so much for my not leading people towards non-Free Software :-) -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Re: [GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)
On Jan 27, 2018, bill-auger wrote: > the scripts are based on a fedora v20 target system and require packages > from corresponding versioned repos on fedora, freedora, and also a > native blag repo - the fedora archives are still available but the > oldest available freedora repo is v25 so that had to be the minimum > target Would you like me to dig up the Freed-ora 20 rpms and the blag-specific rpms from backups? > it would apparently not be possible to build blag (v.N+1) from a > running blag (v.N) - i mention this because arguably this does not > meet the FSDG self-hosting requirement I can imagine it would be convenient, but I guess these scripts are supposed to run within a mock buildroot or somesuch, as a last stage in building the release's live and install images. The buildroot is populated with packages that have already been built or imported, in the corresponding repositories. The rpms in there are also built within mock buildroots or equivalent, so it's all really self-hosted: the buildroots and the build host running mock can be running different versions, or even different distros. > where i last left off, i got it to progress as far as the package > loading phase when it choked on a package missing from the freedora > repos named something like: 'linux-kernel-firmware' - perhaps this is > just a renamed package - i have not looked into it any further kernel-libre-firmware used to be built as part of kernel-libre, but since 4.14-gnu (-ENOFIRMWARE) it was removed, since there was nothing left. I intend to build jxself's linux-libre-firmware to take its place, but I haven't done that yet (vacations were too short ;-( :-) However, kernel-libre-firware *is* available in the Freed-ora 25 repos: that repo was discontinued before getting any 4.14 builds. So it's weird that the package couldn't be found. Freed-ora 26 repos, OTOH, only have 4.14 builds left, so you might expect this sort of error there. You sure you tried 25, not 26 or 27? I guess whoever decides to take up blag will have to sort that out. Hopefully I'll have a newer kernel-libre-firmware in place by then... -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Re: [GNU-linux-libre] PureOS added to endorsed distro list - what about the kernel?
On Jan 16, 2018, Adonay Felipe Nogueira wrote: > What if for example the kernel wouldn't reference stuff by file names, > but instead to bus address or something like that? It's not just about the error messages, it's also about what the kernel actually requests of the userland helper script or the filesystem serving /lib/firmware, and how distros might configure the loader or the filesystem to respond to such requests. When the kernel starts the helper script, it's active telling a third-party program "get me a copy of the program foo.bin". The idea that Jason referred to was of one-way hashing blob names, and having the loader script hash available firmware names until it found one that matched the request, or until it exhausted the list. Problem is, distros could still pretend to have plenty of files available (based on what's in the repos), and make the whole set visible to the script, even if stuff would only be installed on demand, if actually requested. This may have seemed far-fetched back when distros just supplied scripts that would search repos and offer to install firmware requested by the kernel but not installed, but more recently, the kernel is moving away from the userland hotplug script and accessing /lib/firmware directly, and so distros willing to retain such functionality are going to mount /lib/firmware as a userland filesystem serving out the complete set of firmware and installing, or offering to install it, when the kernel actually requests the files. So our hashing would have to be done elsewhere, and even then it wouldn't stop the script/filesystem from installing stuff that was not installed. Even if we turned the table around and changed the kernel so as to ask for a list of available firmware before asking for any blobs, and only requested blobs that were in the list, we would be defeated by this filesystem: enumerating the (apparently) available files would make it seem like all blobs are actually installed. There doesn't seem to be a way to avoid what we're trying to avoid while still allowing proprietary firmware to be loaded, so... we don't allow it. It's still a bug, but apparently an unfixable one. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Re: [GNU-linux-libre] PureOS added to endorsed distro list - what about the kernel?
On Dec 23, 2017, "Jason Self" wrote: > My understanding is that there is an idea for how to > enable the loading of the proprietary firmware without also steering > people to it when it's not present. That idea unfortunately proved to be insufficient for scenarios in which e.g. a (user-hostile) distro pretends all sorts of proprietary firmware are installed just because they're available as packages, and once the kernel actually requests them, offers to install or goes ahead and installs the proprietary firmware for the user. I've heard of distros that intended to do such stuff, so RMS and I agreed we shouldn't implement that any more. GNU Linux-libre is supposed to do its job even if installed on such hostile distros. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Re: [GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)
On Jan 17, 2018, bill-auger wrote: > blag actually has no software available - the download links on their > website have not worked in a very long time because (as ive heard) the > files were lost The server was broken into and then brought down, IIUC. There are backups, so nothing was really lost, but for some reason the server has never been reinstalled and brought back up to make the files available for web download again. I think they might still be available as torrents, if one can find a seeder. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Re: [GNU-linux-libre] add uruk gnu/linux
On Jan 19, 2018, Robert Call wrote: > For example, PureOS was added to the endorsed distro list even with > several long standing issues (mainly the usage of the debain kernel > which advertises missing non-free firmware blobs). ConnochaetOS[1] was > submitted for review was denied based on the fact that they were using > the Debian deblobbing scripts vs. the linux-libre deblobbing scripts. > Is this fair? It certainly sounds odd. But, honestly, right now I'm more concerned that updates for PureOS seem to have been published in a non-free repo. Specifically, non-free microcode for CPUs affected by Spectre. Surely we don't mean to endorse distros that do that, do we? Purism's messaging seems to attempt to distance their new nonfree repos and dists from PureOS, but... I fail to see the difference between that and what Debian does. But then, I haven't looked very closely. Am I missing something? https://puri.sm/posts/purism-patches-meltdown-and-spectre-variant-2-both-included-in-all-new-librem-laptops/ https://deb.puri.sm/pureos/dists/purism-nonfree/ https://deb.puri.sm/pureos/pool/non-free/i/intel-microcode/ Thoughts? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Re: [GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)
On Jan 19, 2018, Caleb Herbert wrote: > wouldn't dropping them from the list act as a wake-up call > to hurry up? Maybe that would be too drastic. After all, even if old and unmaintained, it's still Free Software. Perhaps we'd be better off breaking up the section of self-hosted distros into multiple sections, so that there could be one section for Live distros that are supposed to be used in read-only media and don't get updates, like dyne:bolic and Musix, and one for distros that are in need of contributors to issue newer releases and even updates like BLAG. The latter section would be the wake-up call, and if a distro remained too long in there, then it gets removed. It would also get users better information, and avoid giving users the idea that distros in the list are outdated just because they hit the one or two that really are. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Re: [GNU-linux-libre] Reviewing ConnochaetOS
On Aug 6, 2017, Henry Jensen wrote: > RMS mentions a change "to obfuscate the names of the firmware files" > instead of failing. Yeah, he was referring to the "Request for Comments" section at http://www.fsfla.org/anuncio/2010-03-Linux-2.6.33-libre > Last time I checked, the situation hasn't changed, It has changed a lot, actually, but not exactly in a favorable way. Obfuscating blob names in sources would just create alternate names for blobs, solving nothing, while turning sources into non-sources under the GPL: they would no longer be the most convenient way to make changes to the software. In order to distribute them, or binaries compiled out of them, we'd have to distribute the corresponding sources along with them. Oops ;-) Also, Linux changed so as to pretty much deprecate the userland hotplug script used to load firmware. Its firmware loading machinery can now look directly in the filesystem, within /lib/firmware or elsewhere. In this setting, the idea of one-way-hashing the blob name before passing it on to the userland hotplug script thus became moot. Another concern is whether looking blobs up /lib/firmware when it's NFS- or fuse-mounted is enough of a request to enable it to be construed as user inducement. Probably not in FSDG desktop-targeted distros, but GNU Linux-libre is designed to be installable even in freedom-hostile distros, so the requirements are more stringent. We have considered, for example, the possibility of a distro's fuse-mounting /lib/firmware so that a userland program monitors the requests and offers to install requested firmware, just the kind of scenario that motivated us to want to one-way-hash the requests to the hotplug script. In an attempt to work around this kind of attack, we considered even requiring userland to enumerate firmware filenames to the kernel, and arranging for the kernel to only issue requests to filenames listed in the enumeration. The fuse-mounted /lib/firmware could, however, list all blobs available for on-demand installation, defeating even the pre-enumeration. At that point, we decided the problem was not fixable, and that, because of the design of the firmware-loading machinery, we'd have to keep on disabling the loading of blobs altogether in order to be on the safe side WRT inducing their installation. However, we also agreed that desktop-focused distros, that didn't attempt to induce and facilitate the installation of blobs by the above-described means, could very well relax these stringent requirements, and distribute versions of Linux that didn't completely disable blob-loading, and just refrained from mentioning the blob names in logged errors. I'm not sure the Debian kernel gets that far, I'm afraid. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Re: [GNU-linux-libre] gnu.org "Free GNU/Linux distributions" list updates
On Aug 6, 2017, Jaromil wrote: > in case you follow up on BLAG's website restoration, please consider > at Dyne.org we can also be hosting the BLAG website, which I remember > to be simple enough and could be made static. Thanks. blagblagblag.org is still up; blag.fsf.org, that's down, was much bulkier, in that it had the install isos and tree composes. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Re: [GNU-linux-libre] gnu.org "Free GNU/Linux distributions" list updates
On Aug 4, 2017, bill-auger wrote: > === Blag === > the only one with a critical issue that could not be resolved was blag - > the download links on their website are broken so there is actually no > OS available - i wrote to their mailing list but there has been no > response after nearly a month Not long before your post there, some people (on the list and on IRC, IIRC) talked about giving it another shot and trying to put the server back together. The FSF sysadmins asked us to wait for some new infrastructure, so that the new VM would be set up in the new place to begin with. As for why it's down... Apparently there was a break in and the server was brought down. We have backups, and that's good as far as the data is concerned, but the software is presumed to be vulnerable and will likely have to be installed from scratch. I don't have the details, I'm just an interested party who happens to often be a gateway between (whatever's left of) that community and the FSF. FTR, I'm a bit surprised you didn't get a response from the people who expressed interest in putting it back together. Thanks for your investigation and updates for the free distros list, -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Re: [GNU-linux-libre] [Libreboot-dev] Hardware related confusions, Was: MAME
On Apr 4, 2016, Francis Rowe wrote: > Don't talk about MAME here. in practise, this is often used for running > proprietary software (games). Besides (what I just posted in another email), if there is one place where it is appropriate to discuss whether a piece of software belongs in a FSDG-compliant distro, this is it. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Re: [GNU-linux-libre] [Libreboot-dev] Hardware related confusions, Was: MAME
On Apr 4, 2016, Francis Rowe wrote: > Don't talk about MAME here. in practise, this is often used for running > proprietary software (games). But that's not the criterion we use, is it? Or should we stop talking about Thinkpad x60 and x200, because they are often used for running a proprietary BIOS, and a proprietary operating system on top of it? Isn't it the fact that they *can* be used to run Free Software enough of a reason to talk about these computers, as well as this computer emulator that now is Free Software, and the virtual machine emulator Gnash that has always been Free Software, etc? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Re: [GNU-linux-libre] MAME
On Apr 1, 2016, Jean Louis wrote: > Firmware or blobs are removed from mainstream Linux kernel exactly for > that reason that there is no source code or/and there is no free software > license. When firmware lacks source code, we call it a blob, and it is non-Free Software. But there is firmware that has corresponding source code available, and both sources and binaries are available under Free Software licenses. That is firmware, but not a blob. Free Software firmware is not disabled or removed in GNU Linux-libre. There's yet another kind of firmware that's not even software, just initial register settings for the hardware. Those are often disabled along with other software blobs that accompany them, but there are some non-software blobs that come to mind that don't get disabled: the CIS files used to configure PCMCIA cards. Although they are in binary form and they aren't accompanied by correspoding sources, there is Free Software to convert this binary representation back to a human-readable source representation, and then back, without any loss of information in either direction. We used to remove these from Linux-libre (before it became a GNU project) until it became apparent that the binary representation was as good as sources, and the license was ok. In BSD land, blob has a broader meaning: it is used to refer to sourceless binary-only drivers, not just sourceless binary-only firmware. That's presumably because their kernel license doesn't object to combinations with such drivers. So please be careful with terminology. Don't assume all firmware is non-Free Software, because that's not the case. And don't assume that all firmware is a blob, because that's not the case either. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Re: [GNU-linux-libre] JScreenRecorder v0.3 - a pure java screen recorder (100% free?)
Hello, Deepak, On Oct 26, 2013, deepak pk wrote: > i have developed a pure java based screen recorder named JScreenRecorder. > you can download it from http://sourceforge.net/projects/jscreenrecorder/ That looks like userland code; this list is about GNU Linux-libre, one of the kernels of the GNU system. I believe you meant to write to the gnu-linux-libre@nongnu.org list instead, which discusses issues having to do with 100% Free GNU/Linux distros, so I'm copying that list, including a complete (quoted) copy of your post. > now the thing is that i had a message from sourceforge user G4JC that if i > removed JMF > from my project and replace it with FMJ my app will be 100% pure opensource; > then it will > be available/can be used for GNU-Libre installations. i tried to use FMJ but > it had dependency > on FFMPEG. so i went with jcodec (http://jcodec.org/). its FreeBSD licensed. > and so i released > my apps version v0.3. > then i wanted to improve my apps performance and went to search for better > ways to capture the > screen and found out a code by user Killer 99 > (http://www.rune-server.org/programming/application-development/387765-directrobot-fast-java-robot-allows-screen-recording.html) > he developed a class named DirectRobot which has lower memory requirement > than Robot class, which > improves performance. this class however uses java.awt.peer.RobotPeer and > sun.awt.ComponentFactory classes. will these classes be a problem? my IDE > (netbeans 7.4) is showing warning that its "internal proprietary API and may > be removed in a future release". will this be a problem for being 100% free > and opensource? I suggest checking whether these classes and all of their dependencies are present in IcedTea, or in the source portion of OpenJDK. If they are, then the classes can be used under the Free Software license that governs the Java code in these projects. Otherwise, you'd be better off refraining from using the Java class that relies on them, or using a modified version that does not depend on the classes that may turn out to be non-Free, and that might be removed from future releases of the Java platform. > Eagerly waiting for your response.. > Regards, > Deepak PK > -- Important Links --- > SF Discussion: > http://sourceforge.net/p/jscreenrecorder/discussion/general/thread/d14053b5/?limit=25#f26b/555a > Project SF Page: > http://sourceforge.net/projects/jscreenrecorder/ > DirectRobot code site link: > http://www.rune-server.org/programming/application-development/387765-directrobot-fast-java-robot-allows-screen-recording.html -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] GNU Linux-libre 3.3-gnu is now available
On Mar 19, 2012, jema...@gnu.org (Jose E. Marchesi) wrote: > Would it be possible to use the main GNU distribution sites for > linux-libre? Sorry about the delay. In principle, this is both possible and desirable, but we're still trying to work out how to do that without messing too much with our workflows, given the perfectly reasonable security requirements of ftp.gnu.org and all the churn in linux-libre. > I also noticed that www.gnu.org/software/linux-libre redirects to > http://www.fsfla.org/svnwiki/, which I find a bit confusing. That was a bug in gnu.org; I believe the incorrect redirect has since been fixed. > Would be possible to add a homepage for linux-libre at > www.gnu.org/software/linux-libre using the GNU boilerplate[1]? > [1] http://www.gnu.org/boilerplate.html I'd rather just change the GNU Linux-libre web page to comply. Can you summarize any relevant deviations? AFAICT it might be just a matter of reordering some sections, no? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] GNU Linux-libre 3.3-gnu is now available
On Mar 19, 2012, Henry Jensen wrote: > As I understood the following discussion, your idea was to use a > userland script that tells the kernel, if firmware is available. > Can you tell us what the current status is? I finally have an idea of how to introduce in the deblobbing script the ability to introduce changes other than replacing undesirable stuff with /*(DEBLOBBED)*/, in a way that can greatly simplify the intelligence of the deblob- scripts while at that. I'm afraid I haven't even started the implementation yet. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] GNU Linux-libre 3.3-gnu is now available
The first release of Linux-libre since its dubbing as a GNU package is now available from the download links off of http://linux-libre.fsfla.org/ I expect a more formal announcement to follow within a few days, but if you're in a hurry, you can go straight to http://linux-libre.fsfla.org/pub/linux-libre/releases/3.3-gnu/ Binaries are on the way, check the main web page for links to various repositories. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Free software and open source
On Aug 29, 2011, Richard Stallman wrote: > For instance, many Android phones contain tivoized versions of Linux. > Those executables are open source Are they, really? Few years ago, I got in touch with the OSI board asking them whether they believed Tivoized software fit their definition. I was hoping they'd agree it didn't fit and perhaps start opposing it, on the grounds that Tivoization discriminated against Fields of Endeavor. I got mixed responses from them, but nothing official or definitive. It might be nice to try to get an official decision from them, so that they either join our fight against Tivoization, or provide us with an irrefutable argument about differences between our position and theirs that would be understandable even by those who refuse to take ethical and moral considerations into account. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Freedom issues in lame, cdrkit, SDL, foomatic-filters, freepascal, unzip
On Sep 5, 2011, Henry Jensen wrote: > fpcbuild-2.4.2/fpcsrc/packages/opengl/src/gl.pp > fpcbuild-2.4.2/fpcsrc/packages/opengl/src/glu.pp > Quote > ** Copyright 1996 Silicon Graphics, Inc. > ** All Rights Reserved. > ** > ** This is UNPUBLISHED PROPRIETARY SOURCE CODE of Silicon Graphics, Inc.; > ** the contents of this file may not be disclosed to third parties, > copied or > ** duplicated in any form, in whole or in part, without the prior written > ** permission of Silicon Graphics, Inc. I suggest checking whether these are not part of the *GL code that SGI relicensed under a Free Software license a while ago. If they are, taking them under the new license is probably an easy fix. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Linux-libre compilation option: "Include in-kernel firmware blobs in kernel binary"
On Apr 18, 2011, Karl Goetz wrote: > On Sun, 17 Apr 2011 16:37:26 +0200 > Christophe Jarry wrote: >> -*- Userspace firmware loading support >> [*] Include in-kernel firmware blobs in kernel binary > Is there any free firmware carried in linux? Yes, and those are the only ones Linux-libre carries and includes in the kernel binary if asked. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Jan 14, 2011, Richard Stallman wrote: > For better interoperability, so that it's not harder for us to use third > parties' branches, and so that we don't run into difficulties when > interoperating (say contributing patches) to third parties who don't use > our branch. > The need to run a special command to interconvert is not a difficulty, > just an inconvenience. I agree. It's an inconvenience that we freedom lovers might be willing to accept, but when we interoperate with others who don't share our values, they will likely object and refuse to cooperate with us. > Meanwhile, it occurs to me that once we have converted the repository, > plain rebase will work to interconvert all changes that don't alter > blobs. A single rebase command won't do, for it makes local changes “in the wrong direction”. I mean, what it does is collect whatever changes you made in a local branch, reset the local branch to the top of upstream, then reapply on the local branch the changes as if they had been made on top of upstream. We want the changes from upstream that aren't (in rewritten form) in the local branch to be applied to our local branch, without resetting it, so the commands take a more convoluted form that takes 3 or 4 commands, as discussed upthread. Still, that's no big deal for us. But if we want to be able to push patches we write without publishing a blob-ridden branch, we're going to have to make it easy for third parties who are not willing to tolerate any inconvenience for the sake of freedom. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Jan 14, 2011, Richard Stallman wrote: > No, it wouldn't be impossible. A suitable userland hotplug script would > be perfectly capable of looking for a local file that satisfies the > request. > It seems impossible to me. Could you explain how it could do this? Uhh... I thought I'd already explained, but here it goes... Nowadays, a minimal hotplug script looks like this: # Both $DEVPATH and $FIRMWARE are already provided in the environment. HOTPLUG_FW_DIR=/lib/firmware/ if test -f $HOTPLUG_FW_DIR/$FIRMWARE; then echo 1 > /sys/$DEVPATH/loading # firmware found cat $HOTPLUG_FW_DIR/$FIRMWARE > /sys/$DEVPATH/data # upload it echo 0 > /sys/$DEVPATH/loading # upload complete else echo -1 > /sys/$DEVPATH/loading # firmware not found fi If the kernel passes userland, in addition to DEVPATH and FIRMWARE, a HASHPREFIX, the hotplug script would run: case $FIRMWARE in md5/*) hash=`echo $FIRMWARE | sed 's,^md5/,,'` for f in `cd $HOTPLUG_FW_DIR && find . ! -type d -print | sed 's,\./,,'`; do case `echo -n $HASHPREFIX$f | md5sum` in "$hash"[]*) echo 1 > /sys/$DEVPATH/loading cat $HOTPLUG_FW_DIR/$f > /sys/$DEVPATH/data echo 0 > /sys/$DEVPATH/loading exit 0 ;; esac done ;; esac -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] Re: PCMCIA .cis files
On Jan 13, 2011, Richard Stallman wrote: >> What is Torvalds doing? > Word is that he's removing everything from within firmware/ on the next > release. > I am confused. What dies the `firmware/' directory have to do with these > files for PCMCIA? That's where the CIS files are. > It sounds to me like the binaries are close enough to qualify as > source. That's my understanding as well. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Jan 13, 2011, Richard Stallman wrote: >> We compute the hash of "`uname -r`/foobar/blobname.fw", and ask the >> userland hotplug script for %x of that hash number. >> This does not depend on any session ID. It will only change if you >> install a different version of Linux. > Yeah, this particular variant doesn't. > Other variants, using a kernel-supplied varying hash prefix (which could > be exposed through some file named hashprefix within /sys) could. > What I don't understand is why you entertain the idea of doing so. It > would be like our current approach in that it would be impossible to > put firmware in a file that would load. No, it wouldn't be impossible. A suitable userland hotplug script would be perfectly capable of looking for a local file that satisfies the request. What this would do is make it harder for the hashes to become stable alternate identifiers for the blobs. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Jan 13, 2011, Richard Stallman wrote: > Once the rebasing and the remembering you described above (and I > described before) are easily integrated into git pull/merge/rebase, I > believe so. > Why does it matter to integrate them into git? For better interoperability, so that it's not harder for us to use third parties' branches, and so that we don't run into difficulties when interoperating (say contributing patches) to third parties who don't use our branch. > Using a special command for the conversion is no big deal. To create and maintain our branches, I agree it isn't. For third parties to use them along with stuff they already have, I think it is. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Jan 6, 2011, Richard Stallman wrote: > We compute the hash of "`uname -r`/foobar/blobname.fw", and ask the > userland hotplug script for %x of that hash number. > This does not depend on any session ID. It will only change if you > install a different version of Linux. Yeah, this particular variant doesn't. Other variants, using a kernel-supplied varying hash prefix (which could be exposed through some file named hashprefix within /sys) could. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Jan 5, 2011, Richard Stallman wrote: > Maybe a series of rebase operations could handle them one by one, I think there's some miscommunication. rebase won't deal with blobs, filter-branch will. rebase (used as described) will just apply (ranges of) changes from one branch into a rewritten branch. > What's more, any new revisions from Torvalds' repository can be > converted very fast (assuming they don't add new blobs) by rebasing > them. > In addition, revisions in our repository can be converted the same > way. Just remember the last pair of revisions where a blob was > deleted. Suppose it is m <> z. You can take our revisions, based on > z, and rebase them into m in a copy of Torvalds' repository. Then you > can upload those to his real repository. > Is the whole problem solved? Once the rebasing and the remembering you described above (and I described before) are easily integrated into git pull/merge/rebase, I believe so. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] Re: PCMCIA .cis files
On Jan 5, 2011, Richard Stallman wrote: > What is Torvalds doing? Word is that he's removing everything from within firmware/ on the next release. > How does he justify not including the textual > files in his Linux sources? He doesn't. Probably whoever split them out into the firmware/ tree didn't even know about them at first. The latest version claims they were developed by the pcmcia-cs project. > Does he say he is using them under the other license? Nope. firmware/WHENCE only mentions GPL. > Does he say he has an arrangement to refer to the other site for the > textual files? Does he say that the binary files are sources? Nope, none of this. > If he has not addressed the issue, maybe you can poke him so he has > to do so, and then whatever solution he uses might be good for us too. A patch was posted that brought some sanity to the .cis files in Linux last year (Sam mentioned it upthread), but it got nowhere. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] Re: PCMCIA .cis files
On Jan 4, 2011, Richard Stallman wrote: > Yeah, I believe so. I'm not sure the current pcmcia driver doesn't > really offer the interface the userland program that makes the > conversion relies on, or if it only fails to do so on a machine that > doesn't have a pcmcia interface, but the important point is that it's > definitely not functional on any random machine. > In that case, either we need a separate binary-to-text converter for > these files http://www.mail-archive.com/linux-pcmcia@lists.infradead.org/msg03468.html has a patch by Dmitry Eremin-Solenikov with a stand-alone version of the dump_cis program, that converts .cis binary to text. The separate patch that introduces mkcis, to convert from text to binary, wasn't archived there, but we already have a stand-alone program that does that job, so there aren't any freedom problems with the binaries, the only issue now, if any, is GPL compliance: sh/could we ship only the binaries if we know they were built from textual sources that we don't ship? FWIW, 2.6.37-libre is already out, without the .cis files, but with requests for them. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Jan 4, 2011, Richard Stallman wrote: >> My proposal does that automatically. If filter-branch doesn't do that, >> I think that implies filter-branch is not the same thing. > Compatibility as in git pull/merge recognizing automatically the > saved-away commit equivalences? > I am not sure what that means. It means git pull (the preferred way to bring in changes from a remote repository) or merge (the preferred way to bring in changes from a local branch, which may be a clone of a remote branch) ought to be able to use these equivalences, instead of regarding the commits as unrelated. It also means there should be another variant of git pull that, sort of like rebase, reapplies commits from one branch to another, but that, unlike git pull --rebase, reapplies changes from upstream on top of local, updating the commit mapping while at that. > The correspondence table would be saved permanently (unless you delete > it), so the proper command could automatically move any change from > one repository to the other. The bit that is missing is the integration above. We can do without the second part for the time being, although it's somewhat inconvenient. But without the first part, using our repository would be far more cumbersome than using upstream. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Jan 4, 2011, Richard Stallman wrote: >> Where does it store the correspondence table? > In git refs/original, unless overridden. > I don't understand the answer. It means literally nothing to me. You can think of it as a tag, named after the original commit, pointing at the rewritten commit. > branch1: c1 <- c2 <- c3 <- c4 > branch2: c1 <- c2 <- da > rebasing branch1 onto branch2 would yield: > branch2: c1 <- c2 <- c3 <- c4 <- da' > Proper English usage would be to call it "rebasing branch2 onto branch1". > If you confirm for me that git users customarily use the incorrect > usage, I will accept the fact that they do. But I want to get > confirmation of this. No, sorry, my mistake. Here's a formal description of how git rebase behaves: # git rebase [--onto newbase] upstream [branch] * check out branch (if omitted, use the currently checked-out branch) * collect all commits that are in branch but not upstream * reset branch to point to the head of newbase ?: upstream * re-apply the commits, skipping already-applied patches > In order for me to understand the semantics, could you tell me > how the text of da' relates to the text of c4? Is it the same diff > as the diff between da and c2? In other words, is it true that > da' = c4 + (da - c2)? Yup. > Anyway, the operation I proposed is different. Yep. > Assume we have this: > branch1: c1 <- c2 <- c3 <- c4 > branch2: c1 <- c2 > branch3: whatever <- x > transform branch1, with c2 -> x in the correspondence table, > would not alter branch1, but make a new branch (call it branch1'): > branch1': whatever <- x <- c3' <- c4' What you propose is implemented by the following commands: git branch -f branch1\' branch2 # branch1' is now same as branch2 git rebase --onto branch3 branch1 branch1\' # now branch1' is branch3 plus changes in branch2..branch1 > Is this what filter-branch does? git filter-branch is, in a way, a smarter git rebase, that can be told to modify or discard certain commits instead of just reapplying them, and to take note of the mapping from old to new commits. It doesn't actually change any branches. It takes a list of commits and creates remapped commits. Branches or tags can be reset to point to them afterwards. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Jan 4, 2011, Richard Stallman wrote:
> That the kernel would include a session, build or release id as part of
> the hashed string, and it would provide userland with that string so
> that it would be included in the computation that searches for the
> firmware.
> How could this be useful? I just don't get it at all.
Varying the string would make it harder for people to publish “cheat
sheets” that would render the mangling obsolete, while still enabling
firmware to be found if it is installed.
Say, kernel driver used to request_firmware("foobar/blobname.fw"...)
We compute the hash of "`uname -r`/foobar/blobname.fw", and ask the
userland hotplug script for %x of that hash number.
Userland hotplug script runs e.g.
find /lib/firmware ! -type d -print |
sed "s,^/lib/firmware/,," |
{
requested=`cat /sys/...`
pfx=`uname -r`/ # could be /sys/.../hashprefix instead
found=
while read file; do
if test `echo -n $pfx$file | md5sum` = "$requested -"; then
found=$f
break
fi
done
if test -n "$found"; then
cat /lib/firmware/$found > /sys/...
else
...
fi
}
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Jan 3, 2011, Richard Stallman wrote: > It's so clean and general that it's already implemented in git. It's > called git filter-branch , in the way you stated, > Maybe it is. What does filter-branch do? It lets one programmatically remap commits, file contents, tags, commit messages, committers, tags, and more, from a given branch or set of commits onto a rewritten branch. > Where does it store the correspondence table? In git refs/original, unless overridden. > or git rebase , for > a more manual implementation (maybe good to create an initial mapping). > Based on your definition of rebase, it can't be the same operation, > because rebase and my transformation produce different kinds of graphs. > So I wonder if there is a miscommunication occurring. I guess there is. AFAIK git rebase is supposed to create an isomorphic subgraph, unless it detects that equivalent commits are already present in the target graph. I.e., given branch1: c1 <- c2 <- c3 <- c4 branch2: c1 <- c2 <- da rebasing branch1 onto branch2 would yield: branch2: c1 <- c2 <- c3 <- c4 <- da' whereas rebasing branch2 onto branch1 would yield: branch1: c1 <- c2 <- da <- c3' <- c4' I'm not entirely sure rebasing preserves arbitrarily complex graph structures, like filter-branch does, or if it flattens the graphs, but I'm not sure how important this is, given that filter-branch does preserve arbitrary graphs (unless told not to). > What git misses is means to restore compatibility between the original > and the rewritten branch. > My proposal does that automatically. If filter-branch doesn't do that, > I think that implies filter-branch is not the same thing. Compatibility as in “git pull/merge” recognizing automatically the saved-away commit equivalences? I don't see that your solution does that. If it does, then the problem is solved indeed, but I didn't see any suggestion of yours that changed the way git pull or git merge operate. Can you please clarify? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] Re: PCMCIA .cis files
On Jan 3, 2011, Richard Stallman wrote: > I've just tested that it is possible to load some specific PCMCIA socket > driver on a machine that doesn't have any PCMCIA interfaces, but I don't > think I can even build the ancient 2.4-ish pcmcia module with a current > kernel, let alone run it :-( > So it sounds like you are saying that the current 2.6.12 pcmcia module > does use these files sometimes (for devices that give erroneous info), > but doesn't support the conversion binary to text at all. > Is that correct? Yeah, I believe so. I'm not sure the current pcmcia driver doesn't really offer the interface the userland program that makes the conversion relies on, or if it only fails to do so on a machine that doesn't have a pcmcia interface, but the important point is that it's definitely not functional on any random machine. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] Re: PCMCIA .cis files
On Jan 2, 2011, Richard Stallman wrote: > Is it the case that you only need these files if you are running that > module? No, the pcmcia infrastructure was rewritten in 2.6.12 or .13. The program no longer works for me with a current kernel, but I can't tell whether it is because the interface is no longer available after the rewrite, or because it's only provided if a PCMCIA socket is present. I don't have any machines left with PCMCIA sockets :-( The Card Information Structure (CIS) files are still required to override the incorrect CIS data supplied by a number of PC Cards. > Is it the case that you can always install that module even if you don't > have PCMCIA in your machine? I've just tested that it is possible to load some specific PCMCIA socket driver on a machine that doesn't have any PCMCIA interfaces, but I don't think I can even build the ancient 2.4-ish pcmcia module with a current kernel, let alone run it :-( >> Another possibility is to separate all this from Linux, > This is what's going to happen in upcoming releases of Linux. We might > as well do that right away. > That's a fine solution. The files are already present in the linux-firmware repository. Should we (Linux-libre project) maintain our own cleaned-up linux-libre-firmware repository, or leave that for some other project to undertake? This might even serve as proving ground for the git rewriting solution we're going to adopt for Linux-libre. It would be much simpler, due to its much shorter history, less frequent changes, and smaller number of (remaining) files. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Jan 2, 2011, Richard Stallman wrote: > This operation is clean and general, so they might even install it. It's so clean and general that it's already implemented in git. It's called “git filter-branch”, in the way you stated, or “git rebase”, for a more manual implementation (maybe good to create an initial mapping). What git misses is means to restore compatibility between the original and the rewritten branch. This prevents others from using our repository and “git pull”ing other's topic branches. This is the problem I'm trying to solve, because I don't see that our repository would be useful otherwise. I don't expect lots of Linux developers to switch to a libre repository if this will make it less likely for their developments to be “git pull” ed by Linus or Andrew Morton, or for other users to switch to it if they will then have trouble when pulling others' patches. That said, having a properly filtered repository is a precondition for this once git pull is improved so as to support rewritten branches, so I might as well get started with it as time permits. It's not like it will be wasted time, and it might show I'm wrong in my assessment of usefulness. But it's certainly not as interesting, hack-wise, as finding a way for git to do the work we need, so I tend to be more attracted to the latter. It doesn't help that we don't have scripts yet to deblob such early releases of Linux as 2.6.11, when the history started. If we did, the entire process would be relatively simple. Now, once I get to that, we might not even need those scripts, and just release out of the git repository, so... I'm beginning to like this more and more ;-) -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Jan 2, 2011, Richard Stallman wrote: > My reasonsing was that firmware filenames are static identifiers. Even > if we mangled them, they'd still be identifiers to the same files, and > web pages would quickly pop up mapping the identifiers to the file > names, so it seemed pointless to try to disguise the sources. > I agree those things might happen, but that doesn't make it pointless. Agreed. > So I figured run-time mangling, that can vary not only from release to > release, but also from build to build, even from session to session, was > far more important. > What would it mean to change the translated name from session to session? That the kernel would include a session, build or release id as part of the hashed string, and it would provide userland with that string so that it would be included in the computation that searches for the firmware. I'm not sure yet how this would work with initrd building that include the minimal number of drivers and corresponding firmware files. Varying the hashing of the MODULE_FIRMWARE strings, that are compiled as constants into module files, isn't something we can do. But noting the need for non-Free firmware is something we might want to keep on refraining from doing. > That would mean that the user has to reinstall the nonfree firmware again > in each session -- right? No, it would be installed just once, but the hotplug script that looked for a file whose name matched the requested hash code would take the varying portion into account. > You might as well "mangle" every name to `foobar'. Wel,l we currently mangle them all to /*(DEBLOBBED)*/ ;-) -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] Re: PCMCIA .cis files
On Jan 1, 2011, Richard Stallman wrote: > Maybe we can keep the binary files without adding the textual files. > I think it would be right to do that if the binary files are > just as good as the textual files for all development. > Are they? I used to think so, because there is a program (dump_cis) that supposedly converts them to textual form. I later noticed that the program, part of the ancient pcmcia-cs package, AFAICT only works if you're running linux 2.4 with the pcmcia-cs module. I couldn't get it to work otherwise, for it issues requests to the module to decode the binary. The program to convert from text to binary, OTOH, works fine. This makes me undecided as to whether the binary file is indeed just as convenient as the source. I wouldn't know how to modify it. Now, if there are programs that enable the binary format to be directly modified, or that convert them from binary to text, then it would indeed be just as convenient. > Would you feel good about treating the binary files > as the source code, using them for all editing, and so on? If I could figure out the binary encoding, yes. It's probably not hard, and we have a reference programs to do that both ways, so in theory it's doable. > Another possibility is to separate all this from Linux, This is what's going to happen in upcoming releases of Linux. We might as well do that right away. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Jan 1, 2011, Richard Stallman wrote: > it still seems to me that the directory which normally holds firmware > files could effectively be that list. If there was such a directory, yeah, it could be. But there's no such directory. It's up to the hotplug script to decide where to look for the firmware bits it's going to give back to the kernel. It can be a directory, a collection of directories, a tarball, a database, anything. So the kernel can't look it up. And then, if the kernel could look it up, it might as well get the data straight from the filesystem. The reason is doesn't is precisely to enable userland to control not only where, but also how firmware is stored. > The function that requests loading firmware look in the firmware > directory for the relevant file name. If it finds a file, it requests > loading the firmware. Otherwise, if the firmware file is free, it > requests loading the firmware. But if the file is nonfree and not present, > it gives an error message, "Device not supported". > Wouldn't this do the job? It would, if the kernel could tell how userland would resolve filename requests. It can't. That's why my proposal involves userland to tell the kernel what pieces of firmware are available upfront. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Jan 1, 2011, Richard Stallman wrote: >> Maintain a table of the correspondence between version identifiers >> in Torvalds' repository and version identifiers in ours. > That's what would be prohibitive to maintain by hand, > Why imagine this table would be maintained by hand? Maybe I was confused because a program that does everything you described already exists, and I had already said that that part of the problem was already fixed. The program is git filter-branch. It's another part of the problem that still needs solving. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] Re: PCMCIA .cis files
On Dec 31, 2010, Richard Stallman wrote: > I'm not sure the .cis files are software. They are binary descriptions > of the card name, function, compatibility and hardware configuration. > I am not sure the question matters. Does it? The only significant > difference between the binary form and the textual form is the > comment, but if that comment is useful, then the textual form is > better. I wouldn't say the comment is useful, but I think the textual form is better anyway. > So if you want to add these files, where's the problem? Add the source. I don't want to clutter the deblob scripts adding lots of stuff. > But the first question is, is there a reason to add them? > Why do you want to add them? I don't. I'd just like to keep the binary .cis files if there wasn't any reason to remove them. > Linux-libre has long removed all .cis files that are requested by the > various PCMCIA drivers. > What do these files DO? What job are they used for? The PCMCIA driver gets from this file data on PCMCIA standards compatibility, voltage, I/O ports and IRQs it's supposed to use to talk to the device, in addition to name and type of card. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Dec 31, 2010, Richard Stallman wrote:
>> Propposal on this: preffix all unfree firmware as being unfree ("unfree_",
>> probably) instead of hashing their name identifiers. This way the firmware
>> loader can simply log a warning stating clearly that the firmware harms y=
> our
>> freedoms.
> Sorry, forgot to reply all.
> I think the firmware loader is a separate program, not part of Linux,
> so we do not control it. However, there must be a function in Linux
> which somehow invokes that program. Maybe we could modify that
> function so it sees this and prints the error message "Device not
> supported".
But we don't want to do that unconditionally. That's what we do now,
and we decided to change it. We want to do that only if the kernel
somehow knows that the user hasn't installed firmware with that name.
Which brings us exactly to my earlier proposal:
Now, if the latter approach (mangling blob names in the request, but
not in the source code per se) is acceptable, an even simpler approach
might work: one with even greater odds of being accepted upstream:
introducing some means for userland to tell the kernel which pieces of
firmware are available, so that the kernel does not even ask for those
that aren't.
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Jan 1, 2011, Richard Stallman wrote: > I have a devised a much better plan. It requires changes in git that I > believe will be useful to solve the very kind of rebase (and rewrite > history) problems that often give git users grief, so I expect it to be > welcome (unless my plan is flawed), and it shouldn't be hard to > implement. > Could you tell us more about it? Those sound like a lot of practical > advantages, but we should check that it really solves the problem. My plan is to maintain, within git, the mapping between original and rebased commit, so that pulls, merges and rebases could tell what has already been seen and done, rather than attempting to replay commits. I propose to model them as “weak parents”, akin to weak references: they link to a parent, but they don't demand the parent to be available, or keep the parent around, or cause the parent to be transmitted along with the branch. If the other party has it, it can be used to improve merges and rebases; otherwise, it's ignored. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
interactive mode, and I'm not sure about the implications of that. OTOH, git filter-branch is *designed* to rewrite history preserving merging and all. I'm not sure it can be done incrementally, but I think I see a somewhat convoluted procedure to work around that potential limitation. Even then, this does little to solve the actual problem of using our published repository as part of others' git workflow: the resulting branch, just like the result of the rebase strategy above, is a branch that's completely incompatible with upstream, i.e., for third parties, this means no git pull for updates from upstream, and no combination with third-party's branches based on upstream. > I don't know the git interface, and I don't know whether the goal of > "not breaking it" is feasible. But I urge you not to worry about it > too much. Why? What's the point of rushing to implement something that's no better than using our release tarballs or our deblobbing scripts, rather than releasing something that will actually be useful? > Creating a repository the way you suggest would make it very difficult > for us (or anyone else) to bring in any changes that are later installed > in Linus' tree, regardless of whether they need cleaning up. > Not difficult at all -- I explained just above how to do it. Manually performing operations that git is perfectly capable of performing is not only difficult, it's ridiculously more difficult. If it was such that only we had to do it, it might be acceptable. But if every user has to do it, it is nonsensical. And that's what we would get with an incompatible repository. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Dec 30, 2010, Richard Stallman wrote: > That could be done, I guess, but it would be way too cumbersome. > Cleaning up the repository is not something I'd like to have to do every > time some commit makes to some repository out there. > So implement an optimized equivalent for that case. That's what I'm trying to do. Without breaking the git interface, while at that. http://thread.gmane.org/gmane.comp.version-control.git/164360 is where I discuss my proposal. > Anyway, there is no need to do this "every time". > I think once a day would be good enough. Even once a week > would be pretty good. I think you don't understand how absurd what you're suggesting is, because you probably have never used git. Doing things the way you suggest means *anyone* who wanted to use our repository, and also take changes from other repositories, would have to run this incredibly expensive operation every time they wanted to run the equivalent of “cvs update” to pick up changes from an upstream. It's so absurd that I doubt anyone would want to do that. I know I wouldn't. It's a non-starter. > The method I just described is a way to merge changes from his tree to > ours. Well, you described a way to rewrite the commits of the repository. In git-speak, that's called rewriting history. There's nothing 1984ish about that, it just means you're modifying an earlier commit. The problem with that is that the commit id is a hash of the contents of the tree and of the ids of earlier commits. So when you change a commit, you invalidate all subsequent commits, that must be rebased on the new commit, and because the hashes involve the commit id of prior commits, the rebased commits will also get different ids, with nothing that relates them to the original commits. That's why updating and merging across history rewrites is undesirable. Creating a repository the way you suggest would make it very difficult for us (or anyone else) to bring in any changes that are later installed in Linus' tree, regardless of whether they need cleaning up. I have a devised a much better plan. It requires changes in git that I believe will be useful to solve the very kind of rebase (and rewrite history) problems that often give git users grief, so I expect it to be welcome (unless my plan is flawed), and it shouldn't be hard to implement. So, unless you really want to understand the problem, which involves learning about the inner data structures and common workflows of git, I suggest you leave it at. >> But it isn't our problem. We can leave it to be implemented by >> someone who wants it. > Well, *I* want it. It won't be really useful for me otherwise. > Could you explain why? I don't see why you are concerned about > merging changes automatically from our tree to his. I'm more concerned about the opposite direction, that takes several patches a day. Being able to push our changes upstream is desirable, but not a must. However, it is an absolute must for any of us to be able to trivially pull changes from upstream. Actually, make that upstreams, for any branch that tracks Linus' tree and has additional patches might be desirable for any of us to merge into our personal or published repositories. If the Linux-libre repository doesn't fit into people's regular workflow, there will be a strong incentive against using it, against developing improvements for Linux on it. It would be self-defeating. I don't want this kind of pain, not for myself, not for other contributors. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] PCMCIA .cis files
Linux-libre has long removed all .cis files that are requested by the various PCMCIA drivers. Revising differences between Linux-libre and Debian's Freed kernel, this was one of the differences that I came across, and I'm unsure about how to proceed. I'm not sure the .cis files are software. They are binary descriptions of the card name, function, compatibility and hardware configuration. They are licensed under GPL, but there's no corresponding source in the Linux tree. The “sources” are available from the pcmcia-cs project, under MPL1.1|GPLv2. They look like this: # # Replacement CIS for various busted NE2000-compatible cards # vers_1 4.1, "PCMCIA", "Ethernet" funcid network_adapter config base 0x03f8 mask 0x03 last_index 0x20 cftable_entry 0x20 [default] Vcc Vnom 5V irq mask 0x [level] io 0x-0x001f [8bit] [16bit] This is the entire file, and few are much larger than this; the largest just has a bunch of cftable_entries, each with a different number and io range, and that's about it. pcmcia-cs also provides a progarm to convert from this source format to the binary format that appears in Linux, and another program to decode the binary format back to source form, except for the short comments in the first few lines of each of these source files. To me, it seems like these files are not software, but rather data that describes how to interface with the card. So, to satisfy the GNU FSDG, it would suffice for the data to be redistributable. So the question is, is it? On the one hand, the GPL requires corresponding sources to be distributed along with the binaries. They aren't, but the preferred form to make changes to the files (= source, per the GPL) can be recovered perfectly (save for one-line comments) from the binaries, so maybe they're enough to satisfy the GPL, even though this is not at all obvious (or documented). On the other hand, the files (in source and binary forms) are also available under the MPL, straight from the pcmcia-cs project, and the MPL requires the distributor to offer corresponding sources only for modified versions. So, distributing only the binaries would be fine under that license. While this appears to be defensible, firmware/WHENCE in Linux says the files are under GPL. Thoughts? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Dec 27, 2010, Richard Stallman wrote: > The proposal above would still show the name of the firmware programs in > source code. I'm not sure they have to be mangled or removed from the > sources, because sources are, in a way, passive. I was focused on > fixing the problem of actively recommending non-Free Software through > request_firmware. > I am not 100% convinced I agree, but I don't see a specific reason to > disagree, so I agree tentatively. My reasonsing was that firmware filenames are static identifiers. Even if we mangled them, they'd still be identifiers to the same files, and web pages would quickly pop up mapping the identifiers to the file names, so it seemed pointless to try to disguise the sources. I hadn't considered the possibility of generating different manglings in the sources for each release of Linux-libre, but now that it occurred to me, it seems excessive, and still prone to third-party documentation that provides the reverse mapping, rendering the mangling useless. So I figured run-time mangling, that can vary not only from release to release, but also from build to build, even from session to session, was far more important. > Per the idea above, if the kernel is not told that a certain piece of > firmware is available, it won't issue requests for it, and it will only > report an error that firmware is missing: same as currently, minus the > unsatisfyable request for a "/*(DEBLOBBED)*/" firmware file. > Does "currently" mean "in the current version of Linux Libre"? Yep. > There is something here I don't follow. I see two separate technical > questions, and I don't see how they relate. > 1. How and when Linux gets the list of firmware programs installed. > It could get this list by reading a directory, or some other way. > It could get this list once at startup, or it could check again > whenever it wants a firmware program. Currently, it doesn't. There's no way for it to even tell where the userland hotplug program will look for firmware files, or how it will map the requested identifiers to file names, or how it will respond. Say, it would be perfectly possible for a hotplug program to read the identifier from the /sys/firmware/... pseudo-file, look it up in a database, get the corresponding BLOB (database speak for large binary object, not to be confused with non-Free firmware in binary form), and cat it to the corresponding /sys/firmware/... pseudo-file, or signal through another (?) /sys/firmware/... pseudo-file that the request cannot be satisfied. The lack of an interface to inform Linux what pieces of firmware are installed is what IMHO makes Linux induce users to install non-Free firmware: since it can't tell whether firmware is installed, it has to ask for it, and once it gets a reply that it's not there, it will have induced the user to install it, because the request will have been logged. By adding an interface to tell the kernel the list of currently available firmware files, we can get the kernel to refrain from asking for (non-Free?) firmware that's not installed, which could even obviate the need for identifier mangling. > 2. What it says when the firmware program is not available. The kernel logs the request, including the identifier, and, when it fails, the module that issued the request often logs an error message, that usually includes the firmware name. Also, the kernel sends the firmware name/identifier to the userland hotplug program, and that program can do pretty much whatever it likes with the name, including looking up the name in package repositories, suggesting users to install the package that provides the firmware, or even install it behind their backs. In Linux-libre, we mangle the firmware name both in the request and the error message, so there's no chance that any of this may happen. However, this also disables any possibility of using non-Free firmware that the user has installed and would like to use. > To me, these two questions seem independent. You seem to be saying > that a change in (1) would affect (2), but I don't see how that is so. They are independent, indeed. I'm trying to address the problem that the kernel actively requests non-Free firmware, by informing Linux in advance about the available pieces of firmware. The logged error messages are a much simpler problem to deal with. “device: Missing Free firmware” is a good replacement message IMHO, and that's what we currently output. > Could you explain? Was this clear enough? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Dec 27, 2010, Richard Stallman wrote: > To merge changes from the original repository to our repository, it > would suffice to re-convert the new version of the original > repository. You can then merge from that into our repository. That could be done, I guess, but it would be way too cumbersome. Cleaning up the repository is not something I'd like to have to do every time some commit makes to some repository out there. If we can't get something that enables us (or others) to “git pull” or “git merge” to bring in changes from other existing branches, including Linus' tree, I don't think it's going to work. Ideally we'd have a repository that people could clone and develop on, instead of the Linux git tree, but that still enabled easy pulling from (and pushing to) Linus'-based trees. I'm speaking in git terms here, because the goal is to offer a repository that would fit into the workflow of kernel developers. > That might be ridiculously slow, but I am sure it could be optimized. Being slow is not the only problem. What you're suggesting is what the git documentation calls “rewriting history”, and it explains why doing this would make it impossible to perform merges, including updating our tree from Linus'. http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#problems-With-rewriting-history > But it isn't our problem. We can leave it to be implemented by > someone who wants it. Well, *I* want it. It won't be really useful for me otherwise. > I think you are being hampered by the feeling that this ought to be > trivial. No, what ought to be trivial is the use *after* the repository is converted. What you have proposed is unfortunately anything but. If I just wanted an incompatible git repository, I'd import the existing Linux-libre releases into it and be done with it. But it takes far more than that to be able to track Linus' tree, and it takes understanding of how git works internally to realize the problems. That's why I asked for help from someone who had deep knowledge of this tool. The easy approaches, I've already tried, and they don't give me anything useful. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Dec 19, 2010, Richard Stallman wrote: > Now, if the latter approach (mangling blob names in the request, but not > in the source code per se) is acceptable, an even simpler approach might > work: one with even greater odds of being accepted upstream: introducing > some means for userland to tell the kernel which pieces of firmware are > available, so that the kernel does not even ask for those that aren't. > I don't see how that helps. Whether Linux gets a list of available > firmware from a certain directory or in some other way, the issues > remain (1) what it does when it wants a firmware program that is not > present and (2) whether the source code shows the name of that > firmware program. The proposal above would still show the name of the firmware programs in source code. I'm not sure they have to be mangled or removed from the sources, because sources are, in a way, passive. I was focused on fixing the problem of actively recommending non-Free Software through request_firmware. Per the idea above, if the kernel is not told that a certain piece of firmware is available, it won't issue requests for it, and it will only report an error that firmware is missing: same as currently, minus the unsatisfyable request for a "/*(DEBLOBBED)*/" firmware file. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Dec 19, 2010, Richard Stallman wrote: > I think what we want is a program that will modify a git repository by > meta-deleting a certain range of code. Yup. That's relatively easy. The difficulty is in maintaining the ability to merge changes from one repository to the other. There are two options AFAICT: - rewrite the revision history, so that new hashes (that identify the commits) are computed for each revision => repositories become incompatible - revise the history as in a branch => repositories remain compatible, but their history will carry the non-Free portions, and there doesn't seem to be any way to refrain from carrying (or redistributing) them, since the commit ids carrying them are explicitly mentioned in the modified commits. What is really needed is someone familiar with the git's guts :-) to let me know whether I'm missing something and there is indeed a way to accomplish what we want, or if we have to make a tough call on how to proceed. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] The "Free" Kernel In Debian Squeeze
On Dec 16, 2010, Richard Stallman wrote: > It sounds like the new Debian version of Linux will recommend > specific nonfree firmware programs, which is undesirable. Yup. Debian didn't take the additional step of moving the drivers that require non-Free firmware to contrib where they belong per their own rules. Hopefully they will get there eventually. > The change is to obfuscate the names of the firmware files in the > Linux source code. The “in the source code” was something I was not entirely sure about. It could be done, and it would be much easier to do, if some intermediate layer obfuscated the names before issuing requests to userland. It would be easier not just because we'd have fewer blob names to mangle, but also because some blob names are computed with preprocessor macros, or even run-time sprintfs, involving version numbers of expected blobs or so. It's not that it would be impossible to incrementally compute the hash the way we designed, but it would be much harder. Also, implementing it this way, rather than as something internal to request_firmware(), would make it very unlikely that it is accepted upstream. OTOH, keeping blob names as they are in Linux source code, but mangling them in requests to users, might still be perceived as inducing users to install the non-Free Software, if they go look at the source code instead of just looking at the syslog messages. I'm undecided about which way to go. Now, if the latter approach (mangling blob names in the request, but not in the source code per se) is acceptable, an even simpler approach might work: one with even greater odds of being accepted upstream: introducing some means for userland to tell the kernel which pieces of firmware are available, so that the kernel does not even ask for those that aren't. I've been thinking about these options because AFAICT distros such as Fedora are leaning towards offering users more choice as to which pieces of firmware to install, what licenses to use, etc, but they're planning to do so in userland: the userland hotplug script called by the kernel to load a piece of firmware would obtain information about it from configured repositories and offer users (or not) the choice of installing it if it's not installed yet. I don't think this comes even close to addressing the problem that the kernel induces users to install non-Free Software, although it can mask it to some extent, and defer the filtering to userland. The reason I'm bringing this up is that, just like the move to request_firmware upstream, it's something we may end up having to live with and adjust our behavior to, so we might as well plan ahead of time how to cope with it, and how to design our solution so that it doesn't clash with upstream changes. > Alexandre, how is progress on this? None other than planning so far. In fact, I've been meaning to write about these issues for a while to get some feedback from other interested parties, but hadn't got to before you prompted me to do so. I'd like very much to have this implemented in time for 2.6.38 (late Mar/early Apr 2011, considering that 2.6.37 should be out by late Dec/early Jan), and I'd love to have this in a git repository rather than as deblobbing scripts, but a solution for the problem of creating a git repository that can track Linux upstream without carrying the non-Free bits that the Linux git repository carries has so far eluded me. Any git experts willing to contribute expertise to this end? Or perhaps users of other git-compatible DVCS that could help us get the behavior we need? Say, if bzr could track Linux git repos while enabling us to filter out the non-Free bits from the history, we might solve our problem and promote a GNU DVCS at the same time. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] 3D with free software
On Sep 17, 2010, Henry Jensen wrote: > Older ATI cards should work with 3D. Only with the non-Free firmware that Linux recently split out of the driver sources into separate files. Without them, it works reasonably well for 2D, but not 3D, unless you're running the Linux versions right after the transition, that ran into all sorts of interrupt storms and other problems when the firmware was not available. > With Intel graphics chips you should have have no problems (mostly). Most Intel graphics chips work fine with 3D, if they work at all. Nouveau is getting there. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] Is Kongoni Free again?
Kongoni added some non-Free Software some time ago, and was rightfully taken out of the recommended distro list for that. I got word of a new release today http://www.kongoni.org/index.php/2010/09/11/kongoni-1-12-3-cicero-released/ and I noticed this http://www.kongoni.org/index.php/2010/08/03/kongoni-1-12-3-rc2-cicero-its-out-in-the-wild/ : Another major modification done to Kongoni, is moving from the classic kernel, found at kernel.org to the FSF kernel, which has removed all of the non-free firmware. Also removed from git repository any trace of non-free software and firmware. This means that there will be no Adobe Flash, no radeon non-free firmware, no non-free codecs and so on. Everything is now open source or free. The *or* is a bit worrisome; it had better be an “and”, or drop the “open source” altogether. Still, the new web site points to kernel.org and slackware.org. I don't know who took over Kongoni, is the new maintainer on this list? Anyhow, should Kongoni be added to the incoming distros so people keep a close watch on it for a bit longer before adding it back to the official list off gnu.org/distros? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] Re: 100% Free Software T-shirt design
Consider this: Black (or dark blue?) t-shirt, design to be printed in golden yellow. Front: GNU (and Freedo?) in the center of a spiral galaxy with 16 arms, each ending at one of the distros. No distro names. “GNU STARS” on top or bottom, in a font and arrangement that reminds of the STAR WARS logo: http://en.wikipedia.org/wiki/Star_Wars_opening_crawl Back: Star Wars-like roll-up saying something like: A long time ago, in a galaxy one click away, the evil Empire fell to the freedom alliance, thanks to wholly Free GNU/Linux-libre distros: ututo.org, gnewsense.org, trisquel.info, ... Linux-libre.FSFLA.org, gnu.org/distros Use the Source, Luke, all of it! Ready are you? Maybe add the occasional yellow dot (stars) here and there, the GNU and Freedo logos left and right of the top of the roll-up. Can anyone implement this, hopefully reusing (to some extent, because of the reversal of foreground/background colors) the logos at http://fsfla.org/blogs/lxo/draft/fisl2010-shirt/ Bonus points for giving GNU and Freedo light sabers ;-) -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Re: 100% Free Software T-shirt design
On Jun 27, 2010, Sam Geeraerts wrote: > 1. hound2 This one does indeed look nice, but I suspect some of the features that make it look nice are not going to work in the T shirt: the shadows and the additional tones of grey. Unfortunately, in order to keep the costs low, we need a single solid color, not shades of grey or blurry shadows. In addition to that, tlamaki and G+LfSC are missing, the Drágora logo has too many colors, and the BLAG logo needs reversing. In addition to the graphical issues, I don't see that it delivers the intended message, except for those already in the know. It doesn't even name the Free distros, so it just looks like a very odd collection of graphics put together :-( It doesn't even point at say gnu.org/distros, where people could get further info. I'm going to try to fix the problems into yet another design, but I fully realize I'm not sufficiently skilled in graphical design and visual communication to make these things appealing to the eye, so I hope those that do will step up and further tweak the design or come up with other alternatives, or even completely new designs, so that we can hopefully converge on one that is everyone's favorite. Thanks! -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] Re: 100% Free Software T-shirt design
Thanks for all the contributions so far! On Jun 5, 2010, Alexandre Oliva wrote: > Islene (wife) and I have been working on a T-shirt design for FSFLA at > FISL, to promote the 100% Free distros, that people could print and use > at other events all over. > Improvements to the design are welcome. I put together a web page with the designs hound and myself contributed so far: http://fsfla.org/svnwiki/blogs/lxo/draft/fisl2010-shirt/ Let us know which designs you like best, keeping in mind that we're aiming at a monochrome solid-color front-only design, to be printed in black on light-colored T-shirts. Suggestions of colors are welcome. The designs are displayed on the page as .png images, but if you want to improve them (please do!), click on the image to get the .svg, and use inkscape to edit that. Note that the .svg files often use features that browsers won't display properly, or use fonts that are not available for the browser, or will otherwise mangle the image. Thanks in advance, -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Re: 100% Free Software T-shirt design - [Fwd: Una idea...]
Here's another (very unpolished implementation of an) idea that just occurred to me: http://fsfla.org/svnwiki/blogs/lxo/draft/100freedistros-lxo1.svg I'm trying to figure out a way to introduce the names of the distros. Perhaps a table with logos and URLs with highlighted names on the back or something... Thoughts? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Re: 100% Free Software T-shirt design - [Fwd: Una idea...]
On Jun 11, 2010, Abdur-Rahman Morgan wrote: > BLAG needs to be represented by a black star and unfortunately the > white star that is represented in the image negates the meaning of the > symbol for which it stands. Thanks for pointing that out. Now, I need to make sure I understand what you're saying about the colors to make sure we don't make a mistake when printing the T-shirts. The latest design proposed by @hound http://fsfla.org/svnwiki/blogs/lxo/draft/100freedistros-hound4.svg is black pixels on white background, but what if we print say a light color on a dark colored T-shirt, or a dark color on a light colored T-shirt? When should the BLAG star have the background color, and when should it have the foreground color? Or must it absolutely be colored black (in which case we'd certainly narrow the search space for foreground or background colors :-) Hound, it's not clear to me what you meant with this file that appears to be two separate designs. Is that for front and back, or what? Thanks, -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] Re: 100% Free Software T-shirt design - [Fwd: Una idea...]
On Jun 11, 2010, ho...@lavabit.com wrote: > Hello world! This it's my first post here. Well, my name is Jose Benito > Mora Villegas, from Guanajuato, Mexico, 36 years old, lawyer. I like dogs > especially beagles, and for that my nickname "hound". > I'm not a designer, just I starting to use Inkscape to make some > wallpapers for Trisquel, the distro wich I almost use all the time > And obviously my english is very bad. > I'm attaching another proposal for the t-shirt, basicly on the same way > than the other but trying to follow the comments of Alexandre Oliva. Thanks, I've posted your designs here: http://fsfla.org/blogs/lxo/draft/100freedistros-hound1.svg http://fsfla.org/blogs/lxo/draft/100freedistros-hound2.svg http://fsfla.org/blogs/lxo/draft/100freedistros-hound3.svg I like it. I see we have 15 distros in there, which makes positioning the logos a bit of a challenge. It would be much easier if they were 16, so how about we add tlamaki? :-) http://tlamaki.org/ -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] Re: 100% Free Software T-shirt design - [Fwd: Una idea...]
On Jun 8, 2010, "Luis A. Guzmán García" wrote: > I was talking to hound (Jose Benito) who's the art4trisquel.org admin site > and great designer about the shirts initiative and he gently accepted to > help on it. Thanks, José Benito and Luis Alberto, for the suggestions. You've come up with beautiful designs, indeed. I assume Luis will put them up on his site, that's back up now. The one thing I miss on them is the names of the distros. As nice as the logos are, they're only meaningful if you already know of the distros. So the proposed designs are missing in delivering that part of the intended message. I think naming the distros somehow might be needed (more on this below). I was inspired by the gnu gallaxy idea: it got me thinking that we might try to draw the logos into a gnu constellation that spells FREE or 100% or some such. I couldn't make that work (lack of design and inkscape skills :-) but maybe someone else can. I kind of dislike when Freedo is above GNU, it strikes me as unfair, even if GNU is bigger. It should be other way round; the kernel is architecturally underneath the rest of the operating system. I'm also slightly (but not much, really) concerned about having Freedo mistaken for Tux because of the lack of colors. As much as a monochromatic design will cut the costs, I'm pondering bringing in its light blue in, which might bring some more life to the T-shirts too. Not sure about that. Perhaps instead of adding one more color we could add another monochromatic design on the back, naming the distros or so. All that said, I'm very fond of gnu and freedo in the % sign. I wish we could somehow use that. Maybe it's just the hacker in me, but I suppose hackers are a big part of our target audience. Oh, something else that I hadn't got to, even in the original design, was to add a link to gnu.org/distros and perhaps Linux-libre.FSFLA.org. Perhaps, instead of 100% Free Software, we could phrase it 100% Free GNU/Linux-libre distros. This would avoid confusion about other Free Software projects that are not mentioned because they're not distros. Thanks a lot of the designs, please keep them coming! -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] Re: 100% Free Software T-shirt design
On Jun 6, 2010, crap0101 wrote: > I'm thinking about the result of draw '100% libre' (or most of it) only > using the distros' names and using an optional tin and discontinued > outline when needed That was actually the first thing we tried. I can probably still find the draft, the larger text looked a bit too cluttered and indistinct. Matías Fonzo suggested the letters naming the distros should be even more subtle in color, so that, from a distance, you'd pretty much only see the main message, and get the details once you got closer. I like that. > But in this case, i think the best result will be get drawing them by > hand. Heh. That would make me ineligible to work on it ;-) If I can't draw it with a keyboard, I can't draw it at all ;-) -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] Re: 100% Free Software distros T-shirt
On Jun 6, 2010, "Luis A. Guzmán García" wrote: > You said few colors, right? Yeah :-( I'm not even sure printing non-solid colors into T-shirts can be done affordably. > So this might not look like a great deal :( > http://ark.switnet.org/files/shirt/100freesoftware-mod.png This looks beautiful, indeed. I wonder if we could vectorial versions of all the logos and make a poster along these lines. That would be nice! -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] 100% Free Software T-shirt design
Islene (wife) and I have been working on a T-shirt design for FSFLA at FISL, to promote the 100% Free distros, that people could print and use at other events all over. What we have so far is an early, low-polish draft. It has few colors, so that T-shirt printing can be done at low cost. Different colors for the letters will probably be needed for different background colors, for better contrast. These same colors worked well with dark green last year, but we should probably use other colors this time. http://fsfla.org/svnwiki/blogs/lxo/draft/100freesoftware.png http://fsfla.org/svnwiki/blogs/lxo/draft/100freesoftware.svg Improvements to the design are welcome. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] [en] Take your freedom back, with Linux-2.6.33-libre
e that's not installed won't steer users toward that firmware, because the hash code won't immediately identify it. Thus, if the user insists on installing this firmware, Linux-libre will work with it, but it is very unlikely anyone will install the firmware because of Linux-libre. Join us at linux-li...@fsfla.org and let us know your suggestions, other ways to address this issue, or your opinion about this plan and whether it might be accepted upstream. Feedback and help are welcome! In the mean time, Be Free! with Linux-2.6.33-libre, and help us reverse the growing dependency of Linux on non-Free firmware. == About Linux-libre Linux-libre is a project maintained by FSFLA, that releases cleaned-up versions of Linux, suitable for use in distributions that comply with the Free Software Distribution Guidelines published by the GNU project, and by users who wish to run Free versions of Linux on their GNU systems. The project offers cleaning-up scripts and Free sources, binaries for some Free GNU/Linux-libre distributions, binaries to replace with minimal changes the kernels in non-Free GNU/Linux distributions: Freed-ebian and Freed-ora, and artwork with GNU and the Linux-libre mascot: Freedo, the clean, Free and user-friendly light-blue penguin. Visit our web site and Be Free! http://linux-libre.fsfla.org/ http://www.gnu.org/distros/ == About FSFLA Free Software Foundation Latin America joined in 2005 the international FSF network, previously formed by Free Software Foundations in the United States, in Europe and in India. These sister organizations work in their corresponding geographies towards promoting the same Free Software ideals and defending the same freedoms for software users and developers, working locally but cooperating globally. http://www.fsfla.org/ Copyright 2010 FSFLA Permission is granted to make and distribute verbatim copies of this entire document without royalty, provided the copyright notice, the document's official URL, and this permission notice are preserved. Permission is also granted to make and distribute verbatim copies of individual sections of this document worldwide without royalty provided the copyright notice and the permission notice above are preserved, and the document's official URL is preserved or replaced by the individual section's official URL. http://www.fsfla.org/anuncio/2010-03-Linux-2.6.33-libre --- End Message --- -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Incoming distros page at libreplanet
On Nov 13, 2009, Rubén Rodríguez Pérez wrote: > I've created a new page at libreplanet listing the incoming free > distributions that I know. If you know of other projects or hackers > interested in creating a new free distro, add it to the page or tell it > here and I will add them. There's Amagi http://amagi.gnu.org.ve/ for the Lemote Yeeloong. Octavio Rossell (Cc:ed) is involved in its development. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] Re: [Gnewsense-dev] 9wm - No FSF Free
On Aug 31, 2009, Ali Gunduz wrote: > On Mon, Aug 31, 2009 at 3:22 AM, Alexandre Oliva wrote: >> Given that copyright prohibits modification, and the license doesn't >> grant permission for modifications, I think it's not enough for freedoms >> #1 and #3 to be respected :-( > AFAIK FSF doesn't see requirement of modifications to be only > distributed in form of patches as software freedom violation. That's my understanding as well, but that's not the issue. A patch, in as much as it is a derived work, requires permission from the copyright holder of the original work to be created and distributed. No such permission is granted, therefore neither the creation nor the distribution of such derived works are permitted. > http://gnuplot.cvs.sourceforge.net/gnuplot/gnuplot/Copyright?view=markup. See it says: * Permission to modify the software is granted but such a permission is missing in the 9wm license. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[GNU-linux-libre] Re: [Gnewsense-dev] 9wm - No FSF Free
On Aug 28, 2009, "Paul O'Malley - gnu's not unix -" wrote: > Rubén Rodríguez Pérez wrote: >> Its problem is the absence of *explicit* permission for >> modifications: >> Permission is granted to all sentient beings to use this software, >> to make copies of it, and to distribute those copies > The four freedoms don't look like they are being challenged, or am I wrong? Given that copyright prohibits modification, and the license doesn't grant permission for modifications, I think it's not enough for freedoms #1 and #3 to be respected :-( -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files
On Aug 21, 2009, Daniel Olivera wrote: > Yavor Doganov escribió: >> So, if someone writes a fancy script whose whole purpose is to >> download many popular non-free packages (Opera, Adobe's PDF reader, >> etc.) and install them, and he releases it under a free license such >> as GPL, it would be acceptable for inclusion in Ututo? > No. > Script is ok better if is gpl [en; es below] Err... Your answer seems contradictory, I sense some language barrier, so I'll try my broken Spanish (below) to clarify. You appear to say that a Free script, licensed under the GPL, that downloads and installs a non-Free program, is not acceptable for inclusion in UTUTO (“No.”), but that the script would be “ok, better if it was GPL”, which it already is. Let me rephrase the question: would a Free script like the one below, whose sole purpose is to download and install and/or run a specific non-Free program, from a site explicitly mentioned in the script, be acceptable in UTUTO XS? Why? [es] Err... Tu respuesta me parece contradictoria, siento que hay dificultades con los idiomas, entonces voy a intentar usar mi español limitado para clarificar. Me parece que dices que un script Libre, licenciado bajo la GPL, que baja y instala un programa no-Libre, no es aceptable para inclusión en UTUTO (“No.”), pero que el script sería “ok, mejor si fuera GPL”, lo que ya es. Me permita hacer la pregunta con otras palabras: ¿un script Libre como lo que está abajo, cuya única finalidad es bajar y instalar y/o ejecutar un programa específico, no-Libre, desde un sitio explícitamente mencionado en el script, sería aceptable en UTUTO XS? ¿Por qué? #! /bin/sh -e # Copyright 2009 Evil Corp # This script is licensed under the GNU GPL. # Este script está licenciado bajo la GNU GPL. # [... FSF ... 51 Franklin St ... http://gnu.org ...] URL=http://www.evil.com/sekrit; export URL wget -q -O - $URL/EULA | more case $LANG in) es*) echo Si has leído la EULA y aceptas sus restricciones, presione ENTER echo Si no los aceptas, presione "^C" ahora ;; *) echo If you read the EULA and accept its restrictions, press ENTER echo If you do not accept them, press "^C" now ;; esac read accept DIR=/opt/evilcorp/sekrit; export DIR mkdir -p $DIR echo $accept >> $DIR/.license wget -q -O - $URL/install.sh | sh exec $DIR/bin/sekrit -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files
On Aug 21, 2009, Daniel Olivera wrote: > Alexandre Oliva escribió: >> I hope there's no dispute that drivers are software, and that, per the >> definition, software is information for practical use. > What definition? The one in the Free System Distribution Guidelines. > we need make a "line" according to our objectives We have a line, but it moves from time to time. Years ago, it may have been as simple as what you describe: if it's Free Software, it's ok. I'm pretty sure the GNU philosophy wasn't limited to this back when UTUTO started, but that doesn't matter. Nowadays, the requirements are more stringent: software must not induce or encourage users to install non-Free Software. Heck, RMS has recently requested that several distros remove ndiswrapper, even though it is Free Software, and it doesn't request any non-Free Software. The way it encourages users to install non-Free Software is by carrying a message from the developers of the distro to the user, a message that goes like: “I think it is so important for you to install non-Free drivers that use the NDIS API that I maintain this otherwise-useless program to my distro”. If any useful NDIS driver existed that was Free Software, that would be enough of a reason to offer ndiswrapper. But as it stands today, ndiswrapper doesn't belong in distros that share the values of the Free Software Movement. We understand that any non-Free Software is an aggression against society, and that the unethical deprivation of freedoms is harmful to the user. Any software that requires or suggests the acceptance of such an aggression is not software we should promote or endorse. So, even if you reject the argument that some Linux drivers ask for non-Free Software, or minimize the effects of printing error messages out of failure to load the requested pieces of firmware, it still holds that these drivers are only useful if the user installs non-Free Software. So the message you send when you fight for their inclusion is: “I think it is so important for you to install non-Free firmware that I maintain these otherwise-useless drivers in my distro”. That you modify their error messages, so as to pass some criterion, rather than deleting or disabling them, makes the message even worse, for it shows how important it is to you. So please, pretty please, don't send this message to your users. There's no objection to the possibility that users install and use non-Free firmware along with the non-Free drivers that request them. But a FSD should not ship those drivers any more than it should ship the corresponding non-Free firmware. > Tivolization is another process. I know, I was merely checking all the ways I'm aware of that could render Software non-Free, against the FSDG and Diego's claim about it. I can't find support for Diego's claim in any of them. Maybe we should both let him answer what he was thinking of, rather than speculating? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files
On Aug 20, 2009, Diego Saravia wrote: > also, from these guides nothing suggest to no distribute free drives Err... I don't quite see how a driver could become non-Free given the current requirements. I hope there's no dispute that drivers are software, and that, per the definition, software is information for practical use. Therefore, it must be available in source form, under a Free license, and not be significantly encumbered by trademarks or patents. Are you thinking of tivoization or some other technical measure that could render the driver non-Free? Or some other juridic measure along the lines of DRM/DMCA-related restrictions? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files
On Aug 20, 2009, Karl Goetz wrote: > If my reading of [1] is correct, the only compiling required for b43 > chips (broadcoms) is to build the openfwwf firmware. If the kernel is Linux 2.6.30 or above, yes. Some code was added to support openfwwf explicitly (some differences in file format, IIUC, in addition to a different filename), and it's regarded as a second-class citizen, with the non-Free firmware still preferred (requested first). Linux-libre fixes that, of course. > I'm still not convinced the loading mechanism does the user harm. (As > opposed to an error telling them to install proprietary software on > load, where I definitely agree its a problem.) I don't think it's the loading mechanism per se, it's the request issued by the kernel. If there was any way to make it work without the kernel issuing a request for a piece of software that is known to be non-Free, I think it would be acceptable to keep it enabled. But IMHO no program that goes “gimme non-Free Software!” belongs in a Free System Distribution. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files
On Aug 19, 2009, Daniel Olivera wrote: > UTUTO only distribute 4 freedom software that is our law. http://www.ututo.org/web/modules/definitions/definitions.php [1] UTUTO es y será siempre un proyecto en el marco de la filosofía GNU. My attempt to translate it to English (this remains in Spanish in the site, even in the English version): [1] UTUTO is and will always be a project in conformance (?) with the GNU philosophy Now, the GNU philosophy goes far beyond the 4 freedoms and the FSD, far beyond distributing only software that respects the 4 freedoms. The Free System Distribution Guidelines are an integral and important part of the GNU philosophy, although only recently were they put into a single document. So I expect no less than compliance with these guidelines, from any project recommended by the GNU project, and from anyone who shares the GNU philosophy. I expect no less from the UTUTO project, the very first to undertake these efforts. It's a big surprise and disappointment to me that we're still having this conversation :-( -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files
On Aug 19, 2009, Diego Saravia wrote: >> >> I'm lost. Does this mean that Ututo's kernel is already not requesting >> non-free firmware, but you'd like to change it back? > we were the first to not distribute blobs and continue with that But that's not what you claimed UTUTO didn't do, and your present claims are missing a key part of what you said before that UTUTO already did. Was there a misunderstanding in what you wrote below? > 2009/8/18 Karl Berry : >> how about if the GPL'd code is included, but with a disabled firmware >> loading mechanism, and instead of printing the missing fw files, they >> print an error message with an explanation why the device is not >> supported? > its ok, its what ututo does Last I looked, about a week ago, UTUTO didn't even disable the printing of the error messages, and the firmware-loading machinery was definitely enabled. What is it that changed since then? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files
On Aug 19, 2009, Diego Saravia wrote: > welcome to gnash, gnash only works with propietary codified content, Err... Where did you get that idea? There are Free Flash/Shockwave programs. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: Fwd: [GNU-linux-libre] A call to free software, and its users
On Aug 19, 2009, Diego Saravia wrote: > 2009/8/19 Alexandre Oliva : >> On Aug 19, 2009, Diego Saravia wrote: >> The important question is whether a particular piece of data is >> information for practical use. > I do not agree with that concept > For me is equal relevant non free software, than non free art If you place requirements on art that are as stringent as those you place on software, there's a chance we can reach an agreement. But if you were to relax the requirements for them all, then agreement would be difficult. See, it's not that I think art should *not* respect the 4 freedoms, it's that I haven't ever seen a justification, on ethical and moral grounds, for the 4 freedoms applied to art, as I have for software and other kinds of information for practical use. The practical use is key for the justifications I've seen to apply. >> Yeah, it does. It's unfortunate that the user isn't informed about it, >> but it's not even close to actually demanding the user to install and >> run non-Free Software. > not? runing non free is less important to inform user that there > is a way to run non-free? Informing the user that there is a way to run non-Free, rather than warning about the trap it sets, means regarding running non-Free as something possibly good. Informing the user in that way is very bad, whereas running non-Free is only unfortunate. >> presented to it for execution, specifically demands non-Free Software to >> be installed. > demands? > not sugest? The driver requests the file and refuses to do any useful work without it. That's a demand. > thats worst than RUN non-free? Yes, it is. If installing and running non-Free Software is a decision the user has already made, as long as the user doesn't recommend or induce anyone else to do the same or further empowers the aggressor (network effects, pay per use, etc), the user is the only victim of the continued use of that piece of software. However, if a piece of software induces the user to get a piece of non-Free Software installed on the computer where it wasn't before, the software is effectively inviting one more victim into the trap. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files
On Aug 19, 2009, Diego Saravia wrote:
> 2009/8/18 Karl Berry :
>> name = "some/firmware.bin";
>> if (request_firmware (&fw, name, dev) < 0) {
>> how about if the GPL'd code is included, but with a disabled firmware
>> loading mechanism
> its what ututo does
Oh, nice that you guys fixed it already! Awesome! Thanks!
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] A call to free software, and its users
On Aug 19, 2009, Diego Saravia wrote: > trying to separate code from data is like argue about angel's shoulders There seems to be an assumed dichotomy here that isn't true. > every data codification could be use to encode software, or seen as software Every piece of code is data, true. And irrelevant. The important question is whether a particular piece of data is information for practical use. If it is, a number of moral and ethical imperatives apply, that don't necessarily apply to other kinds of data. And that's why it matters. Fortunately, most often it easy to determine whether or not a piece of data is information for practical use. >> Gnash won't stop you from running them, but there's nothing in Gnash >> that asks the user (or any other piece of software) for any non-Free >> Software. > It runs non-free without asking Yeah, it does. It's unfortunate that the user isn't informed about it, but it's not even close to actually demanding the user to install and run non-Free Software. Warning users about non-Free Software would require a feature to be implemented, to tell Free and non-Free Software apart and display a message to the user, very much like the feature suggested in “The Javascript trap” article to limit the use of obfuscript. It would be nice to have this feature, but it's not an imperative, for there's no inducement or endorsement involved, it's a mere enablement. Linux, OTOH, has implemented a feature in dozens of drivers that, rather than just sitting there waiting for Free or non-Free Software to be presented to it for execution, specifically demands non-Free Software to be installed. That's not mere enablement, that's inducement, endorsement, and obtrusion. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files
On Aug 19, 2009, Karl Goetz wrote: > Why does the firmware load mechanism need to be disabled? In principle, it doesn't have to. But the way this mechanism was designed in Linux, the kernel has to explictly decide to request some file that happens to be known to be non-Free. > I'd have thought leaving it enabled is more likely to encourage > development on free alternatives (by lowering the barrier to entry > when it comes to testing them). That's possible, but that's a matter of convenience, that shouldn't take precedence over ethical issues. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files
On Aug 18, 2009, k...@freefriends.org (Karl Berry) wrote:
> name = "some/firmware.bin";
> if (request_firmware (&fw, name, dev) < 0) {
> printk (ERROR "%s: failed to load firmware `%s'", dev->name, name);
> Thanks.
> So ... how about if the GPL'd code is included, but with a disabled
> firmware loading mechanism, and instead of printing the missing fw
> files, they print an error message with an explanation why the device is
> not supported?
Hey, cool!, I'm going to get Linux-libre to do just that in no time!
Literally in no time! Because that's exactly what we do :-)
> That way, the GPL'd code is included, the nonfree firmware code is not
> being "advertised", and there is a more viable hope that some developer
> will be found to work on free alternatives.
My thinking a well. Of course anyone who perceives such drivers as
pointless (a perfectly legitimate position, FWIW) may very well remove
them from Linux-libre, or just save some compile-time CPU cycles
disabling them in config files.
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] A call to free software, and its users
On Aug 18, 2009, Rubén Rodríguez Pérez wrote: > Gnash allows you -with no non-free software required- to view animations > stored in a proprietary format, like Abiword can open a word file. > Also remember: a non-free firmware file is *not* data in a proprietary > format (like a word file), it is a non-free program. So using Gnash as a > comparison is misleading. The comparison is not as misleading as it might seem, because Flash/ShockWave files often contain actual programs written in ActionScript (a variant of JavaScript/ECMAScript). Most such programs are non-Free. Gnash won't stop you from running them, but there's nothing in Gnash that asks the user (or any other piece of software) for any non-Free Software. It is only an enabler, not a promoter of non-Free Software. Very much like say GNU libc. Linux, OTOH, even if all pieces of non-Free Software are removed from its guts, is still more than an enabler of the use of non-Free Software. It's a promoter, because it contains drivers that request specific pieces of non-Free Software. Nearly all drivers that do refuse to work until you satisfy their demand. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files
On Aug 17, 2009, Diego Saravia wrote: > 2009/8/17 Alexandre Oliva : >> On Aug 17, 2009, Diego Saravia wrote: >> >>> 2009/8/17 Richard Stallman >>> If users get the driver and microcode on their own, they can install >>> and run them. >>> thats not the point >> It is an important point nevertheless. >> Do you acknowledge that point? Do you agree with it, i.e., do you agree >> that users can get the driver and firmware on their own and install it, >> regardless of whatever ships in a Free System Distribution? > That users can do that is a reality, I cant do anything about that Nobody expects you to do anything about it. Nobody's asking you to stop anyone from installing whatever they want. Do you agree that users can get the driver and firmware on their own and install it, regardless of whatever ships in a Free System Distribution? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files
On Aug 17, 2009, k...@freefriends.org (Karl Berry) wrote:
> Excuse the interruption, but can someone point me at an example of the
> actual GPL'd code which is loading the nonfree firmware?
All the examples in Linux follow more or less this pattern:
name = "some/firmware.bin";
if (request_firmware (&fw, name, dev) < 0) {
printk (ERROR "%s: failed to load firmware `%s'", dev->name, name);
return -EINVAL;
}
... load firmware ...
grep for request_firmware in the Linux source tree and you'll find
hundreds of examples, less than a handful of which are acceptable.
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files
On Aug 17, 2009, Diego Saravia wrote: > 2009/8/17 Richard Stallman > If users get the driver and microcode on their own, they can install > and run them. > thats not the point It is an important point nevertheless. Do you acknowledge that point? Do you agree with it, i.e., do you agree that users can get the driver and firmware on their own and install it, regardless of whatever ships in a Free System Distribution? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: [GNU-linux-libre] Re: any Free BSD variant?
On Jun 19, 2009, Yavor Doganov wrote:
> Rubén Rodríguez Pérez wrote:
>> Is true that Debian is not as free as we'd like, but they are the
>> closer we have,
> I don't think so. Please correct me if I'm wrong -- I read only two
> Fedora lists (mostly to watch Alexandre Oliva's heroic Sisyphean
> efforts,
:-)
> and for general information) -- but:
> - Fedora doesn't have any contrib/non-free repos ("contrib" in
> Debian's meaning -- i.e. free software that depends on non-free)
In a sense, Debian's policy of separating Free from non-Free would be
more helpful than Fedora's bundling of Free and non-Free packages into a
single repository, but it would only be actually more helpful if it was
done for real (rather than, “oh, but we need a kernel in main and we
don't want to offer a Free kernel, so...”), and if the same criteria
were used (Debian regards as non-Free a lot of stuff that fits per the
GNU Free System Distribution Guidelines). So in the end Fedora ends up
easier to clean up, yes.
>> > > Basing on debian is a first step.
>> > Fully agreed.
>> And another reason to keep working with them.
> Of course. Cooperation is always a good thing. I never meant to burn
> all bridges out there.
Cooperation isn't always a good thing. It is when the goal is a good
one. Cooperating with evil is no good ;-)
Which is not meant as implying that Debian does evil, BTW. I'm only
disputing the sweeping generalization.
I do think cooperating with nearly-Free distros is a good thing, not so
much because they're easy for us to derive Free distros from, but also
because taking active part in their development keeps some decisions in
check.
Say, if people who cared deeply about software freedom we were to burn
all bridges and leave that room, decisions would be dominated by people
who did not care deeply about software freedom. The end result would be
detrimental to everyone.
Whereas if we remain involved and influential in their decision-making
processes, even when we're defeated, we're probably at least drawing
attention to an important constituency, to the points that matter to us,
which is likely to bring the balance closer to our needs.
Just like the GNU/Linux naming issue, maintaining Linux libre and
getting popular nearly-Free distros to take the final steps to become
Free are issues that we must not perceive and act on as if they were
battles or wars, but rather as the possibly never-ending educational
campaigns that they are.
As painful as taking a part in these campaigns are, I believe we can
make more of a difference addressing communities that aren't fully
aligned with our goals, trying to enlighten them, than preaching to our
own choir, so to speak.
Having at least one fully Free reference distro is essential, but
ultimately the goal of the Free Software Movement is not to develop one
Free distro, it's for *all* software users to be Free.
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
___
gnu-linux-libre mailing list
gnu-linux-libre@nongnu.org
http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre
[GNU-linux-libre] Re: [Gnewsense-dev] Re: Thunderbird recommending non-free software
On Jun 9, 2009, Yavor Doganov wrote: > IceCrow, IceRooster or some other Ice$BIRD in the true spirit of the > "iceweaselization", maybe... Oh my, if only GNU Carrier Pigeon made sense for a MUA, rather than an MTA... :-( -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer ___ gnu-linux-libre mailing list gnu-linux-libre@nongnu.org http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre
Re: [GNU-linux-libre] naming the Linux-libre artwork
On Apr 15, 2009, Rubén Rodríguez Pérez wrote: > I've made some improvements to my svg version of... Freetz, by now ;) Jeff Moe is back, and he suggested we call him Freedo. I loved it. Anyone against naming Rubén's version Freedo, and adopting him as our logo, so that I can get the T-shirt printing underway? http://www.fsfla.org/pipermail/linux-libre/attachments/20090415/1969b25d/attachment-0001.svg -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer ___ gnu-linux-libre mailing list gnu-linux-libre@nongnu.org http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre
Re: [GNU-linux-libre] naming the Linux-libre artwork
On Apr 15, 2009, Rubén Rodríguez Pérez wrote: > I've made some improvements to my svg version of... Freetz, by now ;) Lovely clean look. Is anyone in love with the light blue? I'm thinking we could save one color (printing costs) by replacing it with black, like most penguins out there, and remaking the eyes. Something like this, but... with a proper face expression :-) <> -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer ___ gnu-linux-libre mailing list gnu-linux-libre@nongnu.org http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre
[GNU-linux-libre] Re: [Team] naming the Linux-libre artwork
On Apr 15, 2009, Fabianne Balvedi wrote: > When I just saw the page, I thought they were the same, > stux and freetz, so I dint't get the idea why there should be > two mascots or two names for the same mascot. Yeah, that's kind of my fault. When I first say Stux, I thought he was perfect. It was Tomás who pointed out he was a prisoner. When Freetz came up, I had it in my mind that they were close, but not quite the same, kind of like those "which soap makes for whiter clothes" comparisons in soap ads. So I started using Stux in the context of the non-Free Linux (cute and friendly looks, but not Free), and Freetz in the context of Linux-libre. But I was hardly clear on that. I don't think it's too late to fix it. Naming them differently is supposed to help with that. > Also I dont't know where the name freetz came from, First time I thought of this name was during a conversation (not to say heated discussion) about how unfair it was that the name of the kernel ended up in the name of the operating system product of the company I work with, while the name of the operating system didn't. It was wordplay with Freax, the original name for Linux, but I don't think Freetz stood for a kernel in the hypothetical scenario I presented. > so If I have to pick one, I'd stick with the stuck :) We could, but we don't have to :-) Thanks for your feedback. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer ___ gnu-linux-libre mailing list gnu-linux-libre@nongnu.org http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre
Re: [GNU-linux-libre] naming the Linux-libre artwork
On Apr 15, 2009, Rubén Rodríguez Pérez wrote: >> Yes, the last one is funny and I agree that Freetz could be an >> interesting official mascot. > And also the name Stux is a good pun for refering to the regular blobbed > tux, but I don't like it if you apply to linux-libre mascots. That's the thing: Stux stands for the blobbed (tuxic :-) kernel. It looks nice and appealing, but it takes effort to realize that it's deprived of freedom. > I vote for the penguin in the shower, but I don't love Freetz as a name > (we can give him a guitar, though). Heh. I kind of like Freetz, but I can't say I'm in love with it. It's one syllable, it has 'Free' in the name; it's a bit ironic in that Linus wanted Linux to have been named Freax, it does sound like a pet name, but it's hardly perfect. I guess we'll always be open to suggestions, at least until one name sticks :-) How about this: whoever comes up with a name for, erhm, the penguin currently-named Freetz gets a Free license to run, modify and distribute Linux-libre! ;-) -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer ___ gnu-linux-libre mailing list gnu-linux-libre@nongnu.org http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre
