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 06-18-2008, 10:31 PM
Alexandre Oliva
 
Default Fedora Freedom and linux-libre

On Jun 18, 2008, Anders Karlsson <anders@trudheim.co.uk> wrote:

> * Alexandre Oliva <aoliva@redhat.com> [20080618 21:50]:
>> On Jun 16, 2008, Hans de Goede <j.w.r.degoede@hhs.nl> wrote:
> [snip]
>> > Not being able to ever change the firmware is good,
>>
>> It's not. Being Free to change it would undoubtedly be better.

> So what's stopping you?

Lack of information.

> Go buy the programming manual for the chip,

It's not available.

> or discuss with the chip manufacturer to get the specs

They don't want to provide them.

> as there may not be a programming manual along the line what you
> find with say an Intel CPU.

There is, but they choose to keep it to themselves.

> As the firmware may be written from scratch in hex, that may be your
> *only* option.

That's fine, as long as the firmware *is* written from scratch in hex.
If not, the vendors are artificially and unethically depriving me of
information.

--
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 06-18-2008, 10:33 PM
Alexandre Oliva
 
Default Fedora Freedom and linux-libre

On Jun 18, 2008, Matthew Saltzman <mjs@clemson.edu> wrote:

> On Wed, 2008-06-18 at 14:54 -0300, Alexandre Oliva wrote:
>> On Jun 16, 2008, Les Mikesell <lesmikesell@gmail.com> wrote:
>>
>> > I've explained that the GPL prevents me from sharing original work
>> > that links to both GPL and non-GPL libraries.
>>
>> And I've explained that it doesn't, and asked you to cite the passage
>> of the GPL that prevents you from doing it. You haven't bothered to
>> do it, and instead decided to keep insisting in this nonsensical
>> claim. Please stop spreading lies. We're past the point in which you
>> could claim ignorance as to this point.

> Wait--Alexandre, are you saying that I could take a GPL library and,
> say, a CPL[1] library, write a program that links to both libraries to
> create new functionality and legally distribute source code or a
> statically or dynamically linked executable version of my program
> licensed under either the GPL or the CPL?

No. I'm just saying that it's not the GPL that prevents you from
distributing it. It's copyright law. The GPL merely refrains from
granting permission for you to do something that, without such
permission from copyright holders, you can't do in the first place.

--
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 06-18-2008, 10:38 PM
Les Mikesell
 
Default Fedora Freedom and linux-libre

Alexandre Oliva wrote:



Let's assume that I have obtained my copy of several components under
any license but the GPL, and so have a lot of other people.


Still missing the point. Don't assuming you have a license that says
other things.


I don't have to assume. I have other licenses. Only the GPL applies
its restrictions to the 'work as a whole' instead of just itself. You
are the one assuming that there might be something even more restrictive
than the GPL and using that to excuse its harmful restrictions.



The way to tell whether the GPL prohibits you from doing anything is
comparing what you can do once you accept the GPL with what you could
do before you accepted it.


With any other license, I could at least have done a diff against
the original copies and my work and given that away


As long as your original work is not a derived work. If it is, you
still need permission from the copyright holders of the original work,
to both create your derived work and to distribute the
collective/derived work.


No one but the FSF claims that a patch is a derived work - or a separate
component that links 2 others together but doesn't contain a copy of the
others.



This doesn't happen with any license but the GPL.


Sorry, I don't know how you came to this conclusion, but it's
incorrect.

Try to create a derived work based on say Microsoft Windows or
Microsoft Word, if you happen to have them around, and to distribute
it, and see what happens.


I'm not sure what you are talking about. It's a pretty safe bet that
there is more code that relies on Microsoft libraries than anything else
and Microsoft does not try to stop people from distributing it. If
anything, they encourage it by making a lot of tools and libraries
available.



This would be a prohibition of the GPL.



Yes, in case it wasn't clear before, the specific prohibition that I
consider unethical is that it takes away my choice to share my own
work.


It doesn't. Your own original work can't possibly be a derived work.


Difference of opinion, I guess. The FSF says otherwise and that if the
resulting 'work as a whole' would be be a derived work, then the
components, including my own work, can't be distributed unless all are
restricted by the GPL.



It does not grant you permission to distribute joint works you created
by deriving works from others' works in certain ways, so the
prohibition from copyright law remains in place. See, you didn't have
that choice in the first place for the GPL to take away. That's the
fundamental point that you're missing.


I'm not missing anything. I have my copy of a library, you have your
copy. Without the GPL, I can give you a copy of my original work that
links to that library without imposing the GPL restrictions on it and
any other related components. With the GPL, I can't. And the same
applies even if we both have source and I have made a patch.


--
Les Mikesell
lesmikesell@gmail.com



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-18-2008, 10:41 PM
Alexandre Oliva
 
Default Fedora Freedom and linux-libre

On Jun 18, 2008, Les Mikesell <lesmikesell@gmail.com> wrote:

> I could have redistributed the combination if I had started with the
> original pdtar instead of gnutar.

pdtar was presumably under the public domain, i.e., copyright law
didn't restrict its use.

If you'd started with any other derived version of pdtar that wasn't
in the public domain, or even one that was but that wasn't Free
because you didn't have access to the source code, you'd need
permission/help from the copyright/source holders of that particular
version you started out from in order to be able to create the
combined work and distribute it.

> There is no reasonable interpretation that anything but the GPL
> restrictions applied along with the changes between the pdtar and
> gnutar versions restricted distribution of my subsequent modification
> of the gnutar code.

Not GPL. There isn't any part of the GPL that says you can't do it.
Look for it and, if you find it, quote it here.

What stops you from doing it is not the GPL. It's copyright law. Go
figure.

> Of course I was mistaken at the time in thinking that GPL'd code was
> suitable for re-use and sharing and know better now.

http://fsfla.org/svnwiki/blogs/lxo/draft/forking-and-license-patching

--
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 06-18-2008, 10:42 PM
Rahul Sundaram
 
Default Fedora Freedom and linux-libre

Alexandre Oliva wrote:

On Jun 18, 2008, Rahul Sundaram <sundaram@fedoraproject.org> wrote:


Not all game maps are purely non functional data for example.


That's fine. The exception is not for game maps. It's for
non-functional data.


Sure but that was a specific example provided within the guidelines and
the guidelines should reflect this better. I have already send more
information which the FSF agrees with and is working on updating the
guidelines so I won't be repeating everything here and arguing with you
anymore.


Rahul

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-18-2008, 10:57 PM
Alexandre Oliva
 
Default Fedora Freedom and linux-libre

On Jun 18, 2008, Les Mikesell <lesmikesell@gmail.com> wrote:

> Alexandre Oliva wrote:
>> I agree that the GPL doesn't grant permission for the distribution of
>> such derived works under terms others than those specified in the GPL.

> OK, then the relevant question becomes whether the kernel or the
> firmware is a derived work, not whether they are distributed together
> or not.

Except that the GPL's exception distinguishes the cases in which they
are distributed together and not. So, no, we can't make this
simplification you suggested.

>>> And the GPL's 'work as a whole' concept
>>
>> I don't know what you're talking about. "work as a whole" appears
>> only once in the license, and there 'work' is not a verb, but rather
>> part of the "modified work" phrase.

> Once is enough - and it is the definitive requirement:

Sorry, I misunderstood what you wrote. As it's probably clear from my
response, it looked like you'd written 'works'. My fault.


> "These requirements apply to the modified work as a whole. 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."

> The question is, does taking some code and an opaque binary blob and
> sticking them in the same file make a 'work as a whole' or is it
> identifiable sections of code and separate data that are not derived
> from the Program?

This only matters if you distribute them as separate works. When you
distribute them as a whole, you don't get the exception.

>>>> It is *distributed* as part of the program, and that's what copyright
>>>> law restricts by default.

>>> Which is irrelevant if you have permission to distribute all parts.

>> If they form a coherent whole to the point of being regarded by a
>> court, according to copyright law, as a derived/collective work, then
>> it is relevant. And then, this is not the case we're talking about
>> here.

> How is it different? The question is whether firmware and microcode
> are part of the kernel 'work as a whole', which, I don't think
> depends on how they are distributed at all.

Read again, very carefully, the sentence you quoted. Especially the
"when you distribute them as separate works" part.

> Are you sure that the opaque blob of firmware can't be replaced by any
> other opaque blob of bits without affecting the other part?

Quite the opposite is true. Doesn't change the fact that the combined
work tg3.c, later integrated in linux, was created based on those two
original works.

> Would the code continue to work if you replace those bits with
> something else that would work in the hardware it loads?

Whether it works or not is not relevant to tell whether it's derived.
I have no idea of what happens if you replace it with something else.
Quite likely the hardware will crash or freeze or whatever results you
might expect by throwing random bytes at a microprocessor.

> But why not stick to the CPU microcode example?

Because you got the facts wrong. It's not distributed even close to
the kernel.

--
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 06-18-2008, 11:05 PM
Alexandre Oliva
 
Default Fedora Freedom and linux-libre

On Jun 18, 2008, Les Mikesell <lesmikesell@gmail.com> wrote:

> Alexandre Oliva wrote:
>>
>>> Let's assume that I have obtained my copy of several components under
>>> any license but the GPL, and so have a lot of other people.
>>
>> Still missing the point. Don't assuming you have a license that says
>> other things.

> I don't have to assume. I have other licenses.

In this case they say nothing as to the case, they're just confusing
you.

Here, take this program here:

http://www.lsd.ic.unicamp.br/~oliva/papers/vta/example.c

What do you think you're entitled to do with it as it stands?

Now, if I tell you, I license it to you under the GPL, and you accept
it. what you you think you're no longer entitled to do with it?

> No one but the FSF claims that a patch is a derived work

How would you defend the claim that something that literally copies
portions of a copyrightable work is not?

> or a separate component that links 2 others together but doesn't
> contain a copy of the others.

Even dynamic linking copies portions of the dynamic libraries. We've
covered that already.

>> Try to create a derived work based on say Microsoft Windows or
>> Microsoft Word, if you happen to have them around, and to distribute
>> it, and see what happens.

> I'm not sure what you are talking about.

Try creating a work based on internal DLLs, for which you have no
"developer" permissions.

>>>> This would be a prohibition of the GPL.

>>> Yes, in case it wasn't clear before, the specific prohibition that I
>>> consider unethical is that it takes away my choice to share my own
>>> work.

>> It doesn't. Your own original work can't possibly be a derived work.

> Difference of opinion, I guess. The FSF says otherwise

No, it doesn't, and the GPL itself confirms that. There's a
difference between "your own original work" and "the derived work you
created out of a pre-existing third-party's work". The above is about
the former, as you can probably tell from the similarity in spelling ;-)

> if the resulting 'work as a whole' would be be a derived work,

Then it's not "your own original work"

> Without the GPL, I can give you a copy of my original work that
> links to that library

Only if the copyright holder of the library granted you permission to
distribute your derived work. Same as with the GPL. That's how
copyright law's restrictions work.

--
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 06-18-2008, 11:07 PM
Les Mikesell
 
Default Fedora Freedom and linux-libre

Alexandre Oliva wrote:



Why not pursue this argument regarding the CPU microcode for a more
generic disposition?


Because the CPU microcode is not part of a single source file along
with GPLed code (even though it is distributed by Fedora as part of a
single package, allegedly under the GPL)


Do you think file boundaries are necessary to meet the 'separate
sections' requirement? What about after it is compiled?



It may still be two separate things. What's your distinction
between an aggregate stored together and a derived work?


It doesn't matter what I think it is. What matters is what the law
says.


OK, but I don't think copyright law says anything about separate files.
But what actually matters is what the GPL says anyway, since aside from
anything else, it permits aggregates and it calls the parts 'sections'.



Do you dispute that tg3.c is derived from (i) earlier versions of
Linux, and (ii) the firmware it contains?



Yes. The firmware it contained was a separate item then, and so is
the version it contains now.


Dude! tg3.c *contains* the firmware, and it was modified to count on
its being there. It can't possibly not be derived from it.


A container is a good description. You can build a box to contain some
odd-shaped thing, but you can't support a general claim that the box is
derived from the contents. There might be some special case for a
distinctive and creative shape being duplicated in the container but I
don't think 'x number of bits' would count.



The fact that it gets to different hardware is irrelevant. The
relevant point is that the whole forms a single work,


But there is no evidence to support this claim other than that they are
stuck in the same file. What specifically distinguishes if as a 'single
work' as opposed to a container of some unrelated bits? A file can be
just as much a container as a filesystem or a box.



and claiming it
isn't just because portions of it are for your vision hardware and
other portions are for your listening hardware doesn't make a
difference.


Why not? What does make that difference?


But if you mean that songs used in the movie are
still owned by the same entity that owned them before the movie, I
think that is correct,


I didn't mean that, but I agree it's correct. But this has ZERO to do
with whether the movie in the DVD is a single work. Surely the song
whose snippets play during the movie are not mere aggregation, they're
an integral part of the creative work.


I think you are overgeneralizing. The songs in "South Pacific" were
creatively part of the work, but "Saturday Night Fever" just played
songs that were already hits and happened to fit in the scenes.



Yes, the representation does not affect the underlying creative works.


I think this is enough to show that you're seriously missing
information as to how copyright works, and it's become clear that you
have no interest in obtaining such knowledge.


I'm very interested in anything you have to support your theory that
combining two sections in the same file makes a difference
copyright-wise compared to two separate files. Please share the source
of your knowlege about that.


--
Les Mikesell
lesmikesell@gmail.com


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-18-2008, 11:18 PM
Matthew Saltzman
 
Default Fedora Freedom and linux-libre

On Wed, 2008-06-18 at 19:33 -0300, Alexandre Oliva wrote:
> On Jun 18, 2008, Matthew Saltzman <mjs@clemson.edu> wrote:
>
> > On Wed, 2008-06-18 at 14:54 -0300, Alexandre Oliva wrote:
> >> On Jun 16, 2008, Les Mikesell <lesmikesell@gmail.com> wrote:
> >>
> >> > I've explained that the GPL prevents me from sharing original work
> >> > that links to both GPL and non-GPL libraries.
> >>
> >> And I've explained that it doesn't, and asked you to cite the passage
> >> of the GPL that prevents you from doing it. You haven't bothered to
> >> do it, and instead decided to keep insisting in this nonsensical
> >> claim. Please stop spreading lies. We're past the point in which you
> >> could claim ignorance as to this point.
>
> > Wait--Alexandre, are you saying that I could take a GPL library and,
> > say, a CPL[1] library, write a program that links to both libraries to
> > create new functionality and legally distribute source code or a
> > statically or dynamically linked executable version of my program
> > licensed under either the GPL or the CPL?
>
> No. I'm just saying that it's not the GPL that prevents you from
> distributing it. It's copyright law. The GPL merely refrains from
> granting permission for you to do something that, without such
> permission from copyright holders, you can't do in the first place.
>

OK I see.

Then can we at least agree that there are sometimes unfortunate
consequences to the GPL's failure to permit one to share a work
combining two pieces of *free* software because of relatively minor[1]
license incompatibilities?

In fact, I think it's arguable that there are sometimes unfortunate
consequences to the GPL's failure to permit one to share a work that
makes use of a GPL library and a proprietary library. I understand some
authors' desire not to permit that kind of sharing of their work, even
if I don't necessarily agree with it. But I also think that there's
lots of software released under the GPL by authors who don't think
deeply about license issues and don't really understand the limits of
what is permitted by the GPL.

[1] We can certainly quibble about what constitutes "minor"
incompatibility here, but let us take for granted that all authors
involved are committed to the idea of FOSS, use FOSS licenses, and want
to share their work. If all licenses involved are "free software
licenses" according to the FSF (not even just "open-source licenses"
according to the Open Source Initiative), then I think it's fair to
characterize incompatibilities as minor compared to that.

--
Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-18-2008, 11:19 PM
Les Mikesell
 
Default Fedora Freedom and linux-libre

Alexandre Oliva wrote:



The question is, does taking some code and an opaque binary blob and
sticking them in the same file make a 'work as a whole' or is it
identifiable sections of code and separate data that are not derived
from the Program?


This only matters if you distribute them as separate works. When you
distribute them as a whole, you don't get the exception.


Separate sections. Not separate files, not separate media, not separate
delivery carriers. Separate sections. Whatever that means, it is the
way separate works are defined.


>> How is it different? The question is whether firmware and microcode

are part of the kernel 'work as a whole', which, I don't think
depends on how they are distributed at all.


Read again, very carefully, the sentence you quoted. Especially the
"when you distribute them as separate works" part.


Note that it doesn't say anything about files there.


Would the code continue to work if you replace those bits with
something else that would work in the hardware it loads?


Whether it works or not is not relevant to tell whether it's derived.


How else could you tell if the parts are related or not, unless you were
part of the creative process.



But why not stick to the CPU microcode example?


Because you got the facts wrong. It's not distributed even close to
the kernel.


Does 'close' have something to do with whether it is a separate section
or not? Isn't it in the same vmlinuz imaage somewhere?


--
Les Mikesell
lesmikesell@gmail.com

--
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 08:15 PM.

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