gmane.linux.distributions.gnu-linux-libre

Re: [gnu.org #787981] VENENUX

Karl Goetz — 2013-04-21T07:16:03


Their repositories are now browsable at least (wasn't shortly after the email arrived the first time)
http://venenux.net/repositorio 

I don't have any tools with me atm to be able to confirm if the repos contain proprietary code or not.
thanks,
kk

Re: RFCs and FSDG

Dmitry Samoyloff — 2013-04-08T14:19:56

Karl, Sam -- thanks for the help!

Re: RFCs and FSDG

Sam Geeraerts — 2013-04-05T20:13:33

Op Thu, 4 Apr 2013 22:45:12 GMT
schreef karl-OHxTiG4qnN609vOPjlrUmA< at >public.gmane.org (Karl Berry):


I interpret that license for the text the same way.


I remember from looking at the SHA-1 bug [1] that at least the code
in recent RFC's is often permissively licensed, so at least we have
that.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643703

Re: RFCs and FSDG

Karl Berry — 2013-04-04T22:45:12

    Are they OK or not for a free software distro in the FSF sense?

To my knowledge, it has always been the analysis that RFC's and similar
(C standards, POSIX standards, W3C standards, just about any kind of
official standard) are not ok for free distros.  Because they are
"information for practical use" (term from
http://www.gnu.org/distros/free-system-distribution-guidelines.html) but
they do not typically allow modification, just verbatim redistribution.

John, Donald, anyone, am I wrong?  (I hope so.)

Which leaves many free software packages (not just distros) in the
position of implementing standards which they are not allowed to
distribute.  Bizarre and unwelcome IMHO, but that seems to be the
consequence.

karl

RFCs and FSDG

Dmitry Samoyloff — 2013-04-03T21:46:28

Hi,

There are 3 documents that were removed from the Debian and its
derivatives.

  From libtheora:

1) http://svn.xiph.org/trunk/theora/doc/draft-ietf-avt-rtp-theora-00.txt

  From libogg:

2) http://www.ietf.org/rfc/rfc3533.txt
3) http://www.rfc-editor.org/rfc/rfc5334.txt

For that reason, they are also absent both in gNewSense and
Trisquel. I'm working on LibreWrt 2 currently and I wonder how much
non-free are those texts? Are they not good for FSDG distros too?

The number 2's copyright statement seems contradictory to me but it's
probably my bad English:

  This document and translations of it may be copied and furnished to
  others, and derivative works that comment on or otherwise explain it
  or assist in its implementation may be prepared, copied, published
  and distributed, in whole or in part, without restriction of any
  kind, provided that the above copyright notice and this paragraph
  are included on all such copies and derivative works.  However, this
  document itself may not be modified i

Re: ffmpeg LICENSE file

Dmitry Samoyloff — 2013-04-03T08:54:20

Thanks!

Re: ffmpeg LICENSE file

Karl Berry — 2013-04-01T21:42:59

     "The nonfree external library libfaac can be hooked up in FFmpeg. You need
      to pass --enable-nonfree to configure to enable it. Employ this option
      with care as FFmpeg then becomes nonfree and unredistributable."

FWIW, I think it's ok.  My $0.0001.

k

ffmpeg LICENSE file

Dmitry Samoyloff — 2013-04-01T16:01:29

Hi,

There's the following paragraph in the ffmpeg's LICENSE file:

 "The nonfree external library libfaac can be hooked up in FFmpeg. You need
  to pass --enable-nonfree to configure to enable it. Employ this option
  with care as FFmpeg then becomes nonfree and unredistributable."

Applying the FSDG, does it fall under:

 "What would be unacceptable is for the documentation to give people
  instructions for installing a nonfree program on the system, or mention
  conveniences they might gain by doing so."

or under:

 "For a borderline case, a clear and serious exhortation not to use the
  nonfree program would move it to the acceptable side of the line."

?

Re: [gnu.org #787981] VENENUX

hellekin (GNU/consensus — 2013-03-18T15:48:15

*** (sorry: wrong Cc. Corrected)

Hello,

it appears that there's no obvious link to the source repositories. I'm
not talking of the binary, nor even the source packages, but to the
developer repositories.

Moreover, it appears that some packages (Chromium, Nvidia...) might
contain non-free code. Our webmaster-in-chief suggested the distro
should go through the verification process again, which is why I'm
CC-ing the gnu-linux-libre mailing-list.

Meanwhile, can you provide the correct links to the developer repositories?

Regards,

==
hk

Re: Facilitating payments/contributions to developers

Matias A. Fonzo — 2013-01-24T19:23:42

El Thu, 24 Jan 2013 15:47:23 +1100
Karl Goetz <karl-gjSFtu7vIzwXC2x5gXVKYQ< at >public.gmane.org> escribió:

Is not this the "economy"?. :-)
 

Maybe yes, maybe not...

What about in helping (projects) to organize a fundraising campaign like
MediaGoblin?.

Re: Facilitating payments/contributionstodevelopers

Karl Goetz — 2013-01-24T04:50:34


i like the sound of this as a first sttep - it should be much easier to do then full blown libraries to support doing this in every app.


having a client side program wold be nice but will introduce maintenance issues. Pointing people to a website by a link or wrapper seems like a good first step to me.
Thanks,
kk

Re: Facilitating payments/contributionstodevelopers

Karl Goetz — 2013-01-24T04:47:23



The problem with having a donations bucket is how it gets distributed, specifically in deciding who gets what money.

On a personal note i'd be dubious if this extra fee cane along and i imagine many fsf members are not interested in paying a distro maintenance 'levy'
Thanks,
kk

Re: Facilitating payments/contributions todevelopers

John Sullivan — 2013-01-16T15:26:25


I do have this in mind, as part of our program at
<https://my.fsf.org/donate/directed-donations/working-together>, we will
ask FSF members whether they want to contribute some additional money to
some specific areas.

It is also possible that free distros could become a part of this
program now, as we expand it.

-john

Re: Facilitating payments/contributions to developers

Jaromil — 2013-01-16T09:26:57


somehow yes and I'm glad something is moving in that direction.

however, what John talks about here is slightly different and also
matching an old discussion InI have with big distributions like Debian:
to give correct credit to "upstream", for instance a link to their
webpage (which is there since not so long..) and a mention on the
package, to say the least, as a possibility to direct people to their
donation page.

often such a discussion resulted in a simple conclusion: single software
packages have an "about" screen or menu item or link on commandline that
direct to their page, that's their occasion to advertise to the users
what are the ways to support developers.

this does makes sense, but I still think that a webpage listing url
links and names of "upstream" is useful since that is online and gets
indexed by search engines and visited with a browser. furthermore, such
a list (which could be an outsources service by the Free Software
Directory itself, somehow?) *should* be advertised on the donati

Re: Facilitating payments/contributions to developers

Matias A. Fonzo — 2013-01-16T06:33:10

Hi all,

El Tue, 15 Jan 2013 21:42:39 -0500
John Sullivan <johns-dGWS0fDw8IM< at >public.gmane.org> escribió:

The idea is really good. And that would be better if we can get support
too. In my case I have 5 years developing Dragora with an immense
effort and sacrifice, working every day. In these years only a few
persons have donated to the project (http://dragora.org/en/donate.html
see below). Right now, I am developing a new version at
http://git.savannah.gnu.org/cgit/dragora.git


Perhaps two dollars (more) can be requested from an associate member of
the Free Software Foundation. Even the option may be present, as
optional.

Re: Facilitating payments/contributions to developers

Nicolás Reynolds — 2013-01-16T03:40:38

El 15/01/13 09:42, John Sullivan dijo:

This is related to Jaromil's thread about adbard and a general question about
sustaining libre distributions, no?

BTW at Parabola we've been offered to split ad revenue with duckduckgo.com but
only for the nonfree javascript version :P

Re: Facilitating payments/contributions todevelopers

Matt Lee — 2013-01-16T03:31:36

My idea for how it would be done...

A single app is created called "pay-authors" and it could be called by
any program...

"pay-authors emacs"

It would look like this: http://i.imgur.com/Th3hK.png and could be an
embedded web page, ie. https://secure.fsf.org/pay/emacs or embedded in
the app.

* Any app could support it by just linking to the page, or by calling
the app in their program
* Any program like Synaptic could support it in a similar way.
* The project website could support it by linking to it.

Maybe the program is not needed.

Facilitating payments/contributions to developers

John Sullivan — 2013-01-16T02:42:39

It would be nice if free distributions could support giving donations to
the authors of their packages. 

The FSF could help with the backend of this (handling the money, etc),
but code is needed for the frontend, which somehow tastefully and
usefully presents users with this option, perhaps as part of the
installation process.

Ubuntu is doing something like this, where users can choose areas they
want to see improved and give a corresponding contribution.

Any thoughts about how this could be done, or know about any other
places where it's already being done?

Re: Reducing firmware loading timeout

2013-01-14T08:35:47

The problem is that there are some firmware for which source code is
free, for instance, carl9170 firmware source code is under GPLv2 or
later (http://wireless.kernel.org/en/users/Drivers/carl9170.fw).

Re: Reducing firmware loading timeout

Karl Goetz — 2013-01-09T11:34:44


If only proprietory firmware exists the deblob scripts should be disabling the load attempts too.

Thanks,
kk

Reducing firmware loading timeout

2013-01-09T09:25:48

Dear freedom lovers,

I am trying to build a kernel image for Loongson 3A and suitable for
gNewSense (and potentially every GNU/linux-libre distribution intended
to run on Loongson 3A).

I used the kernel 3.5 modified by Lemote [1] as a base. Then, I ran
the deblob-3.5 script [2] locally. The machine I use for testing uses
the radeon video driver which loads a binary blob on vanilla
kernel. By default, the firmware loading timeout is 60 seconds and,
because the binary firmware has been removed after running the deblob
script, the deblobbed kernel waits 60 seconds for nothing at boot:
beside nothing is printed on the display during that time, this is a
serious time penalty.

In order to boot faster, it is possible to change the value of the
variable loading_timeout from the kernel file
drivers/base/firmware_class.c to something lower than 60, say 5:

    static int loading_timeout = 60;        /* In seconds */

becomes:

    static int loading_timeout = 5;        /* In seconds */

This change works as expecte