Hi Magic, I should say upfront that I'm not criticizing Trisquel, nor am I
trying to derail it. I just liked the idea and am trying to find some ways
for mass adoption. That's all. I'm aware of the question of producing a free
OS with best user experience with as low workload on developers as possible
and with the limited resources at hand. This is a three-legged scale. We
can't have it all and *this* is a reason for compromise - at least pour some
thoughts on it. That's what I've been trying to do.
My original intent was separating FSDG requirements, distro personalization,
and Debian vs. Ubuntu. But the ihttp://www.fsf.org/openofficessues are so
intertwined that I don't know how to discuss them separately. OTOH rolling
all into one thread might cause spreading it too thin, which might also be
counterproductive.
You are right in stating that following a rolling release (Debian testing)
would have required far more work than following a LTS one - with the
presumption that most packages would be scrutinized for strict FSDG
compliance, and there were some changes regarding personality (uniqueness) of
Trisquel. But imagine that there were no FSDG compliance work needed for most
of the packages, and that Trisquel had just a minimal personality - i.e.
heavily depended on whatever desktop environment has to offer off the shelf.
I'm oversimplifying the case for the sake of clarity.
Debian/main repository is kind of approved by FSF, if I'm not mistaken? If
Trisquel taps on Debian testing/main repository (free riding on original
Debian repositories) and add selected few apps from contrib and non-free,
liberate them, and include them into a private Trisquel repository, then dev
work would only be needed for those liberated apps. There would be literally
no work needed to maintain the "main". Then maintaining Debian testing could
become much easier. Of course, on the condition that FSDG allows using Debian
main repo untouched. Am I missing something here?
This my main reasons for "unpersonalized" distro and a bit loosened FSDG
rules.
As per the firmware, well of course firmware is software. But to be inside OS
domain, a software should be run by the OS. Software run on the hardware
still belongs to hardware domain. A modem card has onboard ROM and runs
firmware onboard. So a proprietary modem card locally running a non-free
firmware off of onboard ROM, doesn't violate FSDG restrictions for free OS.
Then how can it be named violation when a cousin of this modem card runs the
same firmware locally off of onboard RAM? The only difference is that, in the
previous case ROM based firmware is always there, and in the second case it's
been uploaded (just upload, not run) by the OS into the modem cards RAM. This
is why I called firmware blobs as gray area.
