Re: [GNU-linux-libre] Differences between Trisquel's kernel and linux-libre for i915 (video)

[Jason Self]

Hi there, it appears you've reached the wrong mailing list - this one
isn't for the kernel. The correct one can be found at
https://linux-libre.fsfla.org. However, it's probably not useful to
start another one there. As a case in point, I've already sought
information from yet another separate location. Having this
conversation spread out over many places might not be useful.


pgpgGxyoOeEaT.pgp
Description: OpenPGP digital signature

Re: [GNU-linux-libre] ION Project

[Jason Self]

On Sat, 04 Nov 2023 19:14:11 -0300
d1nc...@ion.lc wrote:

> I would ask you to review the system or some 
> of it's components

To be sure are you looking to have ION GNU/Linux added to
gnu.org/distros? In that case on this list we evaluate the entire
distro - not just pieces of it.

Outside of the distro review process an option for individual pieces
can be the Free Software Directory at https://directory.fsf.org/

In terms of reviewing the entire distro I was able to quickly find
programs that would need to be either modified or removed entirely.

The nonfree VMWare Workstation
Brave browser (non-free add-ons)

I don't intend for this to be an exhaustive list. Given that I was
able to locate these so quickly I recommend doing a review of all of
your packages and other aspects of the distro for compliance with the
GNU FSDG, making appropriate removals or modifications and re-submit
the distro at that time.


pgplbKuGcOP8B.pgp
Description: OpenPGP digital signature

Re: [GNU-linux-libre] is the license of 'bass' acceptable?

[Jason Self]

On Tue, 4 Jul 2023 15:24:21 -0400
bill-auger  wrote:

> On Tue, 4 Jul 2023 15:05:27 -0400 bill-auger wrote:
> > may we return to the original topic?  
> 
> ill do that one better - i changed the subject and will recap
> 
> so far:
> 
> gnutoo and i believe that per its explicit wording, it is non-free

The license holds:

> You may charge a reasonable copying fee for this archive

I'm thinking of https://www.gnu.org/philosophy/selling.html which
holds that

> The one exception is in the case where binaries are distributed
> without the corresponding complete source code. Those who do this
> are required by the GNU GPL to provide source code on subsequent
> request. Without a limit on the fee for the source code, they would
> be able set a fee too large for anyone to pay—such as a billion
> dollars—and thus pretend to release source code while in truth
> concealing it. So in this case we have to limit the fee for source
> in order to ensure the user's freedom. In ordinary situations,
> however, there is no such justification for limiting distribution
> fees, so we do not limit them.

And so, in cases where distribution fees are not being limited, you
should also be able to charge a distribution fee that's
*un*reasonable, which makes this a non-free license.

The license goes on to say:

> You may not charge a fee for the game itself. This includes
> reselling the game as an individual item.

A program where you cannot charge for copies is also non-free.

To me, both of those items plus what's stated in the preamble, tell
me that the people were intending the copies be distributed gratis.

> ruben suggested that the wording is confusing, and that GNU has
> previously established a precedent, which accepts a license with
> the same confusing requirement, and so it should be acceptable
> 
> RMS threw us a curve-ball, and suggested that the previously
> established precedent should be reviewed or revised first
> 
> how shall we resolve this?

Is it time to revisit the established precedent for the SIL Open Font
License?


pgpy6VXm7MXcJ.pgp
Description: OpenPGP digital signature

Re: [GNU-linux-libre] programs which only use-case is non-free Was: Adding some scummvm

[Jason Self]

On Tue, 25 Apr 2023 23:36:34 -0400
bill-auger  wrote:

> this is one of those FSDG grey-areas, for which it would be good to
> have some consensus

It sounds like what you're talking about his how to handle
distro-specific packaging decisions. It's important to note that the 
FSDG doesn't seem to prevent distro maintainers from adopting an even
broader interpretation of "steering users to nonfree software" than
what the FSDG might require, nor does it seem to require distro 
maintainers to include any software that they don't wish to, for
whatever reason they don't wish to, even if it would be permissible
under the FSDG, so they'll still be able to exclude such software
regardless.


pgprurHBMuXRA.pgp
Description: OpenPGP digital signature

Re: [GNU-linux-libre] Adding some scummvm game(s) to the "List of software that does not respect the Free System Distribution Guidelines".

[Jason Self]

On Thu, 20 Apr 2023 21:33:32 -0400
Richard Stallman  wrote:

> What does "CCS" mean here?

It's supposed to be complete corresponding source code.


pgpy489yOhpTN.pgp
Description: OpenPGP digital signature

Re: [GNU-linux-libre] review of uruk

[Jason Self]

As I look through Uruk, the ISO files appears to be downloadable from
SourceForge but I'm not finding the source code for those. Where is
that located in order to generate them? I don't seem to find any
information on urukproject.org or the SourceForge project.

In addition, the IRC channel and mailing lists mentioned on
urukproject.org appear to be unavailable. Where do community members
interact?


pgpxEi3FW4lfj.pgp
Description: OpenPGP digital signature

Re: [GNU-linux-libre] Should the use of C#, Mono, and .NET still be discouraged?

[Jason Self]

To my understanding the patent situation hasn't changed.
https://www.fsf.org/news/dont-depend-on-mono
Which is a little complicated that while it's useful to have free
implementations of C#, we should arrange to depend on them as little
as possible.


pgppgN5SmZZao.pgp
Description: OpenPGP digital signature

[GNU-linux-libre] GNU FSDG and SaaSS

[Jason Self]

The GNU FSDG doesn't seem to speak to SaaSS. It seems to me that it
should.

What's driving the question is that I learned of Parabola including a
program called ydcv. It's used for translations (Chinese <-> English)
through the Youdao online translate service [0].

This wouldn't stop people from using their web browsers to do this;
only that distros shouldn't include programs that a mere frontend or
helper for SaaSS to encourage or steer people toward such things.

[0] https://www.parabola.nu/packages/community/x86_64/ydcv/


pgpH70Of8y5C9.pgp
Description: OpenPGP digital signature

Re: [GNU-linux-libre] linux ppc micropatch.c: why keep it?

[Jason Self]

I have been unable to locate this engineering bulletin myself. I opened
a support ticket with NXP asking for a copy. Just in case being able to
see the actual engineering bulletin is helpful in some way.


pgpwYuAlknGen.pgp
Description: OpenPGP digital signature

Re: [GNU-linux-libre] Non-free fonts embedded in PDF files packaged by free GNU/Linux distributions endorsed by FSF

[Jason Self]

Thanks for noticing this. Another option is to replace the embedded
font with one of the free ones like Liberation Serif, which is
metrically equivalent to Times New Roman.

All of the FSF-endorsed distro maintainers aren't on this list. To be
sure it's captured as an actionable item, it would be helpful to
report bugs in the relevant packages to the distro channels (for
example: https://trisquel.info/en/project/issues.)

signature.asc
Description: This is a digitally signed message part

Re: [GNU-linux-libre] reply FSF

[Jason Self]

Ineiev wote:
> I believe this results in a doubt that should be resolved:
> if Freenix doesn't "fork support", does it mean that it
> effectively directs its users to Slackware?

Ivan Zaigralin wrote:

> FSF has not told us the official FSF position concerning these
> hypothetical scenarios either.

If Childebert received a response from the FSF pointing to the matter
and stating that it "remained unresolved" (to make a quote) that seems
(to me) an unambiguous response from them saying it needs to be
addressed.

Perhaps forking the documentation is an appropriate next step then,
along with a response back to that person at the FSF to tell them that
this has been done.

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[Jason Self]

On Wed, 2019-02-20 at 19:37 -0500, Luke wrote:
> Additionally, the patches are expected to be ran against specific
> Chromium releases. Future releases of Chromium are not
> patched/audited
> yet by the ungoogled-chromium project and may leak to Google.
> See: https://github.com/Eloston/ungoogled-chromium/releases
> 
> The Guix package is building against Chromium 72.0.3626.109 whereas
> the latest release of Ungoogled-Chromium as of this moment is for
> 72.0.3626.96-1.

Ah I had missed this. Thank you for catching that. 

If Guix is going to use ungoogled-chromium not only as a way to remove
privacy problems but also to fix freedom problems (although it's not
clear to me that ungoogled-chromium actually solves all of the freedom
problems in the first place; an audit will need to be done) then they
will need to be limited to whatever releases ungoogled-chromium
provides, and updated only in lockstep with each other lest other
unknown freedom problems creep in due to not having been
reviewed/audited by the people behind ungoogled-chromium.

signature.asc
Description: This is a digitally signed message part

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[Jason Self]

bill-auger wrote:
> the most recent news regarding this (what appears to be the official
> release notes) indicates that guix is no longer using the "ungoogled"
> team as an upstream[1]

I think that message "no longer using a fork of Ungoogled-Chromium"
means the opposite: Whereas they'd previously been using a modified
(aka "forked" version) now they're using upstream directly. Perhaps
upstream made some changes which made it more suitable for their
purposes.

Re: [GNU-linux-libre] Chromium, ungoogled or otherwise, and Guix

[Jason Self]

On Tue, 2019-02-19 at 17:18 +0100, Giovanni Biscuolo wrote:
> do you have the bug number now?

34565

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34565

It seems to be disabled at build time only.

signature.asc
Description: This is a digitally signed message part

[GNU-linux-libre] Chromium, ungoogled or otherwise, and Guix

[Jason Self]

I decided to spend some time looking into Chromium, ungoogled-chromium, 
and Guix's methods, and the GNU FSDG.

Even if vanilla Chromium does check out to be 100% free software it's
already pretty easy to tell that it wouldn't be FSFG compliant, at
least not out of the box.

One is because of add-ons. It has a similiar problem to Firefox where
people get sent to a place with both free and proprietary add-ons.

Another is the support Widevine DRM, which seems to go against "the
distro must contain no DRM..." in the FSDG.

Thirdly, Chromium appears to ship with binaries in the source tree (the
ungoogled-chromium README mentions that they "strip binaries from the
source tree, and use those provided by the system or build them from
source".) This seems the appropriate thing to do for FSDG compliance,
since "all information for practical use in a free distribution must be
available in source form." The source tree of a program shouldn't
itself come with binaries, IMO, only source code.

My proposal would be to mention these items in the chromium-browser
entry on the libreplanet wiki either in addition to or in place of the
current references of licensing problems that the wiki page has.

Since some issues need fixing in Chromium regardless before an FSF-
endorsed distro could ship it I then turned my attention to ungoogled-
chromium to see if it could be a potential fix for those things. They
do seem to disable the webstore URLs so the add-on problem seems fixed
and stripping out binaries from the source tree seems to fix the third
problem, but they don't appear to remove the Widevine DRM.

As long as that remains the case it would seem that ungoogled-chromium
is also not suitable for inclusion in FSF-endorsed distros, at least
not out of the box. Since Guix has added ungoogled-chromium, without
seemingly have changed it to also tackle the DRM portion, I have
reported this to their bug tracker. I'm waiting to receive the bug
number.

The last item seems specific to Guix: Their method of building seems to
involve downloading Chromium, then runnning ungoogled-chromium over it,
and then building.

That would mean, if someone wanted to build it on Guix themselves, that
they'd also be going through those same steps. I don't know that FSF-
endorsed distros should be having their users download non-FSDG
compliant software in order to build them, even if its patched and
modified during the build process.

When LibreWRT was founded in 2010 (before it later merged into
libreCMC) we submitted a similiar question to the FSF, as to if it was
sufficient for the LibreWRT build scripts (which would be run by the
person building the firmware image from source, just like how someone
might instruct Guix to build from source) to download Linux and then
run the Linux-libre deblobbing scripts on it vs having the build
scripts instead download tarballs that were already cleaned up. I can't
seem to find the email from back then but the response was that we
needed to use already cleaned-up tarballs. Guix should do something
similar.

signature.asc
Description: This is a digitally signed message part

Re: [GNU-linux-libre] FSDG processes

[Jason Self]

Gábor Boskovits asked:
> 1. If there is a free software, how do we ensure that it remains
> free, or that it gets into the list of software with freedom issues?
> Do we supervise each commit?

My understanding is that each distro should be doing their own due
diligence to only include FSDG-compliant free software but from what I
read in the FSDG that doesn't necessarily have to be an "exhaustive"
process. The FSDG has a part regarding that under "Commitment to
Correct Mistakes":

> Most distribution development teams don't have the resources to 
> exhaustively check that their distribution meet all these criteria. 
> Neither do we. So we expect distros to occasionally contain mistakes:
> nonfree software that slipped through, etc. We don't reject a 
> distribution over mistakes. Our requirement is for the distribution 
> developers to have a firm commitment to promptly correct any mistakes
> that are reported to them.

> Do we have a central place, where freedom related bugs can be
> reported?

This mailing list is supposed to be a centralized place for discussion
of things common to endorsed distros. Freedom issues should fall under
there, unless it's something that is somehow exclusive to one distro.

> 2. If there is a claim, that a given software has freedom issues, do
> we accept that without any investigation? How do we protect ourselves
> from a malicious actor faking these reports to hurt the reputation or
> market share of a software?

I don't think it would make any sense to do that. If someone reports
that a freedom problem exists, and if it's not immediately obvious
where the problem is, it seems perfectly reasonable to ask the person
to point to the specific freedom problem that they're seeing.

> On the contrary, if we get a report that the freedom issues don't
> exist any more, then we have to investigate that?

This is probably folded up into the distro's own due diligence that
they should already be doing.

> 3. If we have to investigate that a freedom issue does not exist any
> more, how is that done? Where can we track the progress of such an
> investigation? What is needed to take part in that?

I imagine that depends on the scenario and if a distro using their own
internal resources or if it's some sort of cross-distro collaboration.

> 4. What does 'files with unclear licenses' mean?
> 
> 5. There is a whole bunch of licenses listed as acceptable by FSDG,
> including for example the 'modified BSD license', that do not mandate
> to put anything your source file, just drop the LICENSE file in the
> root folder of the project. The only thing I have seen why you would
> include anything license related in your files, is that the licensing
> remains clear in the case the file is copied out of the source tree.
> It seems to me there is a contradiction here: there is a license
> approved by the FSDG, but it is not approved at the same time, as
> software gets rejected, stating that the license is unclear, however
> the author did everything the license required. To me the only
> resolution to this would be:
> either to accept that files without the license notice, for licenses
> that don't mandate their inclusion is really under the license;
> or to declare all licenses not mandating the inclusion of a license
> notice incompatible to the FSDG. What is your opinion on this?

I'm combining 4 and 5 since they seem similar. Broadly-speaking there
are two ways to handling copyright and licensing information with a
free software project: File-scope notices and centralized notices.
These are discussed more fully in [0]. My take is that whether a given
program uses either method shouldn't have any bearing on being suitable
for inclusion; because I see nothing in the GNU FSDG that would require
distros to only include programs that use file-scope notices. Indeed,
that would unnecessarily limit the number of free software programs
available. For programs that use centralized notices that should apply
to the entire program unless there is some notice to the contrary.

So; a file without a license header isn't necessarily a problem. It
needs to be evaluated within the context of that program (i.e., it
might lack a license header because the project uses centralized
notices.)

Even programs like Linux-libre don't have copyright and licensing
information inside each and every file. The standard in the kernel
community is that things without specific license headers in the kernel
are treated as being under the project's default license of GPLv2-only.

[0] http://softwarefreedom.org/resources/2012/ManagingCopyrightInformat
ion.html

signature.asc
Description: This is a digitally signed message part

Re: [GNU-linux-libre] Adding Inferno to GNU Guix: font issues.

[Jason Self]

On Sat, 2018-11-03 at 21:22 +0100, Diego Nicola Barbato wrote:
> Is it enough to remove the non-free fonts in order to make Inferno
> compatible with the FSDG, or are there further issues, namely that 
> the fonts can not be rebuilt from source (i.e. there is no source) 

Under the FSDG fonts are mentioned as part of "information for
practical use." [0]

The FSDG goes on to say that "all information for practical use in a
free distribution must be available in source form."

If there is no source then it can't meet that criteria. It also sounds
like a GPL violation if they're licensed in that way as you say and
have no source. That's another reason to avoid them then since there
would be no way to comply with the license even if they were added.

[0] https://www.gnu.org/distros/free-system-distribution-guidelines.htm
l

Re: [GNU-linux-libre] [gnu.org #1308285] add uruk gnu/linux to free list

[Jason Self]

There may be a misunderstanding then Thérèse; the GNU Webmastering
Guidelines had never asked for the Webmasters themselves to write to
the list. https://www.gnu.org/server/standards/#distros
#3 has that the requestor (not the Webmasters) write to the list after
the Webmasters have verified (in #1) that the people requesting are the
primary developers and (in #2) briefly checked that the distro is a
feasible candidate.

> By the way, I wonder what webmasters have to do in this 
> process, except acting as spam filter.

That is effectively it, yes: To make sure that the people asking for
the endorsement are the right people, since only the primary developers
can request endorsement -- the users of the distro should be referred
back to the primary developers -- and to filter out distros that
clearly (based on only a brief examination) won't qualify.

Re: [GNU-linux-libre] Amendment proposal for incoming distros page

[Jason Self]

In thinking on this, since I do this in my spare time and don't seem
to work fast enough for André so as to get an entire distro reviewed
in 4 days before it's called "stalled", I hereby resign as the
Hyperbola application manager. Someone else can do it.

Re: [GNU-linux-libre] Amendment proposal for incoming distros page

[Jason Self]

This is something I do in my spare time. The usual review will take
weeks. Sometimes months. (Remember the FSF said that PureOS took
something like two years.) This is not some automated rote process. It
takes a lot of thankless hard work and thought.

Re: [GNU-linux-libre] Amendment proposal for incoming distros page

[Jason Self]

André Silva  wrote ..
> Seems Hyperbola endorsement process (to be evaluated by community)
> is stalled for now.

I only volunteered to look over Hyperbola 4 days ago. It seems
premature to say this. Plus, I hope others are willing to help too and
not leaving it to a one-person job.

Re: [GNU-linux-libre] [gnu.org #1291285] RE: FSF endorsement request for Hyperbola GNU/Linux-libre

[Jason Self]

Jason Self <j...@jxself.org> wrote ..
> Yes, exactly.

I'll volunteer to do that.

https://libreplanet.org/wiki/Incoming_distros has been updated to show
Hyperbola in review.

Re: [GNU-linux-libre] [gnu.org #1291285] RE: FSF endorsement request for Hyperbola GNU/Linux-libre

[Jason Self]

> > only in this case he was interjecting immediately, vouching that in
> > this case, the distro is already know to be a valid candidate and
needs
> > no further scrutiny at this level
> 
> So now, Hyperbola needs wait for an individual volunteer on the list who
> wants to take on the role of ensuring that this application continues to
> move forward ("application manager"), right?

Yes, exactly.

[GNU-linux-libre] [gnu.org #1291285] RE: FSF endorsement request for Hyperbola GNU/Linux-libre

[Jason Self via RT]

On Sat Apr 28 13:52:56 2018, emulator...@hyperbola.info wrote:

> I've sent the above request/application to  with
> CC to the mailing lists . Should i send it to
>  again

The GNU Webmasters just do a very basic check to make sure that a distro is a 
feasible candidate. The folks on the mailing list take it from there. So our 
role is done. If you've already contacted the mailing list that's fine.

[GNU-linux-libre] [gnu.org #1291285] RE: FSF endorsement request for Hyperbola GNU/Linux-libre

[Jason Self via RT]

> Hi, i'm André Silva, one of Hyperbola co-founders [0] and I would open a
> new application for an initial review, required to start at the
> beginning and run the new FSF endorsement process protocol for
> Hyperbola.[1]
>
> Hyperbola is a Free Software and Free Culture project aiming to provide
> a fully free as in freedom GNU/Linux operating system called Hyperbola
> GNU/Linux-libre. Hyperbola is a fully free long-term support
> distribution based on Arch snapshots and Debian development, with
> special emphasis on stability, privacy, security and init freedom. See
> our entire presentation from our site [2] and wiki [3] for further
> details.

Hyperbola seems a feasible candidate. Please request an endorsement from the 
dedicated mailing list . They should include a 
description of their new distro, a link to their home page, and any other 
useful info.

They will take over from there.

[GNU-linux-libre] [gnu.org #1291285] RE: FSF endorsement request for Hyperbola GNU/Linux-libre

[Jason Self via RT]

> Hi, i'm André Silva, one of Hyperbola co-founders [0] and I would open a
> new application for an initial review, required to start at the
> beginning and run the new FSF endorsement process protocol for
> Hyperbola.[1]
>
> Hyperbola is a Free Software and Free Culture project aiming to provide
> a fully free as in freedom GNU/Linux operating system called Hyperbola
> GNU/Linux-libre. Hyperbola is a fully free long-term support
> distribution based on Arch snapshots and Debian development, with
> special emphasis on stability, privacy, security and init freedom. See
> our entire presentation from our site [2] and wiki [3] for further
> details.

Hyperbola seems a feasible candidate. Please request an endorsement from the 
dedicated mailing list . They should include a 
description of their new distro, a link to their home page, and any other 
useful info.

They will take over from there.

Re: [GNU-linux-libre] DSFG in perpetuity

[Jason Self]

Isaac David  wrote ..

> right off the bat, Debian's Chromium steers users towards nonfree
> addons, just like their version of Firefox... obviously unacceptable
> to FSF standards.

Yes, I know. This stems from a little bit of hand waving on my part. I
tried to touch on it with my comment that "while the DFSG and the
FSF's own criteria are not identical..." This conversation's been
about the licensing of the browser itself and, solely for that
purpose, Debian's decision is relevant there because the criteria are
the same. The add-on thing also needs addressing too. A repo to point
to consisting of free add-ons would be good. Perhaps something along
the lines of what was done for IceCat plugins to have a list of free
ones on the FSF's Free Software Directory would be a good thing.

Re: [GNU-linux-libre] DSFG in perpetuity

[Jason Self]

Julie Marchant wondered about this.

Past discussions of this are in the list archives and probably on the 
Linux-libre mailing list too. The general summary is that it's one thing 
when someone goes and does something on their own. It's another thing 
when their system tells them. 

And people have shown up on distro mailing lists asking how to install 
the stuff that the kernel was telling them to. There was an example of 
this on the Trisquel forms not too long ago when a microcode request was 
not properly changed in Linux-libre, resulting in the kernel telling the 
person to install the updated microcode. So they showed up asking how to 
do that.

To make a quote from https://www.gnu.org/philosophy/compromise.en.html

"The issue here is not whether people should be 'able' or 'allowed' to 
install nonfree software; a general-purpose system 'enables' and 'allows' 
users to do whatever they wish. The issue is whether we guide users 
towards nonfree software. What they do on their own is their 
responsibility; what we do for them, and what we direct them towards, is 
ours. We must not direct the users towards proprietary software as if it 
were a solution, because proprietary software is the problem."

Re: [GNU-linux-libre] DSFG in perpetuity

[Jason Self]

Henry Jensen  wrote ..
> It depends on how you define "to steer". Just to mention a file name or
> any other non-free program isn't hardly "steering". And it seems that
> this is also the view at the FSF. Otherwise PureOS wouldn't have been
> endorsed in the first place.

We're going in circles. We had that discussion before. I pointed to the 
earlier messages on this mailing list where RMS had said it amounted to 
that in our earlier conversation, and how PureOS was probably an oversight. 
It doesn't seem fair to point to a mistake and want it to continue to 
happen going forward. After all, "we don't reject a distribution over 
mistakes. Our requirement is for the distribution developers to have a firm 
commitment to promptly correct any mistakes that are reported to them."

And here things are again, continuing to push back on making the change.

Re: [GNU-linux-libre] DSFG in perpetuity

[Jason Self]

> keep it updated in an automated way

I'm not sure I'd be onboard with that idea. My understanding is that the 
Parabola folk will blacklist a package as soon as an allegation is made, as 
part of a "blacklist first, research second" type of policy. I don't mean 
to criticize the Parabola folk for this though because such a policy 
probably does not conflict with the FSDG but I think a list of common 
freedom problems that we're asking other distros to take action on should 
only consist of ones that have been researched and confirmed to be valid, 
which is how that list has historically been maintained. So an automated 
rote importing would probably not be a good idea, IMHO.

Re: [GNU-linux-libre] DSFG in perpetuity

[Jason Self]

bill-auger  wrote ..

> chromium is however not one of those items - and i quote:
> 
>   Recommended Fix:
> Remove program/package
> Use GNU IceCat, or equivalent

Yes, although it's presence there is based on a report from 2009 that
upstream has said (on more than one occasion as I recall) has been
addressed. And so, that recommended fix may indeed not be applicable
anymore. There is some evidence that suggests it's outdated (i.e.,
Debian has added Chromium into Main without the -dfsg string in the
package version number which suggests that they didn't need to make
any changes to Chromium to fit with their criteria. While the DFSG and
the FSF's own criteria are not identical this is nevertheless a good
sign.) So I'd not hold distros to removing a package that is possibly
based on outdated information, at least until someone can review it
and make a determination. I've mentioned before that this whole thing
that we're doing isn't supposed to be some blind, automated, rote process.

Re: [GNU-linux-libre] DSFG in perpetuity

[Jason Self]

Robert Call  wrote ..

> That is not part of the FSDG!

Right. And a lot of entries in there have "use version X or later" as
a fix. So even once Chromium is sorted out it'd still be on there but
with a similar recommended fix. So it's not so much a blacklist
anymore these days but more of a list of minimum versions to use.

Re: [GNU-linux-libre] DSFG in perpetuity

[Jason Self]

> For chromium - I am not in favor for it and as stated I request 
> complete removal. The thing is - we must find more productive ways 
> of this because simply removing things means also we remove 
> productivity for many people (yes we have fork of Firefox but that 
> is still not 100% stable and some things work on chromium that don't
> work on Firefox and vice versa).

Sure, I agree. My understanding is that the only reason people have
brought up Chromium is because it's still listed from many years ago
[0]. As I understand it, upstream has said that they've since fixed
the problems that were raised. AFAIK no one has since done a deep dive
into Chromium to confirm and determine if any other issues exist. If
anything there is some evidence to suggest that it may very well just
be a years-old outdated report and is not valid anymore. But until
someone goes and checks...

But I don't think that the FSDG requires distros to remove a program
over allegations of freedom problems. Waiting until they're actually
confirmed also seems to follow with the FSDG, and might even be better
because it avoids removing packages only to re-add them later in cases
where the report turns out to be wrong. Or perhaps merely changing a
program would be sufficient, not a full removal. Either way, waiting
for an in-depth analysis and confirmation of any particular problem
seems a better solution.

> You have our tracker to comment on that and can't expect us to be 
> all the time everywhere, especially not on list that proved itself 
> as a bashing field.

> the easiest and most efficient way to get PureOS attention is to
> use its public bugtracker (and feel free to mail me directly - 
> whenever I have time I will jump on IRC/Matrix/WebRTC/Mumble).

I agree that this mailing list has its challenges but freedom problems
are usually not limited to just one distro. So it is good to have a
place where all of the FSF-endorsed distros can communicate and work
together on such things in a cooperative way. It would be more
difficult to organize communication to such things if the discussion
on problems were spread out among the ticketing systems of all 12
endorsed distros. For this reason I hope that you (or someone working
on PureOS) will remain involved here. Hopefully everyone involved can
keep things civil and on-topic.

[0]
https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines#chromium-browser

Re: [GNU-linux-libre] DSFG in perpetuity

[Jason Self]

I don't understand the desire to boot distros off over how
"maintained" they are. (Like how often releases happen, etc.) Both
Blag and Ututo have been removed before. That can be seen in the log
from the version control system [0]. One of the cited reasons, for
Blag, was "it was last updated in 2011." My recollection for Ututo is
that it was along similar lines. But, as you can see, they were both
re-added (you can check the version control system log for that.)

My recollection of why they were put back is that the notion of if a
distro was actively maintained or not was supposed to be based on how
the maintainers of the distro classified it and not on some
externally-measurable thing like when the last release was, how
current the program versions are, or whatever. This allows, for
example, for distros that are slow-moving because of a lack of people
power to not find themselves kicked off the list because of a
popularity contest. And that's exactly what it would become: "I'm
sorry, but there are more people helping with Distro X and not Distro
Y so Distro Y hasn't been making much progress and hasn't had a
release in a while so you're gone." It's not supposed to be a
popularity contest and, if anything, slower-moving distros that have
less people power probably need more help than the more active &
popular ones do rather than condemnation and a push to remove them.

Distros are expected to fix freedom problems but I don't know that the
FSDG can be read that a distro must provide support to its users
beyond providing for a way to report freedom problems.

Your question of "should the new release be subject to a fresh review
or grandfathered in on good faith" seems very similar to what you
asked in the other thread. And so that brings up all of those same
responses I wrote. There's no reason someone can't go do a review of
any FSF-endorsed distro. I think the reason that they're not done is a
lack of people power. Please feel free to start a review of Ututo or
any other one. I don't have the free time to do that myself right now
but I'm not going to stop anyone else that wants to do.

AFAIK, no one has done the deep-dive into Chromium needed to make a
determination one way or the other. I don't think there's any harm in
distros removing Chromium (or any particular thing) if they want to --
after all, I don't think the FSDG can be read to compel any particular
distro to carry any particular program -- but at the same time if a
distro wants to instead wait until a particular issue has been
properly researched and confirmed as valid so as to avoid
unnecessarily removing packages only to put them back in later, I
don't see how that would not be FSDG compliant. Especially on a large
program like Chromium where much effort is required. The GNU Bucks
program, for example, conditions getting the Buck not merely on
*allegation* of a problem but "after the maintainer has confirmed that
the bug is valid." Why not tie program removal to that same standard?
That still wouldn't prevent distros from going further if they elected
to. Like it doesn't require distros to remove programs over patent
problems or require that non-functional data (I'm thinking wallpapers,
etc.) be under a free culture license but at the same time it wouldn't
prevent a distro from having such a policy either.

> admittedly, i have been kicking pureos a lot lately - mainly because
> i have been hoping to see someone from pureos defend it - it seems 
> quite clear to me that no one from pureos is reading this list - i 
> would propose that one of the FSDG requirements should be for each 
> distro to elect a delegate to follow, if not actively participate in
> the discussions on this list on behalf of the distro

That does seem a good idea.

[0]
http://web.cvs.savannah.gnu.org/viewvc/www/www/distros/free-distros.html?view=log

Re: [GNU-linux-libre] Freeslack website

[Jason Self]

bill-auger  wrote ..

> which leads me back to my last question to this list from yesterday -
> namely: "should a distro be grandfathered in all perpetuity once
> endorsed with no further scrutiny of their on-going practices?"

I don't think that this is intended.

One of the FSF's high priority projects is "Help GNU/Linux
distributions be committed to freedom."

In that entry on the high priority list one of the things that they
mention is to explore the list of free GNU/Linux distributions, and
contribute to them. Surely "contributions" could include checking them
for FSDG compliance, right?

And, their page about volunteering suggests people "volunteer as a
"Freedom Verifier" to check whether a given distribution contains only
free software, so it can be included on the list of free
distributions." Surely that's not just new ones to add right?

Anyway, a lack of reviewing currently-endorsed distros is probably
more due to a lack of people power than anything else. After all, look
at how hard it's been to handle the backlog.

> the proper thing to do in such cases is to report a freedom bug to 
> the distro - but what if they ignore it?[1]

One of the criteria is the FSDG is that the people behind the distro
be committed to correcting mistakes. If they ignore freedom bugs then
that does not seem very committed to me.

There has been precedent to remove distros over freedom problems.
Anyone remember Kongoni? Search for it in
http://web.cvs.savannah.gnu.org/viewvc/www/www/distros/free-distros.html?view=log

But, the FSF can't do anything if they don't know about it right? I
think that this is probably at least one of the reasons for the GNU
Bucks program: To both encourage people to check for stuff and also
give the FSF a chance to monitor things.

And, giving people GNU Bucks as an encouragement to look at things
circles back to my earlier point that I don't think the intention is
to ignore distros once they're added.

https://www.gnu.org/help/gnu-bucks.en.html

Re: [GNU-linux-libre] what of the distros that have already asked for consideration or have been partially evaluated?

[Jason Self]

Jean Louis  wrote ..
> My suggestion is that FSF and volunteers skip the
> common bureaucracy and skip to community review
> manager right now to handle those distributions
> that already applied.

I had already looked at Hyperbola before the new process started.
Finding no problems I told Don about it and kicked the can over to the
FSF for the final decision.

Re: [GNU-linux-libre] what of the distros that have already asked for consideration or have been partially evaluated?

[Jason Self]

Ivan Zaigralin  wrote ..

> Erm, you would want distro maintainers to re-do the paperwork 
> because FSF took a year evaluating a simple query?

No I don't. Notice that the date of Don's message to them is April 6
2017. So, I meant a year after the FSF got back to them.

But I see now that I had missed the part where the people of the
distro got back to them with name options so I mistakenly thought that
the FSF was waiting on the distro to change names. Since I now see
it's the opposite it renders my initial point moot.

Re: [GNU-linux-libre] what of the distros that have already asked for consideration or have been partially evaluated?

[Jason Self]

bill-auger  wrote ..

> BTW - the actual OP for free-slack is here:
>
https://lists.nongnu.org/archive/html/gnu-linux-libre/2016-07/msg00021.html

OK so freeslack can probably be updated that it's on hold pending a
name change. (Based on Donald's 2017-04-06 email quoted at
https://www.freeslack.net/forum/index.php?t=msg=7=15

Re: [GNU-linux-libre] Updated process instructions on LibrePlanet.org

[Jason Self]

bill-auger  wrote ..
> some of these criteria will no doubt require clarification

But hopefully not to the point of trying to document and cover all
possible cases. This is probably not possible. Even if it were if
evaluations were treated as a simple, automated, rote process where
someone worked from some sort of fixed recipe then things would
probably be missed. Meaning that having some vagueness is actually a
good thing rather than trying to spell out all possible things and
then missing things or not hitting the intended point. This leaves
things open to have a discussion on the mailing list, potentially with
different answers in different cases depending on the specifics of the
circumstances.

> FSF does not consider data (raw information) or art to be 
> "practical";

I'm not sure what you mean by "data (raw information)" but even if
something were to fall into that Non-functional Data part of the
definition, it must at least provide permission to copy and
redistribute, both for commercial and non-commercial purposes. So it's
also not acceptable for it to be entirely proprietary either.

> it is not at all clear what this criteria covers

Things that are neither software nor documentation. Think fonts,
PostScript Printer Description files, data sets used by speech
recognition software to learn how to recognize words, hyphenation
patterns in dictionaries, etc. It's probably not possible to make an
exhaustive list of everything, which circles back to the point I made
at the beginning that it's best to evaluate things in light of the
specifics of a given case instead of trying to enumerate things.

Re: [GNU-linux-libre] Discussing the FSF endorsement process going forward

[Jason Self]

Thanks for the work on this Donald!

It would also be good if the existing resources could be updated to reflect 
this. For example, https://www.gnu.org/distros/free-system-distribution-
guidelines.html mentions "If you know about a free distribution that isn't 
listed there, please ask its developers write to  with a 
description of their system and a link to their web page."

Which, from the process outlined, should be the LAST place to go. Under the 
process you've mentioned that email address should be changed to 
webmast...@gnu.org.

Re: [GNU-linux-libre] Discussing the FSF endorsement process going forward

[Jason Self]

Jean Louis, the idea of having volunteers do the reviewing before the FSF 
gets involved helps spare their limited resources. Also, having more eyes 
looking into things is surely better than fewer ones (i.e., if it were only 
FSF staff.)

Re: [GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)

[Jason Self]

Therese Godefroy via RT  wrote ..

> I would be delighted to comment out Blag until it resurrects.

The free distro page is supposed to be maintained by the FSF's
Licensing and Compliance Lab, not the GNU Webmasters. Given that the
GNU Webmasters aren't supposed to add new distros [0] I would take
that to also include not removing them either. Commenting one out
could be seen as the equivalent of removing it since people would not
see it without examining the page source.

Given that the FSF adds the descriptions when adding the distros
making changes to their descriptions could be equally problematic.

I think we should wait for someone from the Licensing and Compliance
Lab, or the FSF at large, to reply before making any changes to that page.

[0] https://www.gnu.org/server/standards/

Re: [GNU-linux-libre] PureOS added to endorsed distro list - what about the kernel?

[Jason Self]

Perhaps a more philosophical question is: *Should* a free program,
especially one used in FSF-endorsed distros, be generating requests
for proprietary programs in the first place? Regardless of how they
might be handled.

Re: [GNU-linux-libre] PureOS added to endorsed distro list - what about the kernel?

[Jason Self]

> i must say though that it did not address what is the actual
> behavior preventing the debian kernel from being acceptable, 

I thought it did.

> why is it not possible to simply change or suppress the error
> message printed to the log or to later or periodically scrub the 
> logs of the naughty bits

Because the kernel is not necessarily responsible for all firmware
loading.

Alexandre mentioned this in:

> 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.

Once the kernel has identified that a firmware is needed for something
then we've got the problem he mentioned:

> When the kernel starts the helper script, it's active telling a
> third-party program "get me a copy of the program foo.bin".

Being that the userland firmware loading program is a separate program
the kernel has no control over what it might do. Absolutely none. It
might log the request, which would be separate from the kernel
logging, and so even if the kernel's logging functionality were
changed in some way it would not have any impact on what this other
program is doing.

But, of course, it could be even worse than logging. It could, for
some examples:

* Display dialog boxes "Hey, this thing is missing. Do you to install
it?" This would be along the lines of how messages are shown about
missing audio/video codecs when you try to play a video. That is
probably even worse that logging because it's right up there, in your
face.

* Automatically download and install it without even asking anything.

* Who knows what else. Being that the userland firmware loading
program is a program, it could do anything that a program could do.
Even things that we aren't currently thinking of.

One might be tempted to say "well, the solution, then, is that -- in
addition to neutering the kernel's logging functionality -- to this to
get rid of the kernel's support for loading firmware from userland,
since it can access the file system directly anyway."

But that is already reducing the kernel's support for loading
firmware, which was part of the original complaint, and doesn't really
address the potential things that could happen: Another problem is
that /lib/firmware could be treated specially by the distro where any
& all of the kernel's attempts to access files there actually succeed
even if the files are not there (Alexandre mentioned the possibility
that the distro mounts /lib/firmware as a separate file system under
FUSE but that would not be the only possible way of doing this), and
then proceed to do exactly the same things that were mentioned as
being problems with the userland firmware helper. In this case another
program is *still* responsible for handling the request and the worse
part is that the kernel would probably not even know this.

Of course, some might be tempted to say that "OK, the solution, then,
is that -- in addition to neutering the kernel's logging functionality
and getting rid of the kernel's support for loading firmware from
userland, it should only try to load firmware when it's not mounted as
a separate file system. Or something." But at point you're starting to
reduce the kernel's ability to load firmware even further, which is
one of the issues that people have raised, and I don't know that there
is a way for the kernel to be able to know the attempt to access the
file system will be handled.

The fundamental problem is with firmware loading being outsourced to
separate programs, regardless of whether the kernel can detect that
this is happening or not. It might not even be able to detect it. And
the kernel has absolutely no control over what that separate program
does after the kernel has made the request via userland or attempted
to access it directly via the file system.

Of course, FSF-endorsed distros would never do any of these things but
Linux-libre is for use by everyone, even those on what Alexandre
called "hostile" distros, and all such cases need to be considered and
handled.

Given all of these possibilities the firmware loading problem may very
well be unsolvable. It's at least very difficult, which is why it
hasn't happened already.

[GNU-linux-libre] PureOS non-free repo

[Jason Self]

Alexandre Oliva  wrote ..
> 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?

It seems similar in some ways and dissimilar in others.

My understanding is that the challenge with Debian's non-free stuff 
is "the repository is hosted on many of the project's main servers,
and people can readily find these nonfree packages by browsing
Debian's online package database and its wiki." (To quote from the
common distros page.)

Purism seems to avoid at least some of this this by having it on a
different domain, and I don't seem to find information at
http://pureos.net about installing the proprietary software.

So in some ways maybe it could be seen as similar to RPM Fusion? On
the other hand, my understanding is that RPM Fusion is operated by a
third party. I'm not sure how Purism being the folks behind this repo
will change anything. We know that Debian's method was deemed not
acceptable and the RPM Fusion method was since it was on a different
site run by different people but Purism's method seems somewhere in
between these two cases. And in the case of RPM Fusion that "separate
domain" wasn't the domain of the primary driving force behind the
distro who also made made news posts about how to set it up.

It would be good to get clarification from the FSF on this on how
this all fits in FSDG-wise.

Another problematic point seems their statement that "all new laptop
shipments include Meltdown and Spectre patches, as they will have the
latest PureOS image (that includes the Meltdown patch) preloaded"

I realize that, in the FSF's announcement of endorsing PureOS, they 
said that it wasn't "a certification of any particular hardware 
shipping with PureOS" although some people might buy Purism's
computers thinking that they're getting an FSF-endorsed distro along 
with it that doesn't have any proprietary junk when -- by Purism's
own announcement -- they're shipping with it included.

Re: [GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)

[Jason Self]

bill-auger  wrote ..
> then the obvious question would be if the OP will see these replies if
> they are not subscribed to this mailing list

They wouldn't. I imagine that the webmasters will handle the replying of 
email that's sent to them? Maybe this was sent as food for thought or 
something?

Re: [GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)

[Jason Self]

bill-auger  wrote ..
> where is this ticket that you reference? gnu.org #1262331 - it is not 
> on the CC list - is that a on public tracker?

It's a ticketing system used to handle certain email addresses like 
webmast...@gnu.org (and more), which seems to be where the person 
originally wrote to.

Re: [GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)

[Jason Self]

Therese Godefroy via RT  wrote ..
> Should a distro that hasn't been maintained for several years be listed 
> in free-distros.html, especially if it is based on a major distro which 
> itself isn't maintained anymore? I am thinking of Blag, based on Fedora
> 10 (2010).

That's already a thing: One of the criteria in the GNU FSDG is that "to 
be listed, a distribution should be actively maintained." When this has 
come up in the past, the determination of being actively maintained was 
said to rest with the distro maintainers and if *they* consider it to be 
maintained or not (as opposed to, say, moving slowly.)

For some examples my understanding is that people are working on BLAG, 
and Dragora has published a new beta version for 3.0. It seems better to 
try to support such efforts instead of dropping them. We need more people 
working on 100% free distros, not less. :)

> Conversely, if unmaintained distros are listed, is there any good 
> reason not to list a new one, which clearly is actively maintained 
> (Uruk)?

Provided that Uruk (or, really, any new one) successfully completes the 
standard review process and is added by FSF staff. (The GNU Webmasters 
should not be adding new ones as per 
https://www.gnu.org/server/standards/#distros)

Re: [GNU-linux-libre] PureOS added to endorsed distro list - what about the kernel?

[Jason Self]

It's probably best to run it by Alexandre Oliva. I imagine that there will 
still be challenges with this; he'd be the best person to explain them. 
It's not an easy problem to solve or it would have been by now.

Re: [GNU-linux-libre] PureOS added to endorsed distro list - what about the kernel?

[Jason Self]

Not necessarily. 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. A partial patch for it already
exists in the linux-libre mailing list archives but it's a hard
problem and hasn't been fully solved yet. Interested people are free
to help. It would probably be best to coordinate with Alexandre Oliva.
My recollection is that there's a conversation about it in either the
linux-libre list archives, or this one. Perhaps even both places at
different times.

Re: [GNU-linux-libre] PureOS added to endorsed distro list - what about the kernel?

[Jason Self]

Henry Jensen  asked:
> So, of course I want to know how PureOS can use this Debian based
> kernel and be endorsed while ConnochaetOS can't?

As Donald implied there is a lot of work involved in review a distros so I 
imagine that this was missed. A primary difference is a willingness to 
correct mistakes, which from Don's email it seems that they have been so 
this seems a good opportunity to raise the issue in the PureOS bug tracker 
along with a CC to report-nonf...@fsf.org. Earn a GNU Buck. :)

Re: [GNU-linux-libre] FSF endorsement request for Hyperbola GNU/Linux-libre

[Jason Self]

Hello, I wanted to check in and report that I've not yet found any problems 
to report. I'm wondering if anyone else is looking into Hyperbola and can 
share if they've identified anything?

Re: [GNU-linux-libre] Using the Linux Liberation Scripts

[Jason Self]

Gpast_panama  wrote ..
> What modifications would typically be required to port it to an 
> alternative kernel tree, if the former?

It depends on what has changed. As an example, if you were to look at
what Trisquel does, they have modified the deblob scripts to catch
additional things that Canonical has added to Ubuntu's kernels that
don't come in the one from kernel.org.

> neither of us know for certain if this is sufficient to produce a 
> blob-free kernel.

deblob-check may be useful here, but I think it would ultimately need
manual investigation.

Re: [GNU-linux-libre] [Freedom issue, originally posted on Parabola bug tracker] Trademarked logos

[Jason Self]

8jxvrx+1bfu4ijuj3e68, trademarks aren't necessarily a problem. Yes,
there is potential (add emphasis on that word there) for problems.
I'll include by reference how Mozilla's trademark policy goes too far
by including distribution restrictions going against freedom #2, but
that is a specific problem with a specific trademark policy and not
something inherently a problem with trademarks themselves. It is
necessary to evaluate each situation, and there doesn't seem to be
anything special going on with the cases you've pointed out.

Re: [GNU-linux-libre] palemoon browser

[Jason Self]

Oh, and we also have similar efforts with things like GNU IceCat and
Trisquel's Abrowser. It probably makes more sense to work together and
not fragment efforts by starting yet another modified version of a
Firefox-based browser.

Re: [GNU-linux-libre] palemoon browser

[Jason Self]

It seems to have redistribution problems similar to Firefox, along 
with the misunderstanding that free software isn't about cost. It can
be modified, and then a re-branded version could be distributed free
of those problems, but this is also true of Firefox so I'm not sure
what benefit there is to using Palemoon as a base over Firefox.

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Jason Self]

Henry Jensen  wrote ..
> This was an error by me, I did not update the symlink to the source,
> which is located at 
> https://connochaetos.org/slack-n-free/slack-n-free-14.2/d/. This is
> fixed now.

Thank you, although even with this change I still cannot account for
all of the source code for all of the binary packages available.
coreutils for example and many others.

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Jason Self]

Henry Jensen  wrote ..
 
> Yes, thank you for linking to the messages. RMS mentions a change 
> "to obfuscate the names of the firmware files" instead of failing. 

That was not the primary reason for linking to that message. Pay
attention to his very first statement:

> It sounds like the new Debian version of Linux will recommend
> specific nonfree firmware programs, which is undesirable.

The thing he's referring to in that statement is the logging. Feel
free to write him if you don't believe it.

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Jason Self]

The FSF can, of course, set whatever criteria/conditions they want in
order to put their name behind something.

While I don't pretend to speak for the FSF the things I point out are
things that, based on past experience, are problematic points to
address if the end goal is indeed to get the FSF to put their name
behind ConnochaetOS. (As one example, the consensus on this mailing
list for years has been that the notion that the Linux kernel logging
firmware names when they're missing is not desirable. I've even
provided references to that effect. The list archives may very well
provide other such references.)

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Jason Self]

Ah, I managed to find the ones I was thinking of:

http://lists.nongnu.org/archive/html/gnu-linux-libre/2010-12/msg00033.html

http://lists.nongnu.org/archive/html/gnu-linux-libre/2010-12/msg00032.html

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Jason Self]

Henry Jensen  wrote ..

> The link to the freeslack project shouldn't be a problem, since
> the page at https://www.gnu.org/distros/common-distros.html links
> to the very same project.

There is no reference to FreeSlack on that page, only Slackware.

But even if we consider Slackware, what is being said also be
considered: That page is discussing why Slackware is not acceptable
for adding as an FSF-endorsed distro.

In comparison, the text I'm referring to is an out-and-out referral to
go *use* it if someone wants a 64-bit version: "If you are looking for
a libre Slackware x86_64 variant you are welcome to use the x86_64
slack-n-free repo and have a look at the FreeSlack project."

In one case, the statement (on gnu.org) is about why Slackware is not
acceptable. The other is a statement to go use it if they want 64-bit.
These are not the same. An FSF-endorsed distro shouldn't steer people
to using ones that are not.

> I have a diferent view. The statement from the FSF at [1] can be
> interpreted in the way, that the de-blobbed Debian Linux kernel is
> regarded as entirely free software.

That deblobbed kernel is indeed free software; this discussion is
solely about the "inducement" part.

> Our installer doesn't do such things.

I'm not discussing the installer.

> Yes, there may be occurrences of  names of proprietary firmware 
> blobs in log files. But they are not recommendations, simply names.
> We do not steer people to this proprietary files, since we are not 
> telling people how to get them.

It's not necessary to tell people how to get them in order for it to
count as an inducement. In this case people's log files get spammed
with "file not found" error messages. If memory serves this matter has
also come up with RMS before too, and he's on board with the name
scrubbing. All other endorsed distros use Linux-libre. Why should
ConnochaetOS receive a special exemption?

I've installed ConnochaetOS in a virtual machine and have also made
these observations:

- I like that the browser has been modified to send people to the FSF
Directory for add-ons. That avoids the matter of steering people to
non-free add-ons.

- I like that the browser sends people to the non-JavaScript version
of DuckDuckGo, eliminating the JavaScript Trap.

- The installer advertises itself as "ConnochaetOS Linux"
Based on the entry for "Linux system" in the link to Words To Avoid in
the "Please Avoid Repeating Propaganda and Confusion" part of the GNU
FSDG this should be changed to GNU/Linux or the Linux reference
eliminated.

- Some of the documentation contains no copyright or licensing
information. An example:
https://connochaetos.org/slack-n-free/salix/i486/slackware-14.2/Slackware-HOWTO
but this also applies to the speak install and speakup docs files.

According to the FSDG, "all the documentation in a free system
distribution must be released under an appropriate free license." It's
possible that this is already supposed to be free, but just not stated.

The Slackware Howto is also talking of "Slackware Linux" and "the
Linux operating system", which continues the notion of the "Linux
system" mentioned earlier. Further, I'm not sure that sending people
to the Slackware website for further information is the best approach
that an FSF-endorsed distro should take (The Slackware documentation
wiki has a lot of information...)

These may be fixable, depending on the license and if modifications
are allowed.

I've also not been able to locate the source code for the kernel.
https://connochaetos.org/slack-n-free/source/src/linux/ doesn't have
it even though other directories in the parent appear to have source code.

[GNU-linux-libre] Reviewing ConnochaetOS

[Jason Self]

J.B. Nicholson wrote:

> I see on https://connochaetos.org/wiki/ that ConnochaetOS "is
> available for x86 (32 bit) only" and directs users looking for an
> x86_64 libre Slackware GNU/Linux distro elsewhere.

That is probably a valid point. I imagine that FSF-endorsed distros  
should probably not steer people to others that are not?

In addition, I think that the documentation at [0] should probably be
updated to steer people to the Linux-libre deblob scripts (or their
already deblobbed tarballs?) The fundamental problem is that the
method used by the Debian Project leaves the request_firmware calls in
place, resulting in people's system logs being spammed about how the
proprietary software is missing from their system. Linux-libre's
deblob scripts handle this by removing code that induces users to
install non-Free Software.

[0] https://connochaetos.org/wiki/docs/deblobbing

Re: [GNU-linux-libre] ?= Usage of NINTENDO=?UTF-8?Q?®?=,=?UTF-8?Q? MAME® and other trademarks

[Jason Self]

Jean Louis  said:

> Considering all of the above, I propose that NINTENDO® trademark is
> removed from ALL free software distribution as such.

You started a similar thread about this on the Guix mailing list too.

For example I think where, in Guix, the package for Mupen64Plus says that
it "is a cross-platform plugin-based Nintendo 64 (N64) emulator" would be
an example of nominative use.

It would be much more difficult to explain what a program was without being
able to refer to the name. ("This program emulates a certain device
manufactured by a certain company...")

Just because something is a trademark doesn't mean we can never talk of it
or make reference to it.

Re: [GNU-linux-libre] MAME

[Jason Self]

J.B. Nicholson  wrote ..
> Julian Marchant wrote:
> > As far as I know, all Flash objects are non-libre.
> 
> How do you figure this?

I think they are referring to the ActionScript code [0] to construct the 
player (or whatever else.) It is usually not free which means that you're 
still running non-free software in the end, even if you're using a free 
software player like Gnash to interpret it and just "watching the video." 
It seems to be a similar problem to the JavaScript Trap [1].

[0] https://en.wikipedia.org/wiki/ActionScript
[1] https://gnu.org/philosophy/javascript-trap.html

Re: [GNU-linux-libre] MAME

[Jason Self]

Jean Louis  wrote ..

> I have made mistake, I wanted to say:
> 
> there is NOT EVEN ONE SINGLE PIECE OF FREE ROM that was made for 
> MAME that is on their website. Not outside of MAME website.

But it shows that a given program can have multiple uses.

Chris Webber has a well-written reply to a similar thread that you
started with Guix:
http://lists.gnu.org/archive/html/guix-devel/2016-03/msg01267.html

Re: [GNU-linux-libre] RLSD GNU/Linux-libre 2.x

[Jason Self]

fr33domlover fr33domlo...@riseup.net asked:

 What if a distro is not self-hosting, but can be built from another
 fully free distro which is on the FSF's list of free distros?

An exception to self-hosting is addressed in the GNU FSDG already.
This was added for clarity due to LibreWRT, which targets embedded
devices that don't have the resources to compile their own software.
x86/x86_64 machines, in comparison, do.

An exception to this requirement and to the self-hosting requirement
above is for small system distributions, which are distros designed
for devices with limited resources, like a wireless router for
example. Free small system distributions do not need to be
self-hosting or complete, because it is impractical to do development
on such a system, but it must be developable and buildable on top of a
free complete system distribution from our list of distributions,
perhaps with the aid of free tools distributed alongside the small
system distribution itself.

 I'd ask RMS. Is he subscribed to this list (or should I send to him
 directly)?

It is better to go through FSF staff via this list and leave it to
them to interact with RMS as needed.

Re: [GNU-linux-libre] RLSD GNU/Linux-libre 2.x

[Jason Self]

fr33domlover asked:
 a tiny distro for old hardware

x86_64 machines, which are one of the stated targets, are not old.
Imagine a 12-core Intel Xeon.

 I'd just like to understand why something with minimal benefit

It's not clear to me why you're reluctant to provide easy access to a
compiler  complete toolchain to build from scratch. In fact, in
reviewing the website I am not able to find any information about how
to actually build RLSD regardless of the method. libreCMC in
comparison does provide information and instructions on their website:
https://librecmc.org/librecmc/wiki?name=Build+HOWTO

Julian Marchant onp...@riseup.net wrote ..

 You're talking about how long it takes to compile. The way I 
 interpret the exception for distros like LibreWRT and LibreCMC is 
 that it's for systems going on devices that *can't* do self-hosting
 because they don't have enough storage space. That's a very 
 different situation.

Exactly. In the case of libreCMC, there are devices targeted which
contain only 4MB of permanent storage. This is too small the hold the
source code of the software that runs on there. Go look at the
tarballs of Linux-libre and you'll see that the source code of the
kernel alone is far more than 4MB. They can't hold their own source
code but even if they somehow could there's the matter of the CPU:
They're not powerful enough to do so. It would take forever, or at
least long enough as to simulate forever, but in truth the machines
have such limited RAM that the machine would run out of RAM and not be
able to successfully compile its own software anyway. For this reason
it's common to cross-compile on a larger and more powerful host system.

This is not the case on x86: Permanent storage can usually be
increased easily by adding a new or additional HDD or SSD. RAM can be
upgraded to provide a sufficient quantity, etc.

Also, I'm told that libreCMC is also self-hosting on x86: You can
build the toolchain and successfully compile a functioning system
using only the tools that the libreCMC folks provide.

Re: [GNU-linux-libre] RLSD GNU/Linux-libre 2.x

[Jason Self]

Ineiev wrote:
 I'm not sure the exception should apply to it.

Yeah, the idea was that it was for embedded distros that target
machines with insufficient storage, RAM  CPU power to compile their
own software themselves. The exception doesn't make much sense outside
of the embedded world.

Re: [GNU-linux-libre] LibertyBSD - OpenBSD minus the blobs

[Jason Self]

Michał Masłowski asked:
 Do the GNU/Linux-libre distributions need separate design to be useful
 on servers?

Riley Baird replied:

 Yes. Most GNU/Linux-libre distributions have a GUI and various other
 unnecessary, potentially vulnerable programs. These are useful for
 desktop users, but not for server users.

That's just what packages are installed by default, not an argument to
why the underlying system itself needs to be designed differently.
Seems more a perception thing. If your point is over what packages are
installed by default then Trisquel, gNewSense, and Parabola all have
minimal ISO images which are enough to boot your computer, bring up
networking, and then install exactly (and only) what you say to,
thereby eliminating all of that stuff you mentioned. (And really that
copy of Postfix I install on my server is the same as that which I'd
get from most any other system.)

Re: [GNU-linux-libre] GNU/Linux-libre from source code for Loongson 3A (1.3)

[Jason Self]

Christophe Jarry said:
 In an attempt to build a simple GNU/Linux-libre distribution 
 targetted at Loongson 3A machines, I wrote a document that 
 describes how to build a basic GNU/Linux-libre operating system. 

You might be interested in collaborating with [0] who also target
Loongson CPUs (and x86 too.) Consolidating effort is probably a good
idea. :)

[0] https://gnu.org/software/guix/


signature.asc
Description: PGP signature

Re: [GNU-linux-libre] choosealicense.com fork with better wording, perhaps ?

[Jason Self]

Riley Baird said:
 is a restriction

The only way I can think of it to consider is a restriction is if
Tivoization were considered a legitimate activity to begin with.

Framing copyleft as a restriction is not a good idea. This goes back
to what John said.

As an example, it's not as if TiVo Inc. can't use GPLv3 stuff or
that they the license somehow restricts them from doing so. Rather,
they can and should use it (everyone should.) They just need to pass
on those same freedoms to others.

It's probably better to position/frame the GPL and copyleft as
protecting software freedom rather than restricting it.

Re: [GNU-linux-libre] choosealicense.com fork with better wording, perhaps ?

[Jason Self]

Riley Baird said:
 For someone who hasn't decided whether they care about free software
 or open source (or both), it would help them to make their mind up
 without feeling that they are reading propaganda.

Framing copyleft as a restriction is often propaganda used by the
anti-copyleft crowd though so the site already contains some of that.

Re: [GNU-linux-libre] choosealicense.com fork with better wording, perhaps ?

[Jason Self]

Riley Baird asked:
 What part of their description is untrue?

One example: Presenting the anti-tivoization provisions in the GPLv3
as a restriction.

If you listen to Tom Preston-Werner's (GitHub co-founder) anti-GPL
keynote from OSCON his position on the GPL will become clear and
shouldn't be surprising that the website reflects this.

Re: [GNU-linux-libre] Reviewing the GNU system for FSDG compliance

[Jason Self]

Ludovic Courtès said:
 There are still important limitations [1] that make it unsuitable as a
 production system or for newcomers, but OK (and even pretty cool, I
 dare say ;-)) as a hacker’s system.

 So I wonder if now would be a good time to start reviewing it for FSDG
 compliance.

 WDYT?

The upcoming 0.7 seems to address the part about being bootable and
working on real hardware so it seems to make sense to move forward and
take a look at the rest. The limitations mentioned in that file
shouldn't be an issue IMO because, AFAIK, the GNU FSDG doesn't say
that a given system must have a GUI or that it must offer disk
encryption, etc. and being for advanced users seems fine.


signature.asc
Description: PGP signature

Re: [GNU-linux-libre] CAcert root certificate non-free?

[Jason Self]

Luke Shumaker:
 I'm with Parabola GNU/Linux-libre, and I have doubt that we can
 continue packaging the CAcert root certificate.
 
 It was pointed out that in 2010 Fedora Legal found[0] CAcert's Root
 Distribution License[1] to be non-free; with a usage restriction.

How does this compare with the licenses for other certificates that
are already included? In a quick search for example the licenses from
Entrust seem to be less liberal than the CAcert one and yet distros
seem to include them without question.


signature.asc
Description: PGP signature

Re: [GNU-linux-libre] withdraw request for endorsement for GdNewHat.

[Jason Self]

Shintaro Shinozaki said:
 I would like to withdraw request for endorsement for GdNewHat
 because I decided  to give help to restart BLAG distro and
 close GdNewHat project at the end of current release in order
 to shift development from binary base distro to source one.
 
 I would like to thank you for your time and cooperation.

Okay, I will stop my review.

Re: [GNU-linux-libre] GdNewHat info and request for endorsement.

[Jason Self]

Is anyone interested in helping to further review GdNewHat? Please let
me know and I can arrange for you to have access to my FOSSology instance.

Re: [GNU-linux-libre] GdNewHat info and request for endorsement.

[Jason Self]

Shintaro Shinozaki said:
 Hello,
 
 My name is Shintaro Shinozaki who is lead developer of GdNewHat 
 project. We are currently maintaining GNU/Linux-libre system 
 distribution and RPM repositories without non-free packages. So, 
 we would like to join gnu-linux-libre community and request 
 endorsement. If you have a time, please give us some advice. Thank 
 you.

In using GdNewHat briefly I saw that the package manager came
preconfigured to use Fedora's repositories. While these were not
enabled by default I wonder how that fits in with the FSDG where nor
should the distribution refer to third-party repositories that are not
committed to only including free software and if it's necessary to
even have those repositories present at all?

I also noticed that it seems not all source code is being distributed
(in reviewing the GdNewHat repositories I found 20-some source
packages.) Why isn't all source code available from GdNewHat?

Re: [GNU-linux-libre] GdNewHat info and request for endorsement.

[Jason Self]

Riley Baird (Orthogonal) asked:

 What do we need to evaluate/discuss before it is accepted?

I go use it, look it over, see what packages they have and if there is
any low-hanging fruit like stuff mentioned in [0]. Grabbing the source
code for packages and auditing them is also needed - looking for
things that might be a problem, like non-free things that may be
accidentally included or other stuff that goes against the FSF's
guidelines [1]. It's usually quite a bit of work to comb through
everything so I use software tools like FOSSology [2] to help with it.
Automated license analysis is not perfect but it at least helps to
figure out that which is very clearly free software and that which
needs further investigation.

[0]
http://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines
[1] https://gnu.org/distros/free-system-distribution-guidelines.html
[2] http://fossology.org

Re: [GNU-linux-libre] GdNewHat info and request for endorsement.

[Jason Self]

Shintaro Shinozaki said:
 I already sent email to webmast...@gnu.org. Webmaster gave me
 instructions to send email to gnu-linux-libre ML.

Yes - My understanding is that the role of the GNU Webmasters is
limited to briefly checking that the distro is a feasible
candidate: they should have a clear policy of only including free
software, and it should be reasonably apparent how to get the
sources and what packages are included. If there are no glaring
problems they're then referred to the gnu-linux-libre mailing list
for further evaluation and discussion.

Re: [GNU-linux-libre] Recognizing the GNU system as a free distro

[Jason Self]

Ludovic Courtès said:
 I’ve come up with a plan that will allow Guix to behave similarly [0].

Good good. :)

I do have another question about how to apply the FSDG guidelines to Guix.

Specifically in the Complete Distros section it mentions that if
using it requires further work or presupposes installing other
software as well — then it doesn't belong in this list, even if it is
free software.

Guix is currently not bootable - you install it along with another
distribution that is. Does this mean that Guix doesn't meet criteria
until it is bootable? Or is being installable alongside a 100% free
distro acceptable? Or...? I guess I'm not sure what the intention
behind this part is. With Ludovic's change I think Guix would
otherwise meet all of the criteria.

Re: [GNU-linux-libre] Recognizing the GNU system as a free distro

[Jason Self]

Ludovic Courtès said:
 Yes, I understand this, but my question was more about how this occurs
 technically.

 My understanding is that Debian-based distros provide the unmodified
 upstream source, with a debian/patches tree containing patches they
 apply.  Do I get it right?

Ah, I see. In the case of, say, the Linux kernel it's not really
possible to provide the unmodified source code because that would mean
Trisquel would be distributing that non-free software. So, their
orig.tar.gz isn't the unmodified upstream source but rather the
deblobbed version.

Re: [GNU-linux-libre] Recognizing the GNU system as a free distro

[Jason Self]

Ludovic Courtès said:
 I'm reluctant because of the technical and administrative burden it
 entails

I suppose another option is to leave out problematic packages
entirely. Otherwise, welcome to the world of being an FSF-endorsed
distro. :)

 Besides, our package meta-data would probably still refer to the
 real home page of the package, from which it's trivial to get the
 unmodified tarball.

I think the question isn't whether or not the users of a distro can
leave their distro's infrastructure and install non-free or other
programs on their own. Rather, it seems more a question of if the
programs that the users finds through the distro are themselves
FSDG-compliant [0]. I agree with what Sam said regarding Parabola back
in 2011 [1] that:

 Consider that the software is really the source code and that the
 binaries are just the usable machine-readable form of it. Both
 source code and binaries should be free (the latter follows from the
 former if all is well).

...

 providing non-free software + user executable freedom patch is not
 what a free distro should be doing, IMO.

Ludovic Courtès said:

 we'd need an out-of-band mechanism to maintain patches/scripts, said
 patches/scripts would have to be reviewed separately, contributors
 would need to have the necessary credentials to upload patched
 tarballs, etc.

I think some of this can be automated and minimized. Trisquel, for
example, uses what they call Helpers [2]. As new versions are pulled
in from Ubuntu the corresponding package helper is run, if one exists
for that package. That helper is responsible for making any changes
that are needed to the source code and repackaging it before it is
moved into the Trisquel repositories to be compiled. In this way the
users of the distro always have access to FSDG-compliant source code
packages.

Is there some automated method in which Guix checks for new versions
from upstream? Perhaps this could be extended such that, for certain
programs, they're run through some script to clean them up in a
similiar automated fashion to Trisquel? The gnupload script [3] could
then be used to upload them to, say, the GNU FTP server? (Perhaps in
the non-gnu area?) In this way the process that checks for new
versions handles the actual work. People contributing to Guix only
need access to the version control system to maintain the helper for
that program.

[0] http://www.gnu.org/distros/free-system-distribution-guidelines.html
[1]
http://lists.nongnu.org/archive/html/gnu-linux-libre/2011-01/msg00045.html
[2] https://trisquel.info/en/wiki/package-helpers\
[3] http://git.savannah.gnu.org/cgit/gnulib.git/tree/build-aux/gnupload

Re: [GNU-linux-libre] Recognizing the GNU system as a free distro

[Jason Self]

Sam Geeraerts said:
 Note that some packages may contain non-free files (e.g. [a]),
 regardless of the license of the whole. There are also freedom issues
 that are unrelated to the license of the code, e.g. encouraging the use
 of non-free software [b]. I see that your packaging guidelines mention
 these issues, but I thought I'd mention it anyway.

My understanding is that package source code is obtained directly from
the developers, whether that's ftp.gnu.org or Sourceforge or whatever.
In the cases Sam mentions it seems that there will need to be a way to
host modified versions of such problematic programs somewhere with the
necessary changes already made. In this way people that use the Guix
package manager to compile  install from source don't end up
downloading the problematic source code. hydra.gnu.org could even use
that location to build those program from if needed.

Re: [GNU-linux-libre] Gnuplot

[Jason Self]

Alexandru Cojocaru xo...@gmx.com wrote ..
 Is Gnuplot really Free Software?

 Permission to modify the software is granted, but not the right to
 distribute the complete modified source code.  Modifications are to
 be distributed as patches to the released version. 

I seem to recall that other programs have had similar requirements and
have been considered free. It's really just a packaging issue: Your
modifications live in a separate file and are applied at build time.
This seems to mesh well with this section from the Free Software
Definition:

...rules about how to package a modified version are acceptable, if
they don't substantively limit your freedom to release modified
versions, or your freedom to make and use modified versions privately.
Thus, it is acceptable for the license to require that you change the
name of the modified version, remove a logo, or identify your
modifications as yours. As long as these requirements are not so
burdensome that they effectively hamper you from releasing your
changes, they are acceptable; you're already making other changes to
the program, so you won't have trouble making a few more.

[GNU-linux-libre] Working with FSF on Debian Free-ness assessment

[Jason Self]

In case anyone hadn't seen this.

https://lists.debian.org/debian-project/2012/07/msg00016.html


signature.asc
Description: PGP signature

Re: [GNU-linux-libre] LibreWRT free distro?

[Jason Self]

Ineiev asked:
 Is it self-hosting?

I'm not sure that the self-hosting requirement makes sense in this case
because emedded devices typically do not have the resources to compile
their own software. It's usually done on a more capable system and then
copied to the device afterward.

In the case of LibreWRT, everything can be built using only free software.
I start with Trisquel and a copy of the LibreWRT tarball.

[GNU-linux-libre] Linux GPLv3

[Jason Self]

There was a recent discussion about the Linux kernel and GPLv3 on a 
mailing list and it made me wonder how much stuff is licensed under v2 only 
terms.

So I fed Linux-libre 3.1.4 to FOSSology so I can look for things that
would get in the way of moving to v3. Not that Linus ever would, but
perhaps Linux-libre could...

Of the 36,944 that make up Linux-libre 3.1.4, 8,910 are GPLv2 only. That's
about 24% being v2 only. I expected more.

The rest are v2 or later, don't specify a version (and can therefore any
use version of the GPL), or are under a permissive license that would also
be compatible with v3. Is there any benefit to me doing continued research 
like identifying who the copyright holders of those files are or anything 
else?


signature.asc
Description: Digital signature

Re: [GNU-linux-libre] virtual private servers that can run a free distribution

[Jason Self]

Sam Geeraerts wrote ..
 Is corehost.us not included because of false modisty or does it really 
 not qualify?

I was never clear why corehost.us didn't offer things like Trisquel, etc. as 
part of their virtual and dedicated server options.


signature.asc
Description: PGP signature

Re: [GNU-linux-libre] Thunderbird 6.0+ doesn't allow extension URL modification

[Jason Self]

Nicolás Reynolds fa...@kiwwwi.com.ar wrote ..
 Hi, the update from thunderbird 3 to 7 is late at Parabola because we can't
 find a way to modify the extension URL[1] to not show the default recommended
 addons page.

 If you know how to do it please do, otherwise you can vote up this question[0]
 so thunderbird devs can see it.

It looks like there might be some interesting things found
in  /mail/app/profile/all-thunderbird.js, including things like
an extensions.GetAddons.get.url, etc. Haven't actually tried it, just running
grep and looking for stuff.


signature.asc
Description: PGP signature

Re: [GNU-linux-libre] Thunderbird 6.0+ doesn't allow extension URL modification

[Jason Self]

Quiliro Ordóñez wrote ..

 I cannot find that folder or the file you mention.

I was working from the Thunderbird 7.0.1 source code:

ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/7.0.1/source/thunderbird-7.0.1.source.tar.bz2


signature.asc
Description: PGP signature

[GNU-linux-libre] unzip

[Jason Self]

While examining the unzip source code I found this clause in the file match.c:

 Permission is granted to any individual or institution to use, copy,
 or redistribute this software so long as all of the original files are
 included unmodified, that it is not sold for profit, and that this copy-
 right notice is retained.

This could be read as not permitting modification, since it only talks about
using, copying and redistributing. Also, a free program must be available for
commercial use, commercial development, and commercial distribution.

I'm raising this because it appears that several GNU+Linux distros have copies
of unzip. Is it an oversight? It doesn't seem to hive with the Info-ZIP license
at http://www.info-zip.org/license.html.

I'm having difficulty contacting the Info-ZIP people: Their forums require
approval from an administrator to get an account, their mailing lists seem to be
gone, their web-based contact form responds with Go Away Spammer.  :/


signature.asc
Description: PGP signature

Re: [GNU-linux-libre] TeXLive auditing

[Jason Self]

From http://www.gnu.org/philosophy/free-sw.html

...it is acceptable for the license to require that you change the name of the 
modified version, remove a logo, or identify your modifications as yours. As 
long as these requirements are not so burdensome that they effectively hamper 
you from releasing your changes, they are acceptable; you're already making 
other changes to the program, so you won't have trouble making a few more.


signature.asc
Description: PGP signature

Re: [GNU-linux-libre] Trademark licenses, example in Firefox

[Jason Self]

What? Is is absolutely source code.

In a way, they are forks from upstream. They address the problematic areas of 
the upstream software that concern the free software community that upstream 
doesn't want to address. GNU Icecat, for example, can be used without ever 
thinking about Mozilla's trademark policy since it's completely rebranded, and 
Linux-libre addresses all of the problematic areas of the upstream Linux kernel.

There's no need for a code split, since that's what you seem to be talking 
about. While I would love to see the upstream Linux kernel adopt the changes 
that are made in Linux-libre, I doubt that will happen any time soon. In the 
meantime, we have a kernel that is entirely freedom-respecting. What would we 
use without Linux-libre? The HURD is not really ready for prime time, and 
developing an entirely new kernel from scratch would take alot of time and 
energy and gain us... what, exactly? We'd gain an entirely free kernel *all 
over again*? We already have one. So I see nothing bad about maintaining what 
is essentially a fork of the Linux kernel, and incorporating changes from new 
releases of the Linux kernel when they occur, and plenty of good stuff reasons 
to do so.


signature.asc
Description: PGP signature

Re: [GNU-linux-libre] Screenshots Of Free Distros In Action

[Jason Self]

Nicolás Reynolds wrote:

 I can contribute with some of the loongson port, and I guess the 
default tty and several DEs can be there too :)

Great -- the more the merrier, in my opinion :)

-- 
Jason Self
GNU Chief Webmaster
GPG Key: 47486962


signature.asc
Description: This is a digitally signed message part

Re: [GNU-linux-libre] Screenshots Of Free Distros In Action

[Jason Self]

Karl Goetz wrote:

 Assuming there wasn't a new distro to 'feature' every month, would you
 simply swap in an old/repeat one?

Yes, and the more that I have the longer it would be until I had to
cycle back to an old one. :) 

 I'm happy to try and do up some screenshots for gNS if desired.

Yes, please. :)

-- 
Jason Self
GNU Chief Webmaster
GPG Key: 47486962


signature.asc
Description: This is a digitally signed message part

Re: [GNU-linux-libre] Parabola GNU/Linux

[Jason Self]

Sam Geeraerts wrote:
 In gNewSense we rebrand at least the highly visible things in the
 standard desktop install, e.g. GRUB, usplash, GDM, Gnome, package
 manager. I think it's enough to fulfill FSDG.

Karl Berry wrote:
 I agree.

 Parabola people, can you follow that lead, please?

Nicolás Reynolds wrote:
 we're working on that :), grubs are ready, for instance.

New rebranded ISO images showed up a few months ago. I help to participate in
the freedom verification process by sending their entire repo to my FOSSology
instance for analysis. A few non-free things were found, and were promptly
removed by the Parabola folks.

I think that Parabola is ready.


signature.asc
Description: PGP signature

Re: [GNU-linux-libre] chromium not free?

[Jason Self]

Quiliro Ordóñez quil...@congresolibre.org wrote ..
 Nevertheless, it says all rights reserved. Doesn't that mean that all
 other right not specifically mentioned are reserved?

Yes, but it's not due to that satement. With today's copyright law, All Rights
Reserved is the default state of things -- automatically, just by virtue of
having been written -- and that phrase no longer needs to be included to make
it so.

http://en.wikipedia.org/wiki/All_rights_reserved


signature.asc
Description: PGP signature

Re: [GNU-linux-libre] chromium not free?

[Jason Self]

Quiliro Ordóñez quil...@congresolibre.org wrote ..

 Does this mean you cannot have the freedom to modify this information
 file?

It doesn't specifically say that, no... only that you may recompile and
redistribute. Nothing more.


signature.asc
Description: PGP signature

Re: [GNU-linux-libre] LibreWRT : A 100% FOSS GNU/Linux-libre Distro

[Jason Self]

Jaromil wrote:
 Jason: is openfwwf already in LibreWRT? it seems that openfwwf
 supports the Asus WL500g series.

Not currently, but it could be added. We're getting ready to do a new
release on March 19th at the upcoming LibrePlanet 2011 [1]. It's too late
for that, I think, but perhaps for our next release after that. Stay
tuned...

[1] http://libreplanet.org/wiki/LibrePlanet2011