FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 05-22-2008, 02:27 PM
Christian Iseli
 
Default Plan for tomorrows (20080522) FESCO meeting

On Thu, 22 May 2008 06:55:58 -0300, Alexandre Oliva wrote:
> Here's the proposed feature I've just drafted up:
> http://fedoraproject.org/wiki/Features/FedoraFreedom

/me rambles a bit...

Unless I'm mistaken, I assume such a libre system will run on ix86 and
x86_64 machines. As far as I understand, nobody has a GPL'd version of
those processors, nor a choice to hack on their "source" code and
distribute changes...

There is no real distinction between what is hardware
and what is software. It is more like a continuum between the two,
and firmware, as its name implies, lies somewhere between hard- and
soft-ware.

To make a long story short, we need to draw a line somewhere between
where we require GPL'd source code, and where we do not. That line is
defined in
http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#BinaryFirmware

I think it is a laudable goal to move that line as close to having
GPL'd hardware as possible, but as others have mentioned, I think this
means working with upstream kernel to get to a point where you feel
you have all the liberty you expect from the kernel in Fedora.

CHF 0.02...

Cheers,
Christian

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 02:42 PM
David Woodhouse
 
Default Plan for tomorrows (20080522) FESCO meeting

On Thu, 2008-05-22 at 16:27 +0200, Christian Iseli wrote:
> /me rambles a bit...
>
> Unless I'm mistaken, I assume such a libre system will run on ix86 and
> x86_64 machines.

I assume Alex won't be including an interpreter for closed-source ACPI
bytecode in his kernel. So it's likely to have problems on a lot of i386
and x86_64 machines. Should be OK on PPC though

--
dwmw2

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 03:53 PM
"Jeff Spaleta"
 
Default Plan for tomorrows (20080522) FESCO meeting

On Thu, May 22, 2008 at 6:42 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> I assume Alex won't be including an interpreter for closed-source ACPI
> bytecode in his kernel. So it's likely to have problems on a lot of i386
> and x86_64 machines. Should be OK on PPC though

It would however be fascinating to see how many machines fall over and
die in the attempt. I like your action plan concerning the firmware
conversion, but what the hell do i know. If your plan ever makes it
to an upstream technical discussion, I want to make sure I know about
so I can read along.

-jef

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 04:10 PM
Toshio Kuratomi
 
Default Plan for tomorrows (20080522) FESCO meeting

Alexandre Oliva wrote:

On May 21, 2008, Toshio Kuratomi <a.badger@gmail.com> wrote:



There's free software as in legally licensed for us to use distribute
and modify and there's free software as in four freedoms free. Unless
I've missed something, the firmware in the kernel is licensed under
the GPLv2 and therefore it is legally licensed for us to use,
distribute, and modify.


I'm sorry to be the bearer of bad news, but you did indeed miss
something.

Have a look at the license for drivers/net/tokenring/3c359_microcode.h

2 /*
3 * The firmware this driver downloads into the tokenring card is a
4 * separate program and is not GPL'd source code, even though the Linux
5 * side driver and the routine that loads this data into the card are.
6 *
7 * This firmware is licensed to you strictly for use in conjunction
8 * with the use of 3Com 3C359 TokenRing adapters. There is no
9 * waranty expressed or implied about its fitness for any purpose.
10 */


This is just one out of some 30 examples of such licenses in the
kernel. And, heck, this one doesn't even grant permission for
redistribution. What are those Linux-no-libre guys thinking?

Thanks! The Packaging Committee and kernel maintainers will have to
look into what's going on here. Although that doesn't address your
larger issue of binary firmware.


-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 04:47 PM
Alan Cox
 
Default Plan for tomorrows (20080522) FESCO meeting

On Thu, May 22, 2008 at 02:18:22AM -0300, Alexandre Oliva wrote:
> kernel. And, heck, this one doesn't even grant permission for
> redistribution. What are those Linux-no-libre guys thinking?

Well we were thinking (and much legal advice seems to agree) that the firmware
is a separate work. Like your BIOS for example.

We had been gradually moving firmware to user space via request_firmware until
various free software extremists made such idiots of themselves on the kernel
list a couple of years ago everyone stopped because they were so p***ed off
with them.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 05:08 PM
Alexandre Oliva
 
Default Plan for tomorrows (20080522) FESCO meeting

On May 22, 2008, Christian Iseli <Christian.Iseli@unil.ch> wrote:

> As far as I understand, nobody has a GPL'd version of those
> processors,

AFAICT, you're one of those who believe that "Free Software" means
"GPL". No, sir. GPL is just the most common out of the very many
Free Software licenses that exist. I'm not going for GPL. I'm going
for "respect for the 4 freedoms", as per the Free Software Definition.
Bringing the GPL into the debate is completely misplaced.

Your other mistake is to assume that this has anything to do with what
users had on their computers before installing Fedora, or whatever
they choose to install after installing Fedora, for that matter. It
doesn't. It's about what *we* distribute under the label Fedora.
Nothing but it.

IOW, any attempts to point at other sources of problems are just
distractions, because we don't distribute these other sources of
problems. I don't object to our enabling people to live with them, as
long as we don't participate in the process of distributing them,
because is not just neutral to our mission, it's detrimental to it.

--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member íSÚ Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 05:13 PM
Alexandre Oliva
 
Default Plan for tomorrows (20080522) FESCO meeting

On May 22, 2008, David Woodhouse <dwmw2@infradead.org> wrote:

> On Thu, 2008-05-22 at 16:27 +0200, Christian Iseli wrote:
>> /me rambles a bit...
>>
>> Unless I'm mistaken, I assume such a libre system will run on ix86 and
>> x86_64 machines.

> I assume Alex won't be including an interpreter for closed-source ACPI
> bytecode in his kernel.

Is this an intentional strawman, or do you really not get the point?

Why wouldn't I? There's nothing offensive or immoral about the
interpreter, AFAIK.

What is offensive and immoral is the imposition of restrictions on the
bytecode that enables one's machine to work. But the interpreter
itself can't tell whether it's offensive or immoral, since it doesn't
have brains to understand technical and legal restrictions that the
bytecode itself or its corresponding source code might be subject to.

--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member íSÚ Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 05:48 PM
David Woodhouse
 
Default Plan for tomorrows (20080522) FESCO meeting

On Thu, 2008-05-22 at 12:47 -0400, Alan Cox wrote:
> On Thu, May 22, 2008 at 02:18:22AM -0300, Alexandre Oliva wrote:
> > kernel. And, heck, this one doesn't even grant permission for
> > redistribution. What are those Linux-no-libre guys thinking?
>
> Well we were thinking (and much legal advice seems to agree) that the firmware
> is a separate work. Like your BIOS for example.

Being a separate work doesn't save it from the requirements of the GPL.

The GPL clearly states that under some circumstances it _does_ extend to
sections which are independent and separate works in themselves.

And it seems fairly clear to me that those circumstances include the
firmware blobs included in the Linux kernel tarball.

If identifiable sections of that work are not derived from the
Program, and can be reasonably considered independent and
separate works in themselves, then this License, and its terms,
do not apply to those sections when you distribute them as
separate works.

(OK, that's the firmware).

But when you distribute the same sections as part of a whole
which is a work based on the Program, the distribution of the
whole must be on the terms of this License, whose permissions
for other licensees extend to the entire whole, and thus to each
and every part regardless of who wrote it.

(as is that).


--
dwmw2

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 05:53 PM
Alexandre Oliva
 
Default Plan for tomorrows (20080522) FESCO meeting

On May 22, 2008, Josh Boyer <jwboyer@gmail.com> wrote:

> On Thu, 22 May 2008 01:58:25 -0300
> Alexandre Oliva <aoliva@redhat.com> wrote:

>> > Can you point me to where you've approached the upstream kernel
>> > maintainers about this?
>>
>> I haven't. I'm told others have, and have been ridiculed. From what
>> I gather from the LKML archives and personal experiences there, I have
>> no reason to disbelieve them.

> Ok, but you said you had facts. Now you're telling me you only have
> hearsay?

As in, what's in the archives, including my personal experiences on
LKML, are hearsay? I don't think so.

>> Because upstream doesn't want to achieve this goal, and actively
>> refuses to accept changes essential to get there.

> Pointers to this would be nice. Mailing list archives, IRC
> conversations, anything.

I don't have any such pointers handy, save for the related discussions
that you'll find with a web search for "LKML remove firmware or blob".

>> > If those patches get integrated, then wouldn't the parts you find
>> > objectionable be gone?

>> Not all of them, no.

> ?

Sorry. I was so much in a mindset of "there's no way upstream is
going to accept this" that I focused only on the second half of your
question, completely missing the antecedent that conflicted with my
mindset and that would have made the answer 'yes'.

So, I take back the above. Given the antecedent, the answer would be
'yes'. I just don't see that happening. I guess it may be worth a
shot, though.

>> > I certainly didn't think you intended to _replace_ the main kernel
>> > package. But I don't agree with even providing a completely different
>> > alternative "kernel-libre" package. If it can't be built as a flavor
>> > of the existing kernel package, then I don't see it being approved for
>> > inclusion.

>> So much for http://www.linux-books.us/fedora_core_0001.php

> So much for having a productive conversation. You're avoiding my point
> (or think it's entirely hopeless) and spewing rhetoric again.

I thought the acceptance of all patches upstream was entirely
hopeless. However, DWMW2's suggestion today might work, although I
still don't quite understand its details.

I wasn't trying to avoid your point. My response was an allusion to
what I perceive as an inconsistency between Fedora's long-ago stated
goal (build an entire operating system out of free and open source
software) and the preference for following an upstream that (through
their actions) oppose this goal, rather than giving precedence to the
stated goal and switching to another upstream that is compatible with
the goal.

--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member íSÚ Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 06:00 PM
Alexandre Oliva
 
Default Plan for tomorrows (20080522) FESCO meeting

On May 22, 2008, Toshio Kuratomi <a.badger@gmail.com> wrote:

> Thanks! The Packaging Committee and kernel maintainers will have to
> look into what's going on here. Although that doesn't address your
> larger issue of binary firmware.

Indeed, it doesn't. I don't think there are very many of these
firmwares that are licensed in such obnoxious terms. But it's
certainly not the only example of this kind of problem.

The nouveau-drm patches that we're adding ourselves contain relatively
large chunks of "voodoo" [sic] code copied from non-Free drivers by
means of mmio dumps, but no copyright notices or licensing associated
specifically to those pieces of code. As much as I appreciate what
these folks are doing, I'm not sure this approach is ethical, let
alone legal. I don't know whether this has been run through legal,
but if it hasn't, I suggest that it be.

--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member íSÚ Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 01:25 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ę2007 - 2008, www.linux-archive.org