> -----Original Message-----
> From: Boyd Stephen Smith Jr. [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 28, 2006 1:31 PM
> To: [email protected]
> Subject: Re: [gentoo-amd64] Re: How To Play WMV (thread drift -
> slaveryware)
> 
> 
> On Thursday 28 September 2006 13:16, "Bob Young" <[EMAIL PROTECTED]> 
> wrote about 'RE: [gentoo-amd64]  Re: How To Play WMV (thread drift - 
> slaveryware)':
> > Not really, *most* people will be, just as "enslaved" even if they do
> > use a GPLed version of the software.
> 
> Not true.  The freedom to modify the code is important even if the user 
> cannot directly exert it, because it allows the user to pay 
> someone *other 
> than the copyright holder* to do the modifications for them.

So...? instead of being dependent upon the original vendor, the user is 
dependent upon the contractor s/he hires to do the modifications. I don't 
consider the option of transferring dependence from one entity to another 
entity as being real freedom.

I will grant you that in instances where the original vendor no longer wishes 
to maintain/fix/update a piece of software, I believe that the source should be 
released, either GPLed, or just pure public domain, but that's not what we're 
talking about in this debate.

> Also, anyone is allowed to give their friend free software and to  use free 
> software for any purpose.  Those freedoms are not provided to users of 
> non-free software.

Now you're muddying the waters between libre and gratis, I can give you 
hundreds of examples of freeware or shareware that I can *legally* give to my 
friends without charge, but that don't have source code available. So in the 
sentence above what exactly is "free software" and what differentiates it from 
"non-free software?"


> > > when the lack of ATI and NVidia
> > > drivers is the only reason xorg-7.1 is not yet stable on x86 or amd64,
> > > and it's the same thing with other distributions -- their actions are
> > > holding a large segment of the would-be free software world hostage. 
> > > Call it what you like, I call choosing to be a hostage to the whims of
> > > a software overlord choosing to be enslaved, and I both refuse to do
> > > it, and refuse to have my money go toward funding the slave-masters!
> >
> > How is that different from people who can't read code being at the whims
> > of Linux kernel developers?
> 
> No one is at the whims of the kernel developers.  Even if you can't read 
> code, you can communicate with people *other than the kernel developers* 
> who can read code.

Okay, but since you can't read code, you have to *trust* whomever you do 
contact, they could just as easily be mistaken, or make an error without you 
knowing it. Why is being dependent upon someone else instead of <fill in the 
blank>, but still dependent nonetheless, considered freedom?


> You aren't forced to trust the kernel developers word 
> that patch X is "better" for linux.  Sure, it may improve performance in 
> 90% of the cases -- but what if you are in the other 10%?  Even if you 
> don't understand code, it's simple enough to reverse a patch.

Uhhhh....and binary patches can't be reversed, that doesn't require source code 
to be available.

> > I fail to see that it really makes much of a difference whether Jane
> > Avgusr is dependent on a Linux kernel developer or on an engineer
> > working at nVidia.
> 
> Because *no one* is dependent on the linux kernel developers. You can make 
> the needed changes.  If you don't have the ability to,

As is the case for 99.99 percent of the population.

> you can get someone 
> else to using other resources available to you. 

So instead of depending on a kernel developer, I'm depending on a contractor I 
hire, I just don't see that as dramatically different.

> E.g. I really need my 
> lawn mowed and I hate doing it; I'll trade you a mowed lawn for a kernel 
> patch.

LOL..nice in theory, but I seriously doubt that many people are actually 
bartering for kernel patches.


> Someone *has* to pay for the cost of maintaining and improving software. 
> That's economic fact.  NVidia says you have to pay *them* to improve their 
> software.  Linux kernel developers says you can pay *anyone with the 
> skills* (or use your own time) to improve the software.  Clearly, 
> you have more options (and are thus more free) with free software.

If I'm not doing it myself, I see little difference whether I pay one entity, 
or pay another.

> > There really is no such thing as "slaveryware" or "freedomware" it's all
> 
> Yes, there very well is.  I want software I'm free to distribute (I need 
> freedomware).

That's fine for you, but it isn't important to most users, and in the grand 
scheme of things it doesn't need to be.

> I want software I'm free to use how I see fit (I need 
> freedom ware). 

Depends on what how you define "see fit." For most users there is nothing 
specifically provided by open source that they absolutely require.

> I want software I can profile and audit myself

That's fine for you, but it isn't important to most users, and in the grand 
scheme of things it doesn't need to be.
 
> Analogy:
> improving and maintaining software = food
> software companies and individual developers = farms and farmers

Software is not food, software is software, and developers are not farmers, 
they are developers.

> So, you are saying it "doesn't make much different" whether I'm forced to 
> buy all my food from one particular farm or if I'm allowed to buy food 
> from any farmer (probably on the free market)?

I'm saying that end users are free to buy or not buy hardware/software from any 
vendor based on the capabilities, features, reputation, and reviews of that 
hardware/software. The availability/nonavailability of source code doesn't 
add/subtract freedom from the transaction at all, at least in real world 
practical terms for most users.
 
> The fact is that is DOES matter.  And anyone that doesn't understand that 
> is simplifying things to much.

It is simple, very simple, you're just over intellectualizing it and 
romanticizing it.

 -- 
Regards
Bob Young 



-- 
[email protected] mailing list

Reply via email to