[GNU-linux-libre] PSA on weak cryptography

[Rubén Rodríguez]

Just a reminder for all distro maintainers and sysadmins to pay
attention to the cryptographic settings of programs included in free
distros, or being used in their respective project's infrastructure.

In particular, I think we should all analyze the use of weak
Diffie-Hellman Groups ("precomputed primes") and other DH related
vulnerabilities: https://weakdh.org/

For distros derived from others, make sure you are inheriting any
hardening that may come from upstream, and otherwise check the settings
for all the most common, security-sensitive packages. Feel free to share
in this thread what improvements you have implemented!

Quick and incomplete list of tools and documentation:

https://www.ssllabs.com/ssltest/
https://freakattack.com/
https://poodle.io/
http://heartbleed.com/
...
Please add others that you may know.

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

[Rubén Rodríguez]

> Input on what FSDG distributions should do would be much appreciated.

I asked RMS and this is his response:

"If that (cacert) license were on a program, it would be nonfree.
But that is irrelevant to certificates.  So the license
is not an obstacle to our including the Cacert certificate."

This applies to any other certificate and its license.

Still, I will not be adding CaCert's root CA to IceCat or Trisquel as
they don't seem to be very trustworthy:
https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1258286
https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c158

Re: [GNU-linux-libre] Signing FSF statement against Restricted Boot

[Rubén Rodríguez]

> Hi folks,
> 
> Debian has just signed our statement against Restricted Boot (see
> ).
> 
> Of course it would be great to also have signatures from distributions
> on our recommended list. :)

Please add Trisquel.
Our logo is here: https://trisquel.info/en/wiki/logo

Re: [GNU-linux-libre] Linux & GPLv3

[Rubén Rodríguez]

> 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

Unless you find a way to replace those ~9000 core linux files with new,
GPLv3 code, there is not much use for the research... :/

To my knowledge, there is no way Linux's license can be changed, even
if Linus wanted to. Too many authors.

Re: [GNU-linux-libre] Request for Endorsement for ConnochaetOS

[Rubén Rodríguez]

> BTW: I recently had a discussion on this one with some people from the
> Free Software Foundation Europe, the FSF's sister organization in
> Europe. Many people at the FSFE have a different point of view on
> this.
> 
> They prefer the term "free software" as well, but they believe that
> "open source" and "free software" is the same and they don't think
> that both "free software" and "open source" community have different
> goals. So "free software" and "open source" are considered as the same
> community at the FSFE. You see, the view on this topic is not
> homogeneous in the Free Software Community itself.

Even if you found individuals involved with the FSFE who believe that
Free Software and Open Source are the same movements, that is not the
FSFE position: http://fsfe.org/documents/whyfs.html

You may also find people involved with the FSF who think like that,
anyone can be wrong. But finding many people being wrong never was a
good argument anyway. ;)

Re: [GNU-linux-libre] Not free complety software, why other support nonfree os and related? umm extrano e ilogico..

[Rubén Rodríguez]

> >> why that software compile and run most of them on windows and mac?
> >
> > Because it is portable. Nothing related to the license.
> >
> interesting point, so this software promotes non-free operating
> systems licences?

I don't see how.

> why are you speaking about licences?

I'm not, I said the license is not related in that matter. Why are you?
 
> >> LibreOffice supports non-free formats!!!, and supports saving on
> >> them!!!, and its a great support too better in most cases!!!
> >
> > Yeah, isn't it nice?
> >
> some kind of beuty as having support to some hardware devices via
> non-free blobs.

That's just as sad as the other one's ideas...

Re: [GNU-linux-libre] Not free complety software, why other support nonfree os and related? umm extrano e ilogico..

[Rubén Rodríguez]

> I have been researching and viewing the list of software that is not
> free (vague and poorly made from Ubuntu the most obvious to the naked
> eye),

It was edited over 150 times on the last two years, with the help of 16
contributors. In any case, feel free to send your improvements.

> why that software compile and run most of them on windows and mac?

Because it is portable. Nothing related to the license.

> LibreOffice supports non-free formats!!!, and supports saving on
> them!!!, and its a great support too better in most cases!!!

Yeah, isn't it nice?

> I think that the list and policies that exclude software are
> extremely inflexible

Would you prefer them to be arbitrary?

, or rarely suitable for "someones"
> others .. *Libre office can support formats that are not free but
> firefox **can not do ii on **plugins? interesting ! ohh well free
> hell yeah! for me or who?*

Formats are not programs, plugins are.

> Obviously, if windozers not used and download not reach/know them as
> software right?, so there is obviously a political/independient item
> here .. and smelling like convenience for relationship between
> developers and business negociates!!

Dunno what you are on about there.

> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
> Cofundador de Venenux;  debian based multimedia alike free only
> zealots users (oh well, i try but..too many free guidelines buahhh)
> http://shutendouji.net
> creador de massenkoh linux; debian enhanchements for better up to date
> support on stable brand, including non-free soft.

That is just sad.

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

[Rubén Rodríguez]

> you can't fix it and distribute your fix which is where the real
> problem lies

No, the problem I'd like to discuss is the fact that if you don't
modify the package first (removing the trademark), you can't
distribute it in all the ways the software license allows you to.

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

[Rubén Rodríguez]

> I think Ruben's question is more of: If you take Firefox under the
> GPL, does the "you can't charge for unmodified binaries" constitute a
> "further restriction" under the GPL?

This is my main concern, yes.

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

[Rubén Rodríguez]

I've just published a Trisquel development release containing Firefox
5.0, and instead of rebranding it I made all the changes in files
separated from the Firefox package, in an attempt to avoid making
changes to it and falling into trademarks limitations. But I was wrong.

Not only my trick wouldn't work, as the trademark license[1] also
prohibits the inclusion of external modifiers that would be loaded by
the plugin system(!), but as I was pointed out, an unmodified Firefox
package which follows the trademark license can't be charged for.

So, what we have here is a program under a proper free software license
(ignoring the fact that it recommends non-free stuff) that has actual
distribution restrictions. I think trademark licenses that say "if you
modify it, you have to rename it" are ok, but this one says "if you
don't rename it, you can't distribute it for a fee".

* Does it render the program non-free?
* How does it affect the software license it ships under?
* Do you know of any other trademark license that restricts
distribution or usability?

[1] https://www.mozilla.org/foundation/trademarks/policy.html

--
Firefox(TM) is a f** trademark of the Mozilla(R) foundation.

Re: [GNU-linux-libre] Fw: Community Distribution Patent Policy FAQ now available

[Rubén Rodríguez]

> Hi all,
> Don't know if this is of interest to anyone on the list, but you might
> find it interesting.

I find it pretty pointless, as it does not say what to do (other than
the good old "ask a lawyer"). That may be because there is nothing
rational to do, as everything is patented. Avoiding the distribution of
patented software would make any distro unusable, and IMHO removing
functionality because it is patented is just a submissive way to help
the owner and keep the ball rolling.

Re: [GNU-linux-libre] dyne:bolic 3.0 beta1 - comments welcome!

[Rubén Rodríguez]

> the new dyne:III - the third series of dyne:bolic development, has
> reached its beta status and is getting ready to go public!
> 
> if you have time please let us know about your experience with

I don't have much so I didn't test it in deep, but at first sight it
doesn't look good:

* It comes with third party repositories enabled by default, including
ubuntu and medibuntu, which both contain many non-free packages.
* Installing linux-image or any other kernel flavour replaces the
default linux-libre with the vanilla kernel, complete with firmware.
* It comes with a package called "non-free-codecs" preinstalled.
* It comes with "jockey", an utility to install proprietary drivers.
* The official repository seems to lack the source code for most of
the binaries on the live cd.

> this version of our OS is based on the last stable version of
> pure:dyne "carrot and coriander" ( see http://puredyne.org ) closely
> reviewed following the 100% free guidelines set by the linux-libre
> project.

Could you explain how pure:dyne, dyne:bolic and dyne.org are related?

Re: [GNU-linux-libre] Nouveau: NONFSDG listing and current status?

[Rubén Rodríguez]

> * Nowadays Nouveau generates the necessary code itself at runtime, so
> it's in good shape.
> 
> Did I get all that right?

With one detail, recent kernels have a blob again, as it is shown in
the latest linux-libre deblobber.

> > The thing is, I feel like we lack that doc just because nobody
> > tried. :/
> 
> Mm, it's definitely not the case that nobody tried.  The FSF had a
> very similar conversation with John Bridgman: same questions, same
> answers. 

Sure that was tried, but I meant reverse engineering some documentation
or source code.

Re: [GNU-linux-libre] Nouveau: NONFSDG listing and current status?

[Rubén Rodríguez]

> On 05/17/2011 04:44 PM, Rubén Rodríguez wrote:
> >> Right now a nouveau-kernel-source package is listed on the NONFSDG
> >> page (http://libreplanet.org/wiki/NONFSDG#nouveau-kernel-source). 
> > 
> > That entry relates to karmic and jaunty, which both reached end of
> > life.
> 
> Well, that might be confusing point #1.  :)  Put that way, it's not
> immediately obvious to me whether this means "The blobs were in the
> upstream source as of karmic's release, but gone by lucid's," or
> whether it means the blobs were specifically added in Ubuntu (less
> likely, but still possible).

It is not an Ubuntu related problem. The first kernels after nouveau's
inclusion on the main tree had a blob, which later was removed when
they figured out how to generate the code at runtime. Since Ubuntu uses
a fixed kernel version for every release, only jaunty and karmic were
affected.

> > The current nouveau implementation in most distros is blob-free,
> > although it seems to be some new (optional, IIRC) blobs in the
> > latest kernels, so partial deblobbing may be necessary again in the
> > future.
> 
> That generally sounds like good news, thanks.  Is there a Nouveau
> version number or something like that that made the whole thing
> nonfree?

I have no idea, I just look into the linux-libre deblobber for every
kernel version I use to see if it comes with a nouveau part or not.

> If so, I think it would be most helpful to list Nouveau
> generally in NONFSDG, with a note that the problem was resolved as of
> version X -- that's a pretty common situation on the list at this
> point.

Well, since the problematic part of nouveau is the kernel module I think
it would make more sense to document it elsewere, as the list is for
packages. But not all the distros listed as free are using linux-libre,
so it would make sense to make this kind of problem more visible.

> > About the other free drivers, I've been looking into the Radeon
> > blobs, and in most cases they are simple 2kb -with some padding
> > zeroes- register dumps for a state machine initialization. If
> > someone more skilled than me could break them into something
> > documented we could have a lot more cards supported.
> 
> If we know for *sure* that they're just initialization values

Well, that's what AMD's John Bridgman told me, more exactly:
"They are state tables for hardware state machines.". When I asked for
some documentation, he refused replying that "we are talking about
horizontal microcode for hardware state machines so we would need to
expose the internal design of our most complex hardware blocks."

> Initialization values aren't code as such and so they don't seem
> problematic to me personally (although I wouldn't mind getting a
> second opinion on that).

I would need it. This numbers are required to enable 2D/3D acceleration
as well as managing DRM (the bad kind, as in hdmi connection quality
limitations and such), so I think having some basic documentation on the
data sections and their purpose is a must.

The thing is, I feel like we lack that doc just because nobody tried. :/

Re: [GNU-linux-libre] Nouveau: NONFSDG listing and current status?

[Rubén Rodríguez]

> Right now a nouveau-kernel-source package is listed on the NONFSDG
> page (http://libreplanet.org/wiki/NONFSDG#nouveau-kernel-source). 

That entry relates to karmic and jaunty, which both reached end of life.
The current nouveau implementation in most distros is blob-free,
although it seems to be some new (optional, IIRC) blobs in the latest
kernels, so partial deblobbing may be necessary again in the future.

> the results.  I'd guess that they'd be comparable to the way other
> free drivers work in this situation: you can make the card work but
> you get no acceleration.

The latest Trisquel release does have acceleration by installing
libgl1-mesa-dri-experimental. It is not very stable yet, though.

About the other free drivers, I've been looking into the Radeon blobs,
and in most cases they are simple 2kb -with some padding zeroes-
register dumps for a state machine initialization. If someone more
skilled than me could break them into something documented we could have
a lot more cards supported.

Re: [GNU-linux-libre] MAME license non-free

[Rubén Rodríguez]

> I thought MAME was an old-timer in Debian non-free (making it at
> least suspicious), but apparently it only just got added. 

It just entered Ubuntu universe with maverick, replacing sdlmame (which
was in multiverse). Maybe they are relaxing their policies a bit more.

[GNU-linux-libre] MAME license non-free

[Rubén Rodríguez]

The license for the MAME package restricts commercial distribution:

"Redistributions may not be sold, nor may they be used in a commercial
product or activity."

I'm adding it to the blacklist.

Via https://trisquel.info/en/issues/3453

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

[Rubén Rodríguez]

> > I assume you mean 'check to the distribution is correct and the
> > problems are upstream', rather then 'ignore the analysis of all
> > other distributions.  Is my understanding correct?  thanks, kk
> 
> nope. sometimes distributions are wrong.

Anybody can be wrong, that's why no analysis on the freedom of a
package should be ignored. Just in case it is right.

> i also think that
> if we base our analysis on original code distributed by upstream will
> keep out of the picture holy wars on distributions and personal
> feelings that might also be provoked by past experiences..

In most cases the only real license analysis existing for a package is
the one the different main distros did, so they are a good resource to
check in case of doubt, and as an starting point. In any case, just
reading the license the author listed and avoiding looking into the
package is not enough. As I said, the linux kernel is labeled "GPL2"
and we all know what comes inside.

> now i just hope Daniel cools down and smokes the peace pipe with us.

So do I.

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

[Rubén Rodríguez]

> > Do you know where to find a chromium source tarball which is
> > verified free software?
> 
> Please try in "super secret" site at www.chromium.org
> You can download alse an svn copy for developers at src.chromium.org

So, either you verified that those sources are free software or you
think there is no reason to doubt the upstream licensor about it.

Since Debian people did check the contents of those sources and wrote
the longest and most untrustworthy copyright file ever, I'm guessing you
did the latter.

May I ask if you do that with every package, and if that is the reason
for leaving blobs inside UTUTO's kernel? They say is GPL2 after all.

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

[Rubén Rodríguez]

> I now have a clearer panorama. 

How?

> Can conclude (as of the info
> provided) that Debian and Ubuntu introduce a lot of files/licencing
> changes in Chromium that are not on the source of Chromium?

No, they don't. What they do is actually look into the files they
distribute instead of assume the upstream license is ok. That's why
their copyright file is more detailed.

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

[Rubén Rodríguez]

> > It includes things marked as Copyright: UNKNOWN: License: *No
> > copyright* UNKNOWN
> > 
> 
> That is problem only for ubuntu or debian.

I don't understand why, could you explain this?

> > The debian one (they have it in stable/main) is about the same.
> > 
> >> ¿Could someone specify which so it can be removed/replaced for
> >> Ututo?
> > 
> 
> Use free code from source not debian or ubuntu packages.

Do you know where to find a chromium source tarball which is verified
free software?

> Obviously for copied-ubuntu/debian-based distribution is a hard work
> because the only one option is remove packages.

I see no difference in cleaning an upstream tarball or a debianized one.

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

[Rubén Rodríguez]

> http://libreplanet.org/wiki/Software_blacklist#chromium-browser says:
> 
> (1) Copyright or license of some code is unclear
> (2) Links to proprietary plugins.

The copyright file provided by google (the one linked at the LP
blacklist) is ok, but the actual copyright file provided by Ubuntu is
this humongous thing:
http://changelogs.ubuntu.com/changelogs/pool/universe/c/chromium-browser/chromium-browser_10.0.648.133~r77742-0ubuntu0.10.10.1/copyright

It includes things marked as Copyright: UNKNOWN: License: *No
copyright* UNKNOWN

The debian one (they have it in stable/main) is about the same.

> ¿Could someone specify which so it can be removed/replaced for Ututo?

I think it would require some effort to sort that out. It might even be
fully free, it is hard to tell.

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

[Rubén Rodríguez]

>  the Asus WL500* devices have a BCM43x chip for the wireless which
>  AFAIK is not free: the b43x driver needs a 'fwcutted' blob from the
>  windoz drivers, while the broadcom-wl which seems to be redistributed
>  by freewrt (downloaded via ipkg scripts) is proprietary.

Doesn't it work with openfwwf?

Re: [GNU-linux-libre] virtualbox-ose-additions, free or not?

[Rubén Rodríguez Pérez]

> IIRC, the license for the Additions do not permit modification, rendering 
> them 
> nonfree.

Looks like it:
http://changelogs.ubuntu.com/changelogs/pool/multiverse/v/virtualbox-guest-additions/virtualbox-guest-additions_3.1.6-1/virtualbox-guest-additions.copyright

I'll add it to the blacklist.

[GNU-linux-libre] Added testdrive and unetbootin to the blacklist

[Rubén Rodríguez]

I've added testdrive -as suggested by Jelle Hermsen- and unetbootin to
the blacklist, since they are helpers to run non-fsdg systems.

They were both removed from Trisquel.

Re: [GNU-linux-libre] Incoming Distros at libreplanet

[Rubén Rodríguez]

> It seems now that no definite procedure has been
> established. So let's establish one, ok?  Coordinating through the
> Incoming_distros page seems as good as any, to me.

I think peer review is the best way to do -in this case, computational-
science. But some hackers accept better peer criticism than others, we
had some flames in the past to prove it. So I think a mix of peer
review and a bit of arbitrage from FSF would do.

> the distro at least meets the most obvious
> criteria, like having an explicit commitment to free software.  After
> the recent mail, I also added another check for GNU webmasters to
> make -- that the sources are readily available.

Not all criteria are equally obvious to everybody. I've always thought
that having full independent mirrors for all binary and source packages
is mandatory. I think it is in fact what makes a distribution: you
distribute things, not a third party.

Re: [GNU-linux-libre] Incoming Distros at libreplanet

[Rubén Rodríguez]

> Yeah -- I thought that was the official process. It looks like the
> wiki page was originally created by quidam (aka Rubén Rodríguez from
> Trisquel.) Perhaps he can shed some light on why the page even
> exists...

I started both this list and the wiki page with the help of Danny Clark
and other FSF folks to have a place where all free distros and related
projects could talk about our stuff and share common resources.

Participating in this mailing list is open to any project which is
or wants to be fully free, regardless of any endorsement.

Re: [GNU-linux-libre] Review of Trisquel 4.0 at Distrowatch

[Rubén Rodríguez]

> i'm sorry maybe i'm a bit too much of a hippy :) but i think we are a
> "family" of distros. Trisquel appears on the 100% list on gnu.org..
> 
> usually within families people talk to each other about their problems

I'm getting the impression that you think someone from Trisquel wrote
the review. If so, you are wrong. The article is signed by Jesse Smith,
whom I never met.

Re: [GNU-linux-libre] Review of Trisquel 4.0 at Distrowatch

[Rubén Rodríguez]

> but rather than answering, i'd rather ask him why don't we have such
> debates internally? there a motto saying "you should wash your dirty
> clothes within the family"

How is this Distrowatch editor part of our family?

Re: [GNU-linux-libre] upgrade often.. or not? (was: 100% Free Software T-shirt design)

[Rubén Rodríguez]

> > Latest Puppy uses 2.6.33 and the latest xorg.
> 
> i'd love to update d:b to that, besides some other minor changes to be
> done and still pending, since it basically means more hardware
> supported. but there is a backward compatibility problem then:
> SquashFS 3.0 (as included in Linux now) is *not* backward compatible
> with SquashFS 2.0 archives, nor there is a "backport" patch to include
> that support at present time.

The squashfs module currently included in linux is 4.0, and is indeed
not backward compatible. But you should be able to upgrade the userland 
tool easily.

> hence, to upgrade beyond 2.6.18 for dyne:bolic ATM it would mean to
> drop compatibility with all the .dyne modules that users produce and
> freely exchange, while indeed one of the main features of our docked
> software bundling system is to have no central repository, but free
> exchange among users.

> what i think so far can be done to overcome this limitation is:
> - - make a squashfs 2.0 patch for Linux
> - - make a conversion utility for .dyne modules to recompress in SFS-3

Recompressing those modules is a matter of two or three commands, so it
looks like the way to go to me.

> - - don't touch anything really :) people find it a lot useful already

I can agree with this, I myself prefer stable software over new
features. My comment was just to point out that new kernels aren't
heavier, and an update shouldn't be avoided based on that assumption.

> considering i really value much the fact that users can rely on
> something to be compatible over time (let's say, that the OS is
> consistent over time) how do you think would be best to interact in
> such a situation? this is one of the main reasons keeping me away from
> touching d:b nowadays, after publishing an ALPHA release of
> 2.6.22-libre with squashfs-3 and noticing this problem.

Well, that's depends on the distro philosophy, some distros like to be
on the bleeding edge while others prefer very stable legacy pieces...

I'm guessing in any case you are patching the 2.6.18 kernel included
in d:b, otherwise it would include plenty of security holes. Also, such
a kernel is older than the first linux-libre. How was it cleaned?

Re: [GNU-linux-libre] Re: 100% Free Software T-shirt design

[Rubén Rodríguez]

> one of the main focuses of dyne:bolic for instance is that of
> supporting old computers and it doesn't helps to just upgrade any time
> a new version of a kernel, application or library is available. also
> the fact it can be customized into ad-hoc LiveCDs can be a reason to
> not upgrade, to avoid breaking backward compatibility with user-built
> software modules.

Latest Puppy uses 2.6.33 and the latest xorg.

[GNU-linux-libre] Re: 100% Free Software T-shirt design - [Fwd: Una idea...]

[Rubén Rodríguez]

> He made this draft:
> http://ark.switnet.org/files/shirt/svg/UNA%20IDEA.svg

I've made a variation on this:
http://quidam.cc/sites/default/files/tshirt.svg

I've made the objects transparent so they can be printed with one ink
(or better than that with flex or flock printing).

> This is the first draft by now, hopefully next weekend he would find
> time to keep improving it.
> The RMS logo is to be fixed on the next release also the inclusion of
> the gNS logo.

I should have read this to the end before working on it... :( 
But you get the idea.

Re: [GNU-linux-libre] Re: 100% Free Software distros T-shirt

[Rubén Rodríguez]

> I wonder if we could vectorial versions of all the logos and make a
> poster along these lines.  That would be nice!

Trisquel's: http://trisquel.info/en/wiki/logo

Re: [GNU-linux-libre] OpenOffice.org extensions

[Rubén Rodríguez]

> There's just one file that would need to be patched, and that file and
> the change that needs to be made are in the instructions on the wiki
> for using the list.

I took a look to it a couple of weeks ago, and discovered that
the Ubuntu version doesn't point to extensions.OOo, but to go-oo.org
site. Their server automatically redirects the requests to the OOo site.

As the go-oo project goals involve making OOo better, faster and freer,
maybe the FSF could convince them to do a little trick, like
redirecting the users to the new FSF page, or -to be less intrusive- to
the current one inside a frame showing a warning and a link to FSF's.
Many other first line distros use go-oo's version, so this change would
be shown to all of them without patching OOo.

By the way, I think the free extensions list is a good idea, but
linking back to extensions.openofice.org makes it pointless. Maybe
there is a way to use links to the actual file in its latest version,
as you can do with Firefox extensions -something that should also be
checked for IceCat-:

https://addons.mozilla.org/es-ES/firefox/downloads/latest/1843/addon-1843-latest.xpi

If there isn't such a way with ooo extensions, a cgi wrapper shouldn't
be hard to write.

Also, a go-oo folk told me -in a very vague way that needs a deeper
look- that even the go-oo version isn't fully free, just "freer".
It seems to include at least a binary only library -which they told me
is free, but they are lazy to cross compile-, several language tools
-hypenation filters and such- with bogus licenses and some other minor
things. I'm sorry about the lack of better info, this needs research.

Santiago Rodriguez -who found the bdb mersene file under the Artistic
license by analyzing the Trisquel 3.5 source DVD with fossology- also
found two pieces in OOO under the same license:

openoffice.org-l10n_3.1.1.orig.tar.gz/ openoffice.org-3.1.1/ ooo-build/
src/ OOo_3.1.1rc2_20090820_src_extensions.tar.bz2.dfsg/ OOO310_m19/
tomcat/ download/ jakarta-tomcat-5.0.30-src.tar.gz/
jakarta-tomcat-5.0.30-src/ jakarta-tomcat-connectors/ scandoc/
scandoc.pl

The source can be found here:
http://svn.apache.org/repos/asf/tomcat/archive/connectors/trunk/scandoc/scandoc.pl

openoffice.org_3.1.1.orig.tar.gz/ openoffice.org-3.1.1/ ooo-build/ src/ 
  OOo_3.1.1rc2_20090820_src_core.tar.bz2.dfsg/ OOO310_m19/ boost/
download/ boost-1.30.2.tar.gz/ boost-1.30.2/ libs/ graph/ LICENSE

Although the license for the Boost libraries seems to be different for
current versions: http://www.boost.org/users/license.html (fossology
confirms the new license to be that one for all files).

Re: [GNU-linux-libre] Re: License for the mersene twister implementation

[Rubén Rodríguez]

> Would the new license terms also apply to earlier versions? gNewSense 
> (Ubuntu 8.04) still has db4.2 in its repo and its newest version is
> 4.6.

No, You'll need to replace the file. This bug affects every distro.

[GNU-linux-libre] Re: License for the mersene twister implementation

[Rubén Rodríguez Pérez]

> Hello, our intention (co-inventor Takuji Nishimura and me)
> is that make the algorithm as free as possible.
> Thus, it is our pleasure to make a GNU GPL licensed version.

Thank you, these are wonderful news.

> Excuse me, but could you please specify what we should do
> for this purpose: we lack very basic knowledge on licensing
> matters.

To avoid any problems that might stop current distributors from
updating the file, you should dual license it under either the Artistic
License, or the GNU GPL 3 or any later version.

To do so, you can use the following header for the file (replacing the
paragraphs 2 and 3 of the current header):

/* Copyright (C) 1997, 1999 Makoto Matsumoto and Takuji Nishimura. */
/* */
/* This program is free software: you can redistribute it and/or   */
/* modify it under the terms of either:*/
/* */
/* a) the GNU General Public License as published by the Free  */
/* Software Foundation; either version 3 of the License, or (at*/
/* your option) any later version, or  */
/* */
/* b) the "Artistic License"   */
/* */
/* This program is distributed in the hope that it will be useful, */
/* but WITHOUT ANY WARRANTY; without even the implied warranty of  */
/* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.*/
/* */
/* You should have received a copy of the GNU General Public   */
/* License and the Artistic License along with this program.   */
/* If not, see <http://www.gnu.org/licenses/> and  */
/* <http://dev.perl.org/licenses/> */

You can apply it to the original source file I'm attaching -extracted
from BerkeleyDB 4.8- and send it back to me with copy to:

gnu-linux-libre@nongnu.org (to have a public record of distribution)
berkeleydb-info...@oracle.com (for them to update their source)

For more info on how to use the GPL license for your work, read
http://www.gnu.org/licenses/gpl-howto.html or contact with the Free
Software Foundation License Compliance Lab: licens...@gnu.org

Thank you again,
Rubén Rodríguez.


> > Mr Makoto Matsumoto,
> > 
> > I've found that the file mt19937db.c included in the BerkeleyDB
> > package as distributed by Oracle, and written by you and Takuji
> > Nishimura, is licensed under the "Artistic license". This license is
> > listed as non-free by the Free Software Foundation[1], making the
> > package unsuitable for free GNU/Linux distributions [2].
> > 
> > I've also found similar implementations[3] distributed by you under
> > the terms of the  GNU GPL, so I'd like to request you to release the
> > BerkleyDB file under a free software license too. That way we could
> > replace the file instead of writing a new implementation.
> > I'm attaching the mt19937db.c file included in bdb-4.8.24.
> > 
> > Thank you for your time,
> > Ruben Rodriguez.
> > 
> > 1:
> > http://www.gnu.org/licenses/license-list.html#NonFreeSoftwareLicense
> > 2: http://www.gnu.org/distros/free-distros.html 
> > 3: http://www.mindspring.com/~pate/cpp/mersenne.c
/*
 * $Id$
 */
#include "db_config.h"

#include "db_int.h"
#include "dbinc/crypto.h"
#include "dbinc/hmac.h"

/* A C-program for MT19937: Integer version (1999/10/28)  */
/*  genrand() generates one pseudorandom unsigned integer (32bit) */
/* which is uniformly distributed among 0 to 2^32-1  for each */
/* call. sgenrand(seed) sets initial values to the working area   */
/* of 624 words. Before genrand(), sgenrand(seed) must be */
/* called once. (seed is any 32-bit integer.) */
/*   Coded by Takuji Nishimura, considering the suggestions by*/
/* Topher Cooper and Marc Rieffel in July-Aug. 1997.  */

/* This library is free software under the Artistic license:   */
/* see the file COPYING distributed together with this code.   */
/* For the verification of the code, its output sequence file  */
/* mt19937int.out is attached (2001/4/2)   */

/* Copyright (C) 1997, 1999 Makoto Matsumoto and Takuji Nishimura. */
/* Any feedback is very welcome. For any question, comments,   */
/* see http://www.math.keio.ac.jp/matumoto/emt.html or email   */
/* matum...@math.keio.ac.jp*/

/* REFERENCE   */
/* M. Matsumoto and T. N

Re: [GNU-linux-libre] Non-free code found in nouveau-kernel-source

[Rubén Rodríguez Pérez]

> We should not remove nouveau though, as it is the only free driver
> available for nvidia cards and rapidly approaching a state where it
> will remove any need even graphics professionals or hardcore gamers
> may have for the blob. Nouveau is also much more "correct" as a
> GNU/Linux video driver because it uses native kernel DRM support
> rather than it's own layer and it supports xRandR 1.2 (nvidia's only
> supports 1.0).

They are interesting technical reasons, but you know that's not the
issue here. In fact, due to this the only free driver is the nv one.

> If the source package contains unclean blobs from other drivers, those
> blobs/drivers should be removed, not the entire package.

It *also* contains other non-free drivers -I don't know why those are
included-, but there are several non free binary blobs in the nouveau
driver itself.

> As far as I
> can tell it needs kernel DRM, but it shouldn't need the specific blobs
> for those cards, only the core layer as it ads it's own DRM module
> (which is not blobbed).

I read they are working to make the driver run without the ctx blobs,
but they are included in this backported nouveau-kernel-source package.
In the current development branch for Trisquel (based on Lucid) we have
the 2.6.32 kernel deblobbed with the linux-libre scripts and including
nouveau. I yet don't know how the blob removal would affect the driver.

[GNU-linux-libre] Non-free code found in nouveau-kernel-source

[Rubén Rodríguez Pérez]

The package nouveau-kernel-source included in Ubuntu Karmic and Jaunty
-thus, inherited by Trisquel Dwyn and Awen- contains the drm modules
for the linux kernel, which include several hexadecimal blobs. The non
free pieces seem to be in the radeon, mga and nouveau drivers.

I'm removing the package from our repo and adding it to the blacklist.

Re: [GNU-linux-libre] wireless-compat-libre? (was: Re: libc6 and other package)

[Rubén Rodríguez Pérez]

> Since the source for linux-backports-modules-2.6.31 is not a standard
> linux tarball I've modified the deblob script to make it search for
> alternative paths for files to deblob. A patch is attached.

Duh! I forgot some changes, this patch should do the trick.
--- ../deblob-2.6.31	2010-03-12 13:25:21.122384843 +
+++ DATA/linux/deblob/deblob-2.6.31	2010-03-12 14:05:26.643008917 +
@@ -47,6 +47,8 @@
 # from 1 if changes are needed that require rebuilding the tarball.
 kver=2.6.31 extra=2
 
+filelist="filelist"
+
 case $1 in
 --force)
   echo "WARNING: Using the force, ignored errors will be" >&2
@@ -80,9 +82,29 @@
 fi
 
 filetest () {
-  if [ ! -f $1 ]; then
-die $1 does not exist, something is wrong && return 1
-  fi
+export FILE=$1
+if ! [ -f $1 ]
+then
+if [ $( basename $1) = Makefile ] || [ $( basename $1) = Kconfig ]
+then
+die File not found: $1
+return 1
+fi
+
+file=$( basename $1)
+[ -f $filelist ] || find > $filelist
+if alternatives=$(egrep  /$file$ $filelist)
+then
+die File not found: $1
+echo WARNING: alternative\(s\) to $1 found: $alternatives
+export FILE=$(echo $alternatives | cut -d ' ' -f 1)
+echo WARNING: Deblobbing the first alternative: $FILE
+return 0
+else
+die File not found: $1, no alternatives found
+fi
+return 1
+fi
 }
 
 announce () {
@@ -93,8 +115,8 @@
 clean_file () {
   #$1 = filename
   filetest $1 || return
-  rm $1
-  echo $1: removed
+  rm $FILES
+  echo $FILES: removed
 }
 
 check_changed () {
@@ -110,13 +132,13 @@
   #$1 = filename
   filetest $1 || return
   if $have_check; then
-name=$1
+name=$FILE
 set fnord "$@" -d
 shift 2
 $check "$@" -i linux-$kver $name > $name.deblob
 check_changed $name && echo $name: removed blobs
   else
-clean_file $1
+clean_file $FILE
   fi
 }
 
@@ -138,7 +160,7 @@
   if test -f $2; then
 die $2 exists, something is wrong && return
   fi
-  clean_blob $1 -s 4
+  clean_blob $FILE -s 4
   dummy_blob $2
 }
 
@@ -148,7 +170,7 @@
   if test -f $2; then
 die $2 exists, something is wrong && return
   fi
-  clean_file $1
+  clean_file $FILE
   dummy_blob $2
 }
 
@@ -167,8 +189,8 @@
   filetest $1 || return
   sed "/^config \\($2\\)\$/{p;i\
 	depends on NONFREE
-d;}" $1 > $1.deblob
-  check_changed $1 && echo $1: marked config $2 as depending on NONFREE
+d;}" $FILE > $FILE.deblob
+  check_changed $FILE && echo $FILE: marked config $2 as depending on NONFREE
 }
 
 clean_mk () {
@@ -188,9 +210,9 @@
 clean_sed () {
   #$1 = sed-script $2 = file $3 = comment
   filetest $2 || return
-  sed -e "$1" "$2" > "$2".deblob || {
+  sed -e "$1" "$FILE" > "$FILE".deblob || {
 die $2: failed: ${3-applied sed script $1} && return 1; }
-  check_changed $2 && echo $2: ${3-applied sed script $1} 
+  check_changed $FILE && echo $FILE: ${3-applied sed script $1} 
 }
 
 reject_firmware () {
@@ -198,7 +220,7 @@
   filetest $1 || return
   clean_sed '
 s,request\(_ihex\)\?_firmware\(_nowait\)\?,reject_firmware\2,g
-' "$1" 'disabled non-Free firmware-loading machinery'
+' "$FILE" 'disabled non-Free firmware-loading machinery'
 }
 
 maybe_reject_firmware () {
@@ -206,7 +228,7 @@
   filetest $1 || return
   clean_sed '
 s,request_firmware\(_nowait\)\?,maybe_reject_firmware\1,g
-' "$1" 'retain Free firmware-loading machinery, disabling non-Free one'
+' "$FILE" 'retain Free firmware-loading machinery, disabling non-Free one'
 }
 
 undefine_macro () {

Re: [GNU-linux-libre] wireless-compat-libre? (was: Re: libc6 and other package)

[Rubén Rodríguez Pérez]

> I'm trying to include linux-backports-modules -Ubuntu's
> wireless-compat package- in the final version of Trisquel 3.5. The
> list of backported modules can be seen here:
> http://packages.ubuntu.com/karmic-updates/amd64/linux-backports-modules-2.6.31-20-generic/filelist
> 
> I will use the deblob script on all the source, but I can remove all
> non-free modules first. Can someone review the list and mark those to
> be deleted? 

Since the source for linux-backports-modules-2.6.31 is not a standard
linux tarball I've modified the deblob script to make it search for
alternative paths for files to deblob. A patch is attached.
--- ../deblob-2.6.31	2010-03-12 13:25:21.122384843 +
+++ DATA/linux/deblob/deblob-2.6.31	2010-03-12 13:37:47.862989651 +
@@ -47,6 +47,8 @@
 # from 1 if changes are needed that require rebuilding the tarball.
 kver=2.6.31 extra=2
 
+filelist="filelist"
+
 case $1 in
 --force)
   echo "WARNING: Using the force, ignored errors will be" >&2
@@ -80,9 +82,29 @@
 fi
 
 filetest () {
-  if [ ! -f $1 ]; then
-die $1 does not exist, something is wrong && return 1
-  fi
+export FILE=$1
+if ! [ -f $1 ]
+then
+if [ $( basename $1) = Makefile ] || [ $( basename $1) = Kconfig ]
+then
+die File not found: $1
+return 1
+fi
+
+file=$( basename $1)
+[ -f $filelist ] || find > $filelist
+if alternatives=$(egrep  /$file$ $filelist)
+then
+die File not found: $1
+echo WARNING: alternative\(s\) to $1 found: $alternatives
+export FILE=$(echo $alternatives | cut -d ' ' -f 1)
+echo WARNING: Deblobbing the first alternative: $FILE
+return 0
+else
+die File not found: $1, no alternatives found
+fi
+return 1
+fi
 }
 
 announce () {
@@ -110,13 +132,13 @@
   #$1 = filename
   filetest $1 || return
   if $have_check; then
-name=$1
+name=$FILE
 set fnord "$@" -d
 shift 2
 $check "$@" -i linux-$kver $name > $name.deblob
 check_changed $name && echo $name: removed blobs
   else
-clean_file $1
+clean_file $FILE
   fi
 }
 

Re: [GNU-linux-libre] wireless-compat-libre? (was: Re: libc6 and other package)

[Rubén Rodríguez Pérez]

> 
> It would be useful if someone would maintain a -libre version of
> wireless-compat.

I'm trying to include linux-backports-modules -Ubuntu's wireless-compat
package- in the final version of Trisquel 3.5. The list of backported
modules can be seen here:
http://packages.ubuntu.com/karmic-updates/amd64/linux-backports-modules-2.6.31-20-generic/filelist

I will use the deblob script on all the source, but I can remove all
non-free modules first. Can someone review the list and mark those to
be deleted? 

Re: [GNU-linux-libre] Re: Freeing Unrar

[Rubén Rodríguez Pérez]

> > As I understand, it does not limit the possibility of using it as a
> > reference for a free implementation of the *de*compression
> > algorithm. As an example, the zip and unzip programs come from
> > different source packages. INAL, but I see no problem in creating a
> > GNU unrar program, as long as the code from unrarsrc is not used,
> > just the concepts.
> 
> This is more or less what I am already trying to do, but even
> extracting the concepts is not easy. Unrar uses 2 decompression
> algorithms, a virtual machine, several filters, a lot of headers,
> encription, etc.

What's the status on this? Are you still on it? If you are having
trouble maybe we can do a call for help.

Re: [GNU-linux-libre] Packages under the artistic license

[Rubén Rodríguez Pérez]

> Either way does someone have a volunteer whos got nothing to do?
> someone to approach upstreams and ask them to dual licence under _any_
> free licence would be great.

The first step would be to make a better list. I just did a first look,
so I've probably left packages behind. Also, some of the packages in
the list are already dual licensed, but the packager listed them wrong.

As an example: bioperl.org front page says:
"BioPerl is distributed under the Perl Artistic License. For more
information, see _licensing_BioPerl_."
But when you go to _licensing_BioPerl_, they say: "BioPerl is licensed
under the same terms as Perl itself, which means it is dually-licensed
under either the Artistic or GPL licenses."

The debian packager didn't go that deep, and I carried the mistake on.

[GNU-linux-libre] Packages under the artistic license

[Rubén Rodríguez Pérez]

After some research, I've found a set of programs and perl modules
released under the original Artistic License alone, a license that as
you know is listed as non-free by the FSF:
http://www.gnu.org/licenses/license-list.html#ArtisticLicense

One important package I've found is libxml-twig-perl, as it is required
by several GNOME packages. The latest version of the package (3.32-3
and up) is licensed "under the same terms as Perl itself", that is,
under both the Artistic License and the GPL version 1 or later.

I recommend an free distro to upgrade the package as needed.

The (probably incomplete) list of programs licensed under the original
Artistic License alone is:

aee and ee: ncurses text editors
aft: "free form" document preparation system
angband-doc: Documentation for the roguelike game Angband
bioperl: Perl tools for computational molecular biology
chromium: fast paced, arcade-style, scrolling space shooter
coldsync: A tool for syncing PalmOS PDAs with Unix workstations
cracklib2: PAM plugin
cron: includes a script called crontab2english, under the Artistic L. 
durep: create disk usage reports
gbase: small numeric base converter
htp: An HTML pre-processor
icmpinfo: Interpret ICMP messages
iog: Network I/O byte grapher
lphdisk: prepares hibernation partition for Phoenix NoteBIOS
mancala: Implementation of the simple board game called Mancala
matwrap: wrapper generator for matrix languages
mp32ogg: Converts MP3 file to Ogg Vorbis
mummer: Efficient sequence alignment of full genomes
nbibtex: Powerful, flexible replacement for bibtex
njplot: A tree drawing program
pgadmin3: graphical administration tool for PostgreSQL
pgagent: job scheduler for PostgreSQL
pmtools: Perl module tools
poppass-cgi: a CGI script to interact with a poppassd server
postmark: File system benchmark from NetApp
pv: Shell pipeline element to meter data passing through
qstat: Command-line tool for querying quake (and other) servers
rman: Converts man pages into other formats 
rmagic: Report Magic for Analog
snake4: Snake game
tidy-proxy: A small http proxy which tidies html
tkman: A graphical, hypertext manual page and Texinfo browser
ttf-alee: Hangul truetype fonts
ttf-f500: Wipeout 3 Font
vcheck: Utility to check and download the most recent program version
wmgtemp: Temperature sensor dockapp for Window Maker
wwwstat: httpd logfile analysis package
xtv: View the screen of a remote X11 display

I've also identified the following perl modules (listed by the Debian
package names):

libapache-gallery-perl libauthen-radius-perl libbit-vector-minimal-perl
libcarp-datum-perl libcarp-datum-perl libcgi-formalware-perl
libcgi-formalware-perl libcgi-xmlform-perl libchart-strip-perl
libclass-data-inheritable-perl libclass-singleton-perl libcoy-perl
libcrypt-cbc-perl libcrypt-twofish-perl libdate-leapyear-perl
libdb-file-lock-perl libdevel-profile-perl libemail-foldertype-perl
libflickr-api-perl libfont-ttf-perl libgd-gd2-noxpm-perl libgd-gd2-perl
libgetopt-declare-perl libimap-admin-perl libio-dirent-perl
liblog-agent-perl liblog-agent-rotate-perl libmail-bulkmail-perl
libmp3-tag-perl libnetaddr-ip-perl libnet-irc-perl
libnumber-compare-perl liboxford-calendar-perl libpalm-perl
libparse-recdescent-perl libpasswd-unix-perl libpdf-report-perl
libromana-perligata-perl libsnmp-session-perl libstring-escape-perl
libsys-cpu-perl libtext-aspell-perl libtext-autoformat-perl
libtext-pdf-perl libtree-multinode-perl libtree-redblack-perl
libxml-perl

The list was made using the current Trisquel repo, that currently
includes the main and universe sections of Ubuntu hardy, jaunty and
karmic. I've manually excluded those packages licensed as "Artistic 1 or
later", "Artistic 2", "Clarified Artistic" or dual licensed with GPL.

I've asked RMS and Brett what to do about this issue.

Re: [GNU-linux-libre] ee 1.4.2 - artistic license 1.0

[Rubén Rodríguez Pérez]

> I noticed on the upstream website that there's also aee from the same 
> author and under the same license.

Thanks Sam, I'll remove it and list it on the wiki too.

[GNU-linux-libre] ee 1.4.2 - artistic license 1.0

[Rubén Rodríguez Pérez]

Marcooliva just sent the message below to the Trisquel bugtracker.The ee
package uses the artistic license 1.0 so we removed it. It comes from
the Ubuntu hardy repositories.

I'll add it to the libreplanet wiki list.

Begin forwarded message:

Subject: [trisquel] [bug] ee 1.4.2 - artistic license 1.0


Issue status update for
http://trisquel.info/en/issues/ee-142-artistic-license-10
Post a follow up:
http://trisquel.info/en/comment/reply/1641#comment-form


  Project:  Trisquel
  Version:  3.0
  Component:Programs
  Category: bug report
  Priority: critical
  Assigned to:  Anónimo
  Status:   active
  Updated by:   marcooliva

http://archive.trisquel.info/trisquel/pool/extras/e/ee/ [1]


http://www.gnu.org/licenses/license-list.html#NonFreeSoftwareLicense
[2]

[1] http://archive.trisquel.info/trisquel/pool/extras/e/ee/
[2]
http://www.gnu.org/licenses/license-list.html#NonFreeSoftwareLicense

marcooliva

Re: [GNU-linux-libre] teeworlds not free software

[Rubén Rodríguez Pérez]

> 4. Neither this software nor any of its individual components, in
> original or modified versions, may be sold by itself.

You can still include a helloworld.c in the tarball and sell both
together.

[GNU-linux-libre] Incoming distros page at libreplanet

[Rubén Rodríguez Pérez]

I've created a new page at libreplanet listing the incoming free
distributions that I know. If you know of other projects or hackers
interested in creating a new free distro, add it to the page or tell it
here and I will add them. 

The page is: http://groups.fsf.org/wiki/Incoming_distros

Also, I will contact with all this projects inviting them to join here.

Freeing Unrar - Was Re: [GNU-linux-libre] editable sections on Software_blacklist

[Rubén Rodríguez Pérez]

> there is no fix for unrar yet

The non-free (but open source) unrar lib[1] has this license:

   4. Legal stuff

   Unrar source may be used in any software to handle RAR archives
   without limitations free of charge, but cannot be used to re-create
   the RAR compression algorithm, which is proprietary. Distribution
   of modified Unrar source in separate form or as a part of other
   software is permitted, provided that it is clearly stated in
   the documentation and source comments that the code may not be used
   to develop a RAR (WinRAR) compatible archiver.

As I understand, it does not limit the possibility of using it as a
reference for a free implementation of the *de*compression algorithm.
As an example, the zip and unzip programs come from different source
packages. INAL, but I see no problem in creating a GNU unrar program,
as long as the code from unrarsrc is not used, just the concepts.

1: http://www.rarlab.com/rar/unrarsrc-3.9.6.tar.gz


pgpI1747KpoEk.pgp
Description: PGP signature

Re: [GNU-linux-libre] editable sections on Software_blacklist

[Rubén Rodríguez Pérez]

> * Change "Fixed from version" to say "Recommended fix" -- we're
> already using it along those lines anyway.  :)
> 
> * Make at least some of the fields (I had in mind H, F, R, and C)
> optional, so that if they're not specified, the information just
> doesn't show up in the box at all.  These are not really appropriate
> for every entry: there is no fix for unrar yet, the problem with
> Firefox can't be illustrated through the copyright file, etc.
> 
> Sound good?

Sure, feel free to modify the template. I made it just as a starting
point (I'm not a mediawiki expert either).


pgpYDRW6K6JUb.pgp
Description: PGP signature

Re: [GNU-linux-libre] Can linux-firmware get addeed to Software_blacklist?

[Rubén Rodríguez Pérez]

> Any objections to me adding it onto S_B?

None, go ahead.

Re: [GNU-linux-libre] Non-free downloader script found in texlive-bin

[Rubén Rodríguez Pérez]

> For the package in gNS it looks like this:
> 
> (hardy-CHROOT-i386)r...@rommel:~/texlive-bin# find ./ -name *nonfree*
> ./texlive-bin-2007.dfsg.1/debian/patches/60_getnonfreefonts_bash
> ./texlive-bin-2007.dfsg.1/texmf/doc/man/man1/getnonfreefonts.1
> ./texlive-bin-2007.dfsg.1/texmf/doc/man/man1/getnonfreefonts-sys.1
> ./texlive-bin-2007.dfsg.1/texmf/tpm/bin-getnonfreefonts.tpm
> ./texlive-bin-2007.dfsg.1/build/source/texk/texlive/getnonfreefonts-sys.man
> ./texlive-bin-2007.dfsg.1/build/source/texk/texlive/getnonfreefonts.man
> ./texlive-bin-2007.dfsg.1/build/source/texk/texlive/getnonfreefonts
> 
> They should probably all go, I'm trying a rebuild with `-exec rm -v {}
> +` to see how it works out.
> kk

This is how we clean it: http://trisquel.pastebin.com/m6d81cfe3


signature.asc
Description: Esta parte del mensaje está firmada digitalmente

[GNU-linux-libre] Non-free downloader script found in texlive-bin

[Rubén Rodríguez Pérez]

Vicente Herrera (Trinux) reported in the Trisquel bugtrack a script
called getnonfreefonts, present in the texlive-bin package. It downloads
and installs several non-free fonts from the adobe website. The script
can be removed with no harm. I'm updating the libreplanet wiki with it.

More info:
http://trisquel.info/en/issues/texlive-base-bin-tiene-un-guion-que-descarga-fuentes-no-libres-de-adobe
http://man.he.net/man1/getnonfreefonts
http://packages.ubuntu.com/search?suite=jaunty§ion=all&arch=any&searchon=contents&keywords=getnonfreefonts



signature.asc
Description: Esta parte del mensaje está firmada digitalmente

[GNU-linux-libre] Re: GNU Buck as incentive for helping to find nonfree programs

[Rubén Rodríguez Pérez]

> In order to implement this program, can you please let us know how you
> would like to receive these bug reports?

Trisquel's bugtrack is at http://trisquel.info/en/project/issues


signature.asc
Description: Esta parte del mensaje está firmada digitalmente

Re: [GNU-linux-libre] gNewSense 2.3 released.

[Rubén Rodríguez Pérez]

El lun, 14-09-2009 a las 14:12 +0930, Karl Goetz escribió:
> I thought this list might be interested; appologies if its spam :)
> kk

Sure we are :)


> * Freedom bugs fixed:
>  - Several packages freed
>  - Over 15 packages removed
>  - Over 20 sourceless files removed from Linux

I wasn't expecting you to publish an update, as I don't recall you
talking about that in your devel lists, so I'm sorry to say I have some
scripts you could have used -or taken into consideration- before an
update. I talked with samgee three days ago regarding to this, and I
told him I was about to raise this issue here this week.

The issue is the 2.6.24 deblobber coming from linux-libre being
outdated. It leaves all those "free drivers requesting non-free
firmware" pieces in place. That's why I wrote a patch to the latest
2.6.30 deblobber, allowing it to be used over an older kernel.

As an extra inprovement, it gets back to life some drivers as the BNXII
or e100. That is why we updated our 2.2 branch to 2.2.1 the same day as
the Trisquel 3.0 release, including this new kernel.

I sent the patch to the linux-libre list two weeks ago:
http://www.fsfla.org/pipermail/linux-libre/2009-September/000754.html

Re: [GNU-linux-libre] New entries on FSF's fully free GNU/Linux list

[Rubén Rodríguez Pérez]

> As I see you are concerned about bandwidth requirements (a big concern 
> also in rural Spain), perhaps you would be interested in lzip[1]

That would be an improvement. I'd like to ask though, how come
distributing sources is better than distributing binaries in this case.
Our source isos are 3 times bigger than the binary ones, maybe your
package system makes the difference here. Can you give us some figures?

Re: [GNU-linux-libre] New entries on FSF's fully free GNU/Linux list

[Rubén Rodríguez Pérez]

> I would like to throw in some congratulations to the Trisquel guys as
> well - we all know just how much work it is to keep and build a free
> distribution, so kudos to you for doing your part.

Thank you, and congratulations. Your project looks very interesting, I'm
downloading the iso right now! :)

Re: [GNU-linux-libre] Non-free packages in debian lenny

[Rubén Rodríguez Pérez]

El mar, 08-09-2009 a las 18:03 -0500, Karl Berry escribió:
> texlive-base# 477060
> texlive-latex-base  # 483217
> 
> I am the chief maintainer of TeX Live.  I am not aware of any nonfree
> software included (that won't be fixed in the next release).  My policy
> is for TeX Live to follow the GNU (not Debian) free software guidelines.
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477060 is about
> amslatex.  It uses the same license used by Don Knuth in many of his TeX
> files, which was long since declared free according to rms, whatever
> conclusions Debian reaches.  (There is no doubt the wording is not good
> by today's standards.)  And AMS said they would be fixing the license in
> the next release.
> 
> 483217 is about a very few specific LaTeX files.  I will review/remove
> as appropriate.  The bug report is some 16 months old, so I expect at
> least some of them have already been handled.
> 
> In short, I see no reason to blacklist texlive.

I'm glad to hear that. I got to know about this bugs via the Venenux
list yesterday and I didn't had the time to review them, but of course a
full review is needed for every package before being blacklisted.

[GNU-linux-libre] Non-free packages in debian lenny

[Rubén Rodríguez Pérez]

The package list below is a repost of one made by Robert Millan from
before myself receiving the gNS-dev list -so it slipped off-. (Thanks to
Alexis PM for pointing me towards it).

This packages, and the Debian bugtrack numbers where extracted from
http://bugs.debian.org/tag:lenny-ignore


afio# 509287
texlive-base# 477060
texlive-latex-base  # 483217
libsnmp-base# 498475
libsmi2-common  # 498476
pike7.6 # 459705
gkrell-snmp # 508292

(and linux, of course)

I'll include this packages in the blacklist ASAP:
http://groups.fsf.org/wiki/Software_blacklist

Please, report *any* non-free package you know being in a main -posing
as free- repository, no matter which mainstream distro it is part of, so
we can include it in the blacklist.

Re: [GNU-linux-libre] Plagarised data files in freedom

[Rubén Rodríguez Pérez]

El dom, 30-08-2009 a las 14:36 +0930, Karl Goetz escribió:
> Hi all,
> 
> Depending on when you last updated your freedoom packages, this may
> affect you:
> http://bugs.gnewsense.org/Bugs/00324
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533135
> 

Removed in Trisquel, thanks.

[GNU-linux-libre] Re: [Gnewsense-dev] 9wm - No FSF Free

[Rubén Rodríguez Pérez]

El vie, 28-08-2009 a las 23:48 +0100, Marco Oliva escribió:
> " The argument that there's a strongly-implied right to modify is unlikely to 
> fly in many countries outside the US. "
> 
> -> https://fedoraproject.org/wiki/Licensing#Bad_Licenses
> 
> -> http://archive.gnewsense.org/gnewsense/pool/universe/9/9wm/
> 


It was also reported at Trisquel (thanks, Marcooliva), but I didn't have
much time to review it, as it is a tricky license this one. Its problem
is the absence of *explicit* permission for modifications:

---

9wm is free software, and is Copyright (c) 1994 by David Hogan.
  Permission is granted to all sentient beings to use this software,
  to make copies of it, and to distribute those copies, provided
  that:

  (1) the copyright and licence notices are left intact
  (2) the recipients are aware that it is free software
  (3) any unapproved changes in functionality are either
(i) only distributed as patches
or (ii) distributed as a new program which is not called 9wm
and whose documentation gives credit where it is due
  (4) the author is not held responsible for any defects
  or shortcomings in the software, or damages caused by it.

  There is no warranty for this software.  Have a nice day.



Notes:

- The package is included in debian main [1]
- 9wm licence is not listed in the -informal- debian dfsg license list [2]
- The author, sadly, died [3]

1 http://packages.debian.org/search?keywords=9wm
2 http://wiki.debian.org/DFSGLicenses
3 http://lwn.net/Articles/312262/

Re: [GNU-linux-libre] No license for package tatan

[Rubén Rodríguez Pérez]

> 
> I can't find this package in Hardy or gNS. Was it imported to Trisquel
> specially?

It was in the Trisquel 3.0 (jaunty based) repos. Anyway, maybe we was
too fast with this one, it is still under review.

[GNU-linux-libre] No license for package tatan

[Rubén Rodríguez Pérez]

Reported by Marcooliva:

http://trisquel.info/en/issues/tatan-10-license-not-found

1 - I did not find the license.

2 - tatan/import has many files without license, and, many files with code 
similar to, example:
In tatan/import/opengl.d ->  " 0x0102 " .

3 - tatan/src/util has many files without license, and, in 
tatan/src/util/rand.d is written: "/*
 * $Id: rand.d,v 1.2 2005/01/01 12:40:28 kenta Exp $
 *
 * Copyright 2004 Kenta Cho. Some rights reserved.
 */



/*
...
Copyright (C) 1997 - 2002, Makoto Matsumoto and Takuji Nishimura,
   Copyright (C) 2003, Andrew C. Edwards
   All rights reserved.
...
*/"

4 - tatan/src/br has all files without license.

Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files

[Rubén Rodríguez Pérez]

> welcome to gnash, gnash only works with  propietary codified content,
> ok not program, but content
> 
> and of course world is not a static place, perhaps today we do not
> have a free firmware, but tomorow yes
> 
> so this *only* have a complex timeframe: today, always?


If you are actually saying that Gnash and similar packages should be
avoided due to ethical concerns, I suggest you to start a new tread with
your ideas about that issue, so we can focus on the firmware thing here.

Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files

[Rubén Rodríguez Pérez]

> Why does the firmware load mechanism need to be disabled? I'd have
> thought leaving it enabled is more likely to encourage development on
> free alternatives (by lowering the barrier to entry when it comes to
> testing them).

I don't know if such a driver encourages or helps developers (I think it
does not). The point is that we should never distribute a piece of
software that can *only* work if the user feeds it with a non-free
program. The method you choose to avoid that problem is up to you.

Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files

[Rubén Rodríguez Pérez]

El mié, 19-08-2009 a las 09:51 -0300, Diego Saravia escribió:
> > Why does the firmware load mechanism need to be disabled? I'd have
> > thought leaving it enabled is more likely to encourage development on
> > free alternatives (by lowering the barrier to entry when it comes to
> > testing them).
> > kk
> 
> $agree++;

I think we are miscommunicating here.

Quoting your response to Karl Berry:

>> So ... how about if the GPL'd code is included, but with a disabled
>> firmware loading mechanism, and instead of printing the missing fw
>> files, they print an error message with an explanation why the device
>> is not supported? 

[trimmed]

>its ok, its what ututo does

I'm lost. Does this mean that Ututo's kernel is already not requesting
non-free firmware, but you'd like to change it back?

Re: [GNU-linux-libre] Additions to Software_blacklist

[Rubén Rodríguez Pérez]

> Is it my imagination or is the text on the edit page smaller then when
> viewing normally?

No, it was the opposite. It's fixed now.

Re: [GNU-linux-libre] Additions to Software_blacklist

[Rubén Rodríguez Pérez]

El mié, 19-08-2009 a las 16:10 +0930, Karl Goetz escribió:
> On Fri, 14 Aug 2009 10:25:23 +0200
> Rubén Rodríguez Pérez  wrote:
> 
> > El vie, 14-08-2009 a las 14:10 +0930, Karl Goetz escribió:
> > > Hi all,
> > > The following software seems to be removed from gNS but not listed
> > > on the shared wiki page [1]. Due to my fsf login /not/ working to
> > > let me in, I've been unable to add them to the page yet.
> > 
> > Thanks, I'll check this list in a while.
> 
> Anyone else want to comment?
> If not, I'll add these items to the wiki page (I've created a local
> login for it).

I'm working on it (last night I added a template to improve the list a
little), and I plan to add more data this days. But please, join me! :)

Re: [GNU-linux-libre] A call to free software, and its users

[Rubén Rodríguez Pérez]

> 
> "To recommend mplayer is, in effect, to promote use of the non-free codecs"
> 
> the same with gnash.

Gnash allows you -with no non-free software required- to view animations
stored in a proprietary format, like Abiword can open a word file.

Mplayer documentation encourages you to install non-free codecs as extra
plugins for the program, they even distribute a pack of dll's for that.

Also remember: a non-free firmware file is *not* data in a proprietary
format (like a word file), it is a non-free program. So using Gnash as a
comparison is misleading.

Re: [GNU-linux-libre] Freedom issues with non-free firmware in external files

[Rubén Rodríguez Pérez]

> > I prefer the first, I don't see the point of distributing a useless
> > program that still depends on a non-free part that now cannot be
> > loaded. Linux-libre chooses this solution, stating that the modified
> 
> Unless it doesnt depend on non-free parts, because there is free
> firmware.

Sure. The example is the broadcom b43 driver, which has a non-free
firmware and a free one. We should distribute both the module and the
free firmware together.

Re: [GNU-linux-libre] A call to free software, and its users

[Rubén Rodríguez Pérez]

> We could go one step further, so we could not provide direct links to
> a propietary material.

Yes, we should not provide links to non-free software, or lead our users
to such a resource. In fact we shouldn't refer to that programs other
than to say that they are not free and therefore not recommended.

Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files

[Rubén Rodríguez Pérez]

El lun, 17-08-2009 a las 16:53 -0300, Diego Saravia escribió:
> 2009/8/17 Alexandre Oliva :
> > Do you acknowledge that point?  Do you agree with it, i.e., do you agree
> > that users can get the driver and firmware on their own and install it,
> > regardless of whatever ships in a Free System Distribution?
> 
> 
> I am not god
> 
> I do not believe in god
> 
> That users can do that is a reality, I cant do anything about that
> 
> What I can do is work to a) promote the develop  of a free driver
> b) bypass a law to end copyright c) reverse engeneer the blob, etc

You can still do all that things even if you do not distribute this
not-usable-in-freedom drivers. They are separate problems.

> 
> Users can do what they want.

That is the idea. Even if you, as a free software distributor, choose
not to ship that drivers, users can still download an use them if they
like, so you are oppressing nobody.


> do you have a problem with that?
> 
> I can speak, promote free ideas, etc,
> 
> what do you want', a law to send to jail users of non free software?
> 
> do you want to kill them?


Please, just calm down, that attitude is not going to help.

Re: [GNU-linux-libre] Freedom issues with non-free firmware in external files

[Rubén Rodríguez Pérez]

El sáb, 15-08-2009 a las 10:55 +0930, Karl Goetz escribió:
> In order of preference, I'd go with:
> 
>  - Modify driver to print a warning.
>  - Modify driver to print a warning (disable loading files)
>  - Disable driver at compile time.
>  - Remove driver (source) completely.

>From that list, only two look "free enough" to me:

-Remove driver (source) completely.
-Modify driver to print a warning (disable loading files)

I prefer the first, I don't see the point of distributing a useless
program that still depends on a non-free part that now cannot be loaded.
Linux-libre chooses this solution, stating that the modified error
message can be used to teach the user about freedom. That way the
program is not useless, but I still prefer to remove it.

> 
> > > > -Should they be kept, but disabling the file load call?
> > > 
> > > what if someone develops a free file replacement?
> > 
> > Then the maintainer of the freed version of the kernel can stop
> > removing that module.
> 
> This would be easier if it was compiled out then if it was rm'd out.

Difficulty can only be used to choose between valid solutions. Same goes
for any other practical concern. If you choose not to compile the driver
to fix an ethical issue, then you shouldn't distribute the code either.

Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files

[Rubén Rodríguez Pérez]

First, please everyone remember to CC your messages to rms.

El dom, 16-08-2009 a las 18:42 +0200, Daniel Olivera escribió:
> Now we reject a gpl-2 software?
> 
> If this software have 4 liberties is free software.
> 
> Becuse
> 
> we can use this software
> we can access to source code
> we can change this software
> we can distribute modified copies
> 
> if this 4 liberties are in any software software is free according to
> FSF definition.


With a driver composed by a GPL'd module and a non-free firmware, you
cannot have, nor provide the four freedoms. You don't have the code for
all the required pieces, so you cannot modify it and thus you cannot
redistribute your changes. You cannot use it freely, so in fact you have
non of the four freedoms.

This kind of driver is not free software.

You don't even have the four freedoms for the GPL'd part either. As the
non-free part is hidden to you, you don't know how to modify the free
part. Many changes must match the requirements in the firmware.

Re: [GNU-linux-libre] Re: Freedom issues with non-free firmware in external files

[Rubén Rodríguez Pérez]

> 
> No solamente eso,
> 
> Se obliga a los que escriben en FSFLA (LATINOAMERICA) a hablar inglés!!
> 
> UN DELIRIO opresivo.

Marcos, este hilo es para aclarar dudas sobre las directivas de FSF para
distros libres, no para vuestras peleas personales. Afecta a muchos
proyectos de diversos países, por lo que el inglés puede ser útil.
No se ha obligado a nadie a participar en este hilo ni en esta lista,
que por otra parte he de decir que es independiente y no asociada a
ninguna entidad concreta -incluyendo FSF-.

Como ves, estoy contestando en español -aunque sé que hablas inglés-,
porque has decidido enviar esta conversación a tres listas más, entre
ellas SolAR general. Otro de los motivos para iniciar un nuevo hilo en
esta lista era desalojar la lista de SolAR como pidieron los
administradores. Por favor, mantengamos la discusión en gnu-linux-libre.

[GNU-linux-libre] Re: Freedom issues with non-free firmware in external files

[Rubén Rodríguez Pérez]

El vie, 14-08-2009 a las 22:30 -0400, Richard Stallman escribió:
> Lest people get the wrong idea, I should point out that the FSF
> is not considering a change in its criteria for free distros.
> The discussions now occurring on certain lists include a lot of
> misunderstanding about what these criteria are and what they mean.
> I have not seen any reason to reconsider the decision.

My apologies if someone get that idea from my words. I don't think the
criteria should be changed either, but it might need some clarification.
I hope you can help us with that.

Note for the list users: rms is not subscribed to the list, so remember
to CC your messages to him (or better, use "reply all").

Re: [GNU-linux-libre] Freedom issues with non-free firmware in external files

[Rubén Rodríguez Pérez]

El vie, 14-08-2009 a las 16:46 -0300, Diego Saravia escribió:
> >> or only print info about what is missing?
> >
> > The vanilla kernel prints an error about the missing files if the
> > request fails. For the case of non-free blobs, linux-libre now prints
> > a /*DEBLOBBED*/ message, and the files are not actually requested.
> 
> Ututo now also prints a special message.

Nice. What does it say?

> 
> > If a driver needs a non-free firmware file to work, removing it renders
> > the driver useless, so you can remove it. Having non working drivers
> > looks pointless to me, and can -maybe in a subtle way- cause harm.
> 
> could you tell us about this subtle harm?

E.g. someone can tell your users how to make the driver work, by
recommending to use the non-free file, thus harming their freedom. It's
not you who is causing the harm, but the one who recommends the file.
But if the driver is removed, you are not even allowing that to happen.

> 
> > Then the maintainer of the freed version of the kernel can stop removing
> > that module.
> 
> and the people will need to upgrade, a lot of additional work

How can you provide your users with a new driver without an upgrade?

> 
> >> is there another way to detect that hardware?
> >
> > All hardware can be detected. That part doesn't matter.
> 
> can is different than doing it. Why do you think that do not matter

I think you are using "detecting" in a different way than I do. The
kernel does not need the modules to know if a piece of hardware is
present. No matter if you remove the module, it can be detected.

> 
> >> is not usefull to know what hardware do not have frre software to work 
> >> with?
> >
> > Yes, but how is that related to the load call thing?
> 
> is related to the module
> 
> modules are a way to know if the hardware exists and is working.

You can't tell if -let's say- a ipw2100 card is broken unless you use
the non-free firmware. I wouldn't care if it's broken, it doesn't work
with free software anyway, so it is always broken.

> >> > -What is enough to comply with the Guidelines for Free System
> >> > Distributions? [3]
> >>
> >> is this free guideline fine?
> >
> > Is ok for me, but maybe it needs some clarifications (like this issue).
> 
> its not weel organized, have a lot of confusing parts, etc
> 
> but the principal issue is its central argument
> 
> we have free software definition, a huge agreement about that, why try
> to impose additional conditions?

I don't see the guidelines being imposed. I see them as an useful set of
recommendations -not everyone is aware of the issues of a free distro-,
and it can be useful for non-free distros that might like to go libre.

Additional positions should be taken every time a new threat appears.

> why to speak about trademarks and  non functional non-free works
> 
> we are talking about a free distribution with non free material, why?
> For example debian is more restrictive on that

Everyone has a viewpoint, that is why they are called guidelines, and
that is why I think we should talk about them.

Including non-modifiable art is ok to me. Trademarks and patents are
important issues that every distro needs to be aware of.

> >> is free-linux something usefull? or the removal can be done by a
> >> script running over a normal kernel?
> >
> > I'm not sure if I'm getting your question. :|
> 
> do the world need free-linux?

That is a rude question. If you don't like it, don't use it, it's not a
requirement. I mentioned it as an example implementation of a freed
kernel, and it is used by several projects in this list, so it makes the
task of cleaning more easy for a lot of hackers including myself.

> >
> >> do free distros must have non-free-software-having-hardware detection
> >> procedures and user warnings?
> >
> > Please, explain "non-free-software-having-hardware detection procedures"
> 
> capability to detect and warn user about hardware without free software

I think it is a nice feature, that allows us to tell the user about the
perils of non-free software. I also think it shouldn't be mandatory.

Re: [GNU-linux-libre] Freedom issues with non-free firmware in external files

[Rubén Rodríguez Pérez]

> > -Should GPL modules that are useless without the non-free firmware files
> > be removed?
> >
> 
> I think that the GPL modules should not be removed, because if "we" have 
> them, "we" can develop free GPL firmwares, "we" need the hardware to 
> experiment, 
> 
> what do u think?

"We" as driver hackers, have the code anyway, we know where to find it.
"We" as software distributors must think of our end users, who deserve a
fully free system. I think that a program that needs a proprietary piece
to work is not free software, even if it is GPL'd.

Re: [GNU-linux-libre] Freedom issues with non-free firmware in external files

[Rubén Rodríguez Pérez]

El vie, 14-08-2009 a las 14:15 -0300, Diego Saravia escribió:
> >-Linux includes some -GPL'd- modules that load firmware files into the
> >devices. Most of that files are non free,
> 
> or only some?

I don't know the figures, but many.

> > -Newest linux-libre versions remove not only the embedded blobs, but
> > also the ability of the modules to request non-free firmware files.[2]
> 
> request?
> 
> or only print info about what is missing?

The vanilla kernel prints an error about the missing files if the
request fails. For the case of non-free blobs, linux-libre now prints
a /*DEBLOBBED*/ message, and the files are not actually requested.


> > -Should GPL modules that are useless without the non-free firmware files
> > be removed?
> 
> why?

(From now on, this is _my_ personal opinion)

If a driver needs a non-free firmware file to work, removing it renders
the driver useless, so you can remove it. Having non working drivers
looks pointless to me, and can -maybe in a subtle way- cause harm.

> > -Should they be kept, but disabling the file load call?
> 
> what if someone develops a free file replacement?

Then the maintainer of the freed version of the kernel can stop removing
that module.

> is there another way to detect that hardware?

All hardware can be detected. That part doesn't matter.

> is not usefull to know what hardware do not have frre software to work with?

Yes, but how is that related to the load call thing?

> >
> > -What is enough to comply with the Guidelines for Free System
> > Distributions? [3]
> 
> is this free guideline fine?

Is ok for me, but maybe it needs some clarifications (like this issue).

> >
> > Note that this issue was already discussed in January by Richard
> > Stallman, Alexandre Oliva et. al. at the linux-libre lists[4], leading
> > Alexandre to implement one of the discussed solutions in the linux-libre
> > deblobber. Other solutions are possible, so this new thread should focus
> > on what is _enough_ to achieve a fully free kernel.
> 
> is free-linux something usefull? or the removal can be done by a
> script running over a normal kernel?

I'm not sure if I'm getting your question. :|

> do free distros must have non-free-software-having-hardware detection
> procedures and user warnings?

Please, explain "non-free-software-having-hardware detection procedures"

[GNU-linux-libre] Freedom issues with non-free firmware in external files

[Rubén Rodríguez Pérez]

There is an ongoing discussion at the FSFLA and SolAR lists[1] to decide
if the ability of the linux kernel to request non-free firmware should
be removed or changed, if  the whole drivers should be deleted, or if it
is enough to remove the offending firmware files and discourage its use.

As this issue affects all distros, and the conversation was also
generating some complaints from the list administrators, I'd like to
start a new thread here.

I'll try to summarize the ideas in a neutral way:

-Linux includes some -GPL'd- modules that load firmware files into the
devices. Most of that files are non free, and most of them are required
to get the device working. All the free distros exclude that files.

-Older linux-libre versions -still in use in several distros- remove the
non-free blobs embedded in .c and .h files. External non free firmware
files are also deleted. Other cleaned linux versions work this way.

-Newest linux-libre versions remove not only the embedded blobs, but
also the ability of the modules to request non-free firmware files.[2]

The questions that came from that include:

-Is enough to remove the non-free firmware files from the distro and
discourage its use?

-Should GPL modules that are useless without the non-free firmware files
be removed?

-Should they be kept, but disabling the file load call?

-What is enough to comply with the Guidelines for Free System
Distributions? [3]

Note that this issue was already discussed in January by Richard
Stallman, Alexandre Oliva et. al. at the linux-libre lists[4], leading
Alexandre to implement one of the discussed solutions in the linux-libre
deblobber. Other solutions are possible, so this new thread should focus
on what is _enough_ to achieve a fully free kernel.

1:
http://lists.ourproject.org/pipermail/solar-general/2009-August/
http://www.fsfla.org/pipermail/discusion/2009-August/

2:
http://www.fsfla.org/svnwiki/selibre/linux-libre/#2009-03-21 - gen2 -
2.6.28-libre1 released at [[http://www.fsf.org/associate/meetings/2009/|
Libre Planet 2009]]

3:
http://www.gnu.org/philosophy/free-system-distribution-guidelines.html

4:
http://www.fsfla.org/pipermail/linux-libre/2009-January/thread.html

Re: [GNU-linux-libre] Additions to Software_blacklist

[Rubén Rodríguez Pérez]

El vie, 14-08-2009 a las 14:10 +0930, Karl Goetz escribió:
> Hi all,
> The following software seems to be removed from gNS but not listed on
> the shared wiki page [1]. Due to my fsf login /not/ working to let me
> in, I've been unable to add them to the page yet.

Thanks, I'll check this list in a while.
Some of this packages where added in the latest days, others where not
added as they are outdated. E. g. linuxsampler is not in the gNS
upstream, that might come from an earlier version of gNS.


> [1] http://groups.fsf.org/wiki/Software_blacklist
> 
> 
> == linuxsampler ==
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=328121
>  non-commercial
> 
> == isdnutils ==
>  This source package contains multiple binaries, of
> which isdnactivecards is one. Not sure if this is relevant - I can't
> find a gNS bug about why it was removed to start with.
> 
> == bind (8) ==
>  http://bugs.gnewsense.org/Bugs/00102
>  "...the statement “You only have the right to use it or distribute it
> as a bundled, integrated product.” makes DNSsafe non-free..."
> 
> == afio ==
>  http://bugs.gnewsense.org/Bugs/00234
>  (1) It may not be sold at a profit.
> 
> == fpc ==
>  https://bugs.launchpad.net/ubuntu/hardy/+source/fpc/+bug/275688
>  License issue
> 
> == rman ==
>  http://bugs.gnewsense.org/Bugs/00291
>  PolyglotMan (package rman) is distributed under the original Artistic
> License. According to the FSF this license is non-free
> 
> == cracklib2 ==
>  http://bugs.gnewsense.org/Bugs/00109
>  cracklib2 not free - the licence is "freely plagiarised from the
> 'Artistic Licence'"
> 
> == scribus-ng-doc ==
>  http://bugs.gnewsense.org/Bugs/00300
>  scribus-ng-doc contain non-free docs
> 
> == All virtual realities games ==
>  blobwars
>  starfighter
>  viruskiller
>  https://www.redhat.com/archives/fedora-games-list/2008-August/msg00027.html
> 
> kk.
> 

[GNU-linux-libre] License issues in the ivman and d4x packages

[Rubén Rodríguez Pérez]

Marcooliva reported yesterday about license issues in the packages d4x
and ivman. Both where removed from the Trisquel repositories, and we
suggest the other free distros to do the same.

http://groups.fsf.org/wiki/Software_blacklist updated

More info:

ivman:
https://bugzilla.redhat.com/show_bug.cgi?id=208737#c18

d4x:
Example: In d4x-2.5.7.1/main/ :
/* WebDownloader for X-Window
* Copyright (C) 1999-2002 Koshelev Maxim
* This Program is free but not GPL!!! You can't modify it
* without agreement with author. You can't distribute modified
* program but you can distribute unmodified program.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*/

[GNU-linux-libre] Re: kernel-libre-2.6.27.25-78.2.56.fc9 for freed-ora/F-9

[Rubén Rodríguez Pérez]

El dom, 26-07-2009 a las 18:57 +0100, Nick escribió:
> Quoth john maclean:
> > Is there such a thing as a libre hardware compatibility list? Would be
> > nice for chaps to be able to know that they have compliant hardware.
> 
> The FSF have a hardware compatibility list at 
> http://www.fsf.org/resources/hw
> 
> However massively incomplete. Perhaps a wiki format might be better, 
> to make contribution much easier?

I know of a good place for that: gnu-linux-libre pages at libreplanet's
wiki. You can find them here: http://freedsoftware.org

This wiki can be used for freedom related info for all GNU/Linux
distros, especially focused in the fully free ones.
I think that we can start a page listing links for resources like that
one, for later importing and extending them. What do you think?

[GNU-linux-libre] Non-free package found: pdftk

[Rubén Rodríguez]

Hi everyone,

We've just received the below included report about a non-free package in
the Trisquel repositories. The offending package was removed, and I
suggest the rest of free distros to do the same.

I'll add this package to the list at freedsoftware.org too.

Thank you marcooliva for the useful report.
Rubén


Issue status update for
http://trisquel.info/en/pdftk-files-sun-confidential-code
Post a follow up:
http://trisquel.info/en/comment/reply/1098#comment-form

 Project:  Trisquel
 Version:  3.0
 Component:Programs
 Category: bug report
 Priority: normal
 Assigned to:  Anónimo
 Status:   active
 Reported by:  marcooliva
 Updated by:   marcooliva

"
Description of problem:
The following files in the pdftk tarball:
com/lowagie/text/pdf/codec/postscript/PACommand.java
com/lowagie/text/pdf/codec/postscript/PAContext.java
com/lowagie/text/pdf/codec/postscript/PAEngine.java
com/lowagie/text/pdf/codec/postscript/PAPencil.java
com/lowagie/text/pdf/codec/postscript/PAToken.java
com/lowagie/text/pdf/codec/postscript/PainterException.java


(which originate in itext) contain code with the following copyright
header:
/*
 * Copyright 1998 by Sun Microsystems, Inc.,
 * 901 San Antonio Road, Palo Alto, California, 94303, U.S.A.
 * All rights reserved.
 *
 * This software is the confidential and proprietary information
 * of Sun Microsystems, Inc. ("Confidential Information"). You
 * shall not disclose such Confidential Information and shall use
 * it only in accordance with the terms of the license agreement
 * you entered into with Sun.
 */
"
-> https://bugzilla.redhat.com/show_bug.cgi?id=236310#c0 [1]


"
Correction: The files are all in the java_libs subdirectory, i.e.:
java_libs/com/lowagie/text/pdf/codec/postscript/PACommand.java
java_libs/com/lowagie/text/pdf/codec/postscript/PAContext.java
java_libs/com/lowagie/text/pdf/codec/postscript/PAEngine.java
java_libs/com/lowagie/text/pdf/codec/postscript/PAPencil.java
java_libs/com/lowagie/text/pdf/codec/postscript/PAToken.java
java_libs/com/lowagie/text/pdf/codec/postscript/PainterException.java
"
-> https://bugzilla.redhat.com/show_bug.cgi?id=236310#c1 [2]


->
http://archive.trisquel.info/trisquel/pool/extras/p/pdftk/pdftk_1.41.orig.tar.gz
[3]


-> https://bugs.launchpad.net/ubuntu/+source/pdftk/+bug/384515 [4]

[1] https://bugzilla.redhat.com/show_bug.cgi?id=236310#c0
[2] https://bugzilla.redhat.com/show_bug.cgi?id=236310#c1
[3]
http://archive.trisquel.info/trisquel/pool/extras/p/pdftk/pdftk_1.41.orig.tar.gz
[4] https://bugs.launchpad.net/ubuntu/+source/pdftk/+bug/384515

marcooliva

Re: [GNU-linux-libre] Re: any Free BSD variant?

[Rubén Rodríguez Pérez]

> I disagree.  This is what makes us a community.  The users have equal
> powers as developers.

For power level this is true: the more you do, the more you rule. But I
was talking about knowledge, more related with your words on usability
and what you said about the users not being dummies.

> A user who wants to learn more about
> the system than the average user

So you are not the average user, and also not a dummy :)

> > you compile your own emacs
> 
> Compiling Emacs and other packages is what users typically do.

See? That's where I think you are wrong with this. Compiling is for
advanced users, just a little tiny portion of the total. Most of the
users know nothing about computing science -the exact amount they want
to know-, and they expect the system to work with no effort.

> > and you are bothered about the lack of debugging symbols.
> 
> Sure I am, but this doesn't imply I'm a developer.  I think that a
> diligent user has to at least try to report every bug she encounters,

Your knowledge level is way above the average computer user. If you
design a distro thinking that every user is a hacker, only hackers
will use it. Including an easy way to report bugs is a good idea, but
everything should be automated and easy.

> I also use GDB as a learning tool [...] The distro should make such tinkering
> easy by default.

Yes, a good distro should include the best of the two worlds: a easy,
non frightening, modern OS that "just works", with all the required
hacking machinery underneath, so if a user -like you do- wants more, he
can learn all he wants. Both tasks are equally important.

> But we have a GNU system!  It was never the intention the GNU system
> to comprise only of GNU packages.  At the dawn of the project all
> efforts have been made to reuse existing free software.  Facts like
> rms' quest for a free compiler and the early decision to use large and
> important software like X and TeX speak in favor of this.

Then you need to explain what do you mean with "pure GNU". I thought
you where talking about just the GNU packages.

> My only conclusion is that Fedora is closer to a free system than
> Debian is.  Not yet there, surely.

That is nice, I didn't know.

> 
> > > This was just one (albeit central) point of my plan, and it's not
> > > something to be taken lightly.
> > 
> > I think that this is not a good idea.
> 
> I was expecting a comment like this.  As a GNUer, don't you want to
> improve the system?  I'd even say that everyone who appreciates the
> goals of the GNU project wishes it success, both on philosophical and
> technical level.

Of course I do, but the GNU packages are just a tool. The only matter
is the philosophical one. So, if a free program exists, then the
hackers should not waste their time by doing a GNU version, as there
are lots of more important tasks to do. They should work on GNU
versions of non-free programs instead.

> If you're brave enough to claim that GNU make is not the most popular
> and most powerful make implementation, let me know :-)  I'd by amused
> to argue just for the sport.  Yet, they include their own
> implementations, because of natural solidarity and the desire to
> improve their own system.  I guess their default shells are not Bash
> as well, etc.

In most cases, that solidarity is mostly filled with ego too. I don't
care much about a program being "ours" or not, as long as it is free.
As a distro maintainer, I choose GNU programs if they are equally good
as some other. If they are not, I have to provide the user with the
best alternative available. I.e. our distro ships with swfdec, as it
can show way more flash movies than gnash. The day gnash catches up, we
will replace swfdec. Our pride of GNU should not blind us.

> > There are lots of non-free software that needs a replacement, that's
> > a much more urgent issue.
> 
> I agree 100% with you.  It is more urgent and more important, too.
> 
> But that's a bit out of scope from the perspective of a distro
> maintainer.  The task of distro maintainers is to make the system more
> usable, more coherent and integrated for the benefit of its users.  A
> distro maintainer is a proxy for the user -- 

True, In this case, replacing a commonly used free app with a not
so known GNU package is a pointless effort anyway, even it the GNU app
already exists. Only if the free program is -despite of it's
popularity- doing the things wrong we should replace it. If the program
is fine, then we should stick to the standard, as it will simplify the
users adoption of our system.

Excluding or replacing a program for freedom shake is mandatory. Even
if it makes the distro harder for the user. But replacing a package
just because we like it better does not justify the extra hardness.

But of course this are just a general thought, your idea makes sense for
several packages anyway.

> the complex task of
> assembling the system is not anymore user's responsibility, like in
> the early days.

The same applie

Re: [GNU-linux-libre] Re: any Free BSD variant?

[Rubén Rodríguez Pérez]

> Thanks for the encouraging words.

I will add some skeptic ones.
I just want to be the "critical voice", to add points of view. So if I
sound a little harsh on you, that is not my intention :)

> 
> I think the list's name is misleading, because there are GNU systems
> based on other kernels

This list is just for _fully_free_ systems, and as by now there are only
GNU/Linux distros in the list, this name was proposed.
http://www.gnu.org/distros/free-distros.html


> in the
> free world there is no clear distinction between a developer and a
> user, and that's a good thing.

This is not true. And I think that it is a good thing like it is.
You are clearly a developer: you compile your own emacs and you are
bothered about the lack of debugging symbols. You are a hacker. And that
is great, but most users are not interested in becoming hackers, they
just want to read the paper, talk with their friends, caption some
cats... And this is also ok!

I like the idea of a free distro being a way for a user to become a
developer: include compilers, code, debuggers, doc... but as a
complement of a non-technical-user oriented system.

Being yourself a hacker is probably why you also think that GNU is an
usable system by itself. Sadly it is not, we need lots of external
programs to have a distro. The only way to have a GNU system, -and it
would be something like OpenBSD: simple, hard and small- is to write a
package manager and finish the HURD. And that would be a waste of time.



> The "open source" inertia is huge, and there's no way out of the
> current situation taking into account how the decision-making process
> in Debian is done.


Is true that Debian is not as free as we'd like, but they are the closer
we have, so I think we should take it easy with them, and try to help
their community. There are plenty of crappy distros full of non-free
stuff to criticize, and we always press harder on Debian.


> 
> > Basing on debian is a first step. I am not a developer but the
> > people who currently maintain gNewSense assured me that using debian
> > as a base will make gnewsense easily to maintain and upgrade.
> 
> Fully agreed.

And another reason to keep working with them.

> 
> > We should create a gnu community repository 

This is interesting. Something like the PPA system in Ubuntu, where
packages from trusted hackers can be easily added to the official repos.

> > 3) Start to apply what Waver Doganov has just proposed: switching
> > packages to the GNU alternative, one by one.
> 
> This was just one (albeit central) point of my plan, and it's not
> something to be taken lightly.

I think that this is not a good idea. If a program is free, then it
needs no replacement. Why should we replace, let's say. openssh -which
has become an standard- with a new and unsupported GNU app? 
There are lots of non-free software that needs a replacement, that's a
much more urgent issue.

And by the way, you cannot replace them all as I said previously.
Is there a point in replacing all but the kernel and the xserver?



___
gnu-linux-libre mailing list
gnu-linux-libre@nongnu.org
http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre

Re: [GNU-linux-libre] Thunderbird recommending non-free software

[Rubén Rodríguez Pérez]

> Maybe we should have someone doing a libre gnu thunderbird software just
> as there is a libre gnu firefox one.
> 

Yes, and also because the mozilla trademark policies say that you must
rename the package if you change it in certain ways. INAL, but this
changes might be in the border line for this.

http://www.mozilla.org/foundation/trademarks/policy.html



___
gnu-linux-libre mailing list
gnu-linux-libre@nongnu.org
http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre

[GNU-linux-libre] Thunderbird recommending non-free software

[Rubén Rodríguez Pérez]

I've realized that, as Firefox, Thunderbird points the users to
addons.mozilla.org for extensions, a site listing non-free software.
This must be avoided redirecting the users to a list of free add-ons.

This can be easily fixed by changing some default config chains:

$ cat /etc/thunderbird/pref/freedom-settings.js 
// Preferences for the Get Add-ons panel
pref ("extensions.getAddons.showPane", false);
pref ("extensions.getAddons.browseAddons",
"http://www.gnu.org/software/gnuzilla/addons.html";);
pref("extensions.getAddons.maxResults", 5);
pref ("extensions.getAddons.recommended.browseURL",
"http://www.gnu.org/software/gnuzilla/addons.html";);
pref ("extensions.getAddons.recommended.url",
"http://www.gnu.org/software/gnuzilla/addons.html";);
pref ("extensions.getAddons.search.browseURL",
"http://www.gnu.org/software/gnuzilla/addons.html";);
pref ("extensions.getAddons.search.url",
"http://www.gnu.org/software/gnuzilla/addons.html";);
pref ("extensions.getMoreExtensionsURL" ,
"http://www.gnu.org/software/gnuzilla/addons.html";);
pref ("extensions.getMorePluginsURL" ,
"http://www.gnu.org/software/gnuzilla/addons.html";);
pref ("extensions.getMoreThemesURL" ,
"http://www.gnu.org/software/gnuzilla/addons.html";);
// Dictionary download preference
pref("browser.dictionaries.download.url", "http://gnuzilla.gnu.org";);


I've take this configs from IceCat, which by the way still redirects you
to addons.mozilla.org in some cases -search engines and java plugin-.



___
gnu-linux-libre mailing list
gnu-linux-libre@nongnu.org
http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre

Re: [GNU-linux-libre] Re: any Free BSD variant?

[Rubén Rodríguez Pérez]

> I think it would be even easier on a technical level to create and keep
> updated a GNU OS distribution based on OpenBSD than a GNU OS based on
> Debian or Ubuntu 

Well, as you will be replacing almost the complete BSD userland with GNU
programs, is not that easy.

> (a) you wouldn't need to fight against blobs in the upstream repository,

There are almost no blobs in Debian anyway.

> (b) the entire distribution is in a single source code control repository,

That is not true if you replace the userland programs, you would need to
add them to the ports system.

> (c) "make world" works, and

GOTO B

> (d) the major thing we object to, the non-free software in ports, could
> be solved just by making a copy of the distribution without ports and
> with name changes in some places to avoid pointing at upstream nonfree
> repositories.

If that's it, you can simply copy the OpenBSD repo and remove the
offending ports, and you will have a fully free system. (And just not to
piss off Theo: I mean a system that does not contain non-free pieces nor
recommend them)

> Socially it might be tricky to form a collaborative relationship

> With regard to (d) ports, the most obvious solution would be to create a
>  derivative of OpenBSD ports without the nonfree software.

You would also need to change it's name and website, but as I said, you
would have a free but pointless OS: you need to do more than that if you
want to maintain a fully free distro. If you don't, the upstream hackers
would think that you are just "teaching them ethics" by doing a tiny
tech job at the expense of their huge own, therefor they won't help you.
That would SURELY be the case with OpenBSD.

> it would be pretty trivial to create a
> tool to generate a free version of the repository, and they have
> well-documented tools to create an automated compile farm.

I think that the point of all this -despite of the technical examples-
is the question: should we build up a fully free distro from scratch?

Taking a well maintained distro and cleaning it up is easy, almost all
the bugs will be fixed upstream. But, no matter how well you automate a
farm, it will never give you a usable distro if you don't put LOTS of
work on it. Even Ubuntu is using Debian as upstream for most of it's
"extra" packages, it needs 124 people [https://launchpad.net/~motu] to
watch out for every single package to work well. And all the main
packages are maintained by cannonical itself.


> 
> * djbclark: dachary: http://nixos.org/about.html and also there is a
> useful academic paper I'll get the URL for in a sec...

This is a very interesting package manager, but it still needs you to:

* Brand and tune up every package using diffs
* Make sure that every package works well with the others -and fix them
with more diffs-
* Pick up every package from the upstream project -checking regularly
for new releases, and watching out for regressions-

That is what a distribution is all about, taking care of every package
by hand. It cannot be automated -you cannot even download the new
version of every package that way-. It can be somewhat automated if you
just include the GNU packages, put the result would be incomplete.

> 
> * djbclark: What makes me nervous about gnewsense, trisquel at all is
> that we are in most cases just trusting that the available binaries are
> producible from certain sources (since they are just copied from
> upstream; I don't know what blag's situation is).

We can check if the binaries are really made from it's sources -that can
be automated easily- although it would be easy to just ask them about
the build logs or to let us take a look at the build farm... Anyway,
that would be pointless: you would still need to check every source
package by hand.

The only way you wouldn't need to trust anyone is to avoid having a
upstream. We can do a GNU/hurd system without Xorg, but even if that
would be a fun technical exercise, it would be useless.

Anyway... Why shouldn't we trust -let's say- Ubuntu about putting fake
source tarballs that doesn't match the binary results?



___
gnu-linux-libre mailing list
gnu-linux-libre@nongnu.org
http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre

Re: [GNU-linux-libre] Building recent linux-libre and icecat packages for more GNU/Linux distributions

[Rubén Rodríguez Pérez]

> I'm in the process of using the Ubuntu documentation to build a
> 2.6.28-libre for Trisquel amd64 based on Ubuntu 2.6.28 most recent
> tagged jaunty git + linux-libre 2.6.28 deblob - I'll also be building
> that for gNewSense to close the above-referenced ticket soon :-)

The Trisquel/gNewSense way: Add the upstream deb-src repo where you want
to get the kernel from, and then

apt-get source linux
apt-get --yes build-dep linux
[debblobing and customizing scripts]
dpkg-buildpackage -us -uc

Of course the deblobbing part is the tricky one, you need to apply the
matching deblob script from linux-libre, and then deblob-check the files
that ubuntu changes (you can list them from the patch file), usually by
adding some deblob routines from a newer deblob script -Ubuntu guys tend
to backport some drivers- and also adding the needed whitelist to the
script, to avoid false positives. Is not a fully scriptable process.



> 
> (2) For building linux-libre (and perhaps other pieces of freed
> software, like GNU IceCat) for more GNU/Linux distributions (most
> important I think are to have easy to install recent linux-libre
> packages for all of the Libre GNU/Linux platforms, but if it isn't much
> harder I don't think it's a mistake to also do for for the upstream
> distributions).

I think that this is the distro part of the job, there is no need to
provide a kernel for everyone if the deblob scripts are generic. It's
the same for other packages too: you don't know the specifics of every
distro, and they would want to customize the packages too.



___
gnu-linux-libre mailing list
gnu-linux-libre@nongnu.org
http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre

Re: [GNU-linux-libre] any Free BSD variant?

[Rubén Rodríguez Pérez]

El jue, 14-05-2009 a las 21:49 +0200, Giuseppe Scrivano escribió:
> Hi all,
> 
> is there any completely free BSD variant (or at least just the kernel)?


OpenBSD does not contain binary blobs, and all the code they publish is
free software, but some ports are "contrib" -in debianese-, as they are
free scripts to install non free programs, which is not good.



___
gnu-linux-libre mailing list
gnu-linux-libre@nongnu.org
http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre

Re: [GNU-linux-libre] List of blacklisted packages

[Rubén Rodríguez Pérez]

> I think it will would be better if the order of the packages is alphabetical. 
>  Another thing is that we can use the "program name" or the "source name" 
> instead of "package name" (of a specific distribution).  This would be more 
> general, anyhow, be can put a reference about the package name for a specific 
> distribution.

I'll try to save some time tomorrow to improve it a little.
We should include references to the program site, replacements, etc.

And of course, we need to add more packages! I'm sure that we (as units)
are not aware of all the packages to avoid.



___
gnu-linux-libre mailing list
gnu-linux-libre@nongnu.org
http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre

[GNU-linux-libre] List of blacklisted packages

[Rubén Rodríguez Pérez]

I've included a initial list of blacklisted programs at
http://groups.fsf.org/index.php/Software_blacklist

It's just a work in progress, please add your packages and descriptions.
And feel free to discuss any package that doesn't match your policies.
Some packages may also need a review, please go ahead!

Ruben



___
gnu-linux-libre mailing list
gnu-linux-libre@nongnu.org
http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre

Re: [GNU-linux-libre] naming the Linux-libre artwork

[Rubén Rodríguez Pérez]

> Heh.
> 
> I kind of like Freetz, but I can't say I'm in love with it.
> 
> It's one syllable, it has 'Free' in the name; it's a bit ironic in that
> Linus wanted Linux to have been named Freax, it does sound like a pet
> name, but it's hardly perfect.
> 
> I guess we'll always be open to suggestions, at least until one name
> sticks :-)
> 
> How about this: whoever comes up with a name for, erhm, the penguin
> currently-named Freetz gets a Free license to run, modify and distribute
> Linux-libre! ;-)

I've made some improvements to my svg version of... Freetz, by now ;)
<>___
gnu-linux-libre mailing list
gnu-linux-libre@nongnu.org
http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre

Re: [GNU-linux-libre] naming the Linux-libre artwork

[Rubén Rodríguez Pérez]

> Yes, the last one is funny and I agree that Freetz could be an
> interesting official mascot.

And also the name Stux is a good pun for refering to the regular blobbed
tux, but I don't like it if you apply to linux-libre mascots.

I vote for the penguin in the shower, but I don't love Freetz as a name
(we can give him a guitar, though).



___
gnu-linux-libre mailing list
gnu-linux-libre@nongnu.org
http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre

Re: [GNU-linux-libre] Job to be done: list of non-free components

[Rubén Rodríguez Pérez]

El lun, 30-03-2009 a las 13:28 +0200, Jose E. Marchesi escribió:
> > I'd like to propose a task for this group: we need a list of all the
> > non-free bits that we are currently excluding from our distros. Some of
> > them might be well known, but I'm sure we will find others that are not.
> >
> > We need a wiki to accomplish this, that can be hosted in the FSF servers
> > (any wiki software would do). Can the sysadmins set this up? Thanks!
> 
> Since that data is likely going to be accessed in an automatic way (using
> scripts or programs) I would suggest to use some kind of
> easy-to-parse-and-maintain text files, stored in a CVS or any other
> revision control system.

I like the idea, but it has some downsides (including being a little
harder to do, and we are just starting to work together): Some packages
receive different names from one distro to another, and for some cases,
the packages are not totally removed but just deblobbed. That job is
usually different for every version of the package, so manual work is
almost always needed.

I think that for a start we can document the list of well known
problematic packages (with explanations, references and replacements),
and if this job takes us to somewhere, we can think of this idea again.



___
gnu-linux-libre mailing list
gnu-linux-libre@nongnu.org
http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre

[GNU-linux-libre] New wiki and url

[Rubén Rodríguez Pérez]

Hi,

Today Daniel Clark kindly set up the domain http://freedsoftware.org  to
point to a new wiki page at FSF Groups which you can also reach at
http://groups.fsf.org/index.php/FreedSoftware

I'm starting to write on it, but you can join me if you like, by adding
your info to the hackers list. We should get this cracking, so as a
start I will list the packages we are currently excluding from Trisquel,
and it would be great if you add your own list of packages and reasons.

Happy hacking!
Rubén

PS: Thank you, Daniel!



___
gnu-linux-libre mailing list
gnu-linux-libre@nongnu.org
http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre

[GNU-linux-libre] Job to be done: list of non-free components

[Rubén Rodríguez Pérez]

Hi,

I'd like to propose a task for this group: we need a list of all the
non-free bits that we are currently excluding from our distros. Some of
them might be well known, but I'm sure we will find others that are not.

We need a wiki to accomplish this, that can be hosted in the FSF servers
(any wiki software would do). Can the sysadmins set this up? Thanks!

This list can be the foundation to later write some other useful
documents, as a compilation of free software replacements for this
pieces, or free supported hardware recommendations. Some of this
information can be found in our own distros documentation or the GNU
website among others, but it needs to be updated and centralized.

Yours,
-- 
Rubén Rodríguez Pérez
GNU España
http://es.gnu.org/~ruben



___
gnu-linux-libre mailing list
gnu-linux-libre@nongnu.org
http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre

[GNU-linux-libre] New free distro: Dragora

[Rubén Rodríguez Pérez]

Hello everyone,

As you may already know, we have a new member in our family: the
Argentinian distribution Dragora GNU/Linux. I've invited the project
admin, Matías A. Fonzo to join our group. Welcome, Matías!

-- 
Rubén Rodríguez Pérez
GNU España
http://es.gnu.org/~ruben



___
gnu-linux-libre mailing list
gnu-linux-libre@nongnu.org
http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre

[GNU-linux-libre] Introducing

[Rubén Rodríguez Pérez]

Hi, may I start?

I'm Rubén Rodríguez, a 26 year old hacker from Spain, founder and
current leader of the Trisquel GNU/Linux project, a fully free distro
born in 2004, with educational, enterprise and home user editions.

I'm also a GNU Spain contributor, and I work in a free software
development company of my own.

Welcome everybody!
Ruben

PS: I will be managing this list, so ask me if you need help.



___
Gnu-linux-libre mailing list
Gnu-linux-libre@nongnu.org
http://lists.nongnu.org/mailman/listinfo/gnu-linux-libre