Blocking Gmail ads

[Gregory Seidman]

On Thu, May 15, 2008 at 06:53:26PM -0500, Jordi Guti?rrez Hermoso wrote:

> On 15 May 2008 19:40:21 -0400, Luke S Crawford <lsc@...> wrote:
> > "Jordi Guti?rrez Hermoso" <jordigh@...> writes:
> >  > ...  Apple taking code without
> > > giving back in a usable way, or not giving back at all?
> >
> > see Darwin-  Apple is giving away a bunch of it's OS-level advances.
>
> I was thinking more about the KHTML/Webkit fiasco. Looks like the code
> is finally finding its way back to KDE, but Apple didn't make it easy
> to happen.

[...]

I believe what Apple did is fork the code. KHTML had code useful to Apple,
but not goals useful to Apple. They decided to call it WebKit (renaming is
allowed by the GPL/LGPL) and have been maintaining a separate code
repository. As a result, KHTML is used in exactly one environment
(Konqueror/KDE) and WebKit is used in all kinds of places (Safari, the Qt
library, Adobe AIR, Google's Android, GNOME's Epiphany, etc.).

Looks like Apple did terrible harm by devoting resources to improving the
functionality and releasing them to the world, eh? Oh, but it isn't getting
back to KHTML quickly, you say? That sometimes happens in a code fork.

I don't think this counts as a fiasco, sorry. Apple played by the rules and
it benefited everyone. (Not KHTML? Actually, since WebKit is part of Qt
these days, KDE could just ditch KHTML and use WebKit instead. Whether they
choose to or not has nothing to do with it.) Remember that forking is one
of the rights the copyleft seeks to protect.

> - Jordi G. H.
--Greg


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jordi Gutiérrez Hermoso-2]

On 15/05/2008, Steve Lamb <grey@...> wrote:
> Jordi Gutiérrez Hermoso wrote:
>  > They're
>  > playing nice today, and even Microsoft was once widely thought to be
>  > playing nice too, but there's no reason why they should keep doing so.
>
>
>     Er, what?  When did that happen?  Certainly not in the past 20 or so years.

Maybe you didn't think Microsoft was playing nice, but when they were
the underdog against IBM, it obtained a similar mindshare as Apple is
now being an underdog to Microsoft.

Of course, with hindsight of all the nasty practices that Microsoft
did from the beginning it's a different story, but back then very few
people were aware of those practices.

- Jordi G. H.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jordi Gutiérrez Hermoso-2]

On 15/05/2008, Gregory Seidman <gsslist+debian@...> wrote:

>  Looks like Apple did terrible harm by devoting resources to improving the
>  functionality and releasing them to the world, eh? Oh, but it isn't getting
>  back to KHTML quickly, you say? That sometimes happens in a code fork.

Well, the rules (LGPL) say that they have to give back the code. Which
they did, in large chunks, a year later, in ways that were impossible
to put back into KDE. They didn't break any written rules, just didn't
act in a way that is traditional in the free software community. They
acted like a corporation would (this is not a compliment, despite what
the "profitable == moral" people think).

Forking is generally seen as a hostile falling apart within our
community. Forking happens with big disagreements, negative publicity,
and internal flamewars. Xemacs vs Emacs, XFree86 vs Xorg, Funpidgin vs
Pidgin... And I don't see Apple's forking as a friendly move either.
And it's taken a long time for KDE to benefit from it, and in the
meantime the whole thing caused flamewars within KDE.

Fiasco, I insist.

- Jordi G. H.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jordi Gutiérrez Hermoso-2]

On 15/05/2008, Gregory Seidman <gsslist+debian@...> wrote:
>  Not KHTML? Actually, since WebKit is part of Qt
>  these days, KDE could just ditch KHTML and use WebKit instead.

It's not so easy. Technical obstacles loom ahead:

   http://www.kdedevelopers.org/node/3073

- Jordi G. H.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Rich Healey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jordi Gutiérrez Hermoso wrote:

> On 15/05/2008, Ron Johnson <ron.l.johnson@...> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>>  Hash: SHA1
>>
>>
>> On 05/15/08 12:41, Jordi Gutiérrez Hermoso wrote:
>>  > On 14/05/2008, Michelle Konzack <linux4michelle@...> wrote:
>>
>> [snip]
>>
>>  >>  OH, Airbus is using Linux too...  So, do you want to have access to  the
>>  >>  sourcecode because you are traveling with an Airbus?
>>  >
>>  > In fact, I believe it is available. It has to be anyways, according to
>>  > the GPL. There is no ASP loophole (I assume you are referring to the
>>
>>
>> You need to study the GPL more closely.
>>
>>  The source only needs to be available to parties that you distribute
>>  binaries to.  In this case, presuming that Airbus subcontracted out
>>  the coding of the in-flight entertainment module, the distributees
>>  are Airbus and the companies that purchase the planes.
>
> How does this work with GPLv3? They changed it from "distribute" to
> "convey". Is Airbus conveying the software to its customers or not? If
> there is a way to bring a USB dongle and get some of the software from
> the entertainment system in the Airbus passenger seats, has that

I believe that's called "Stealing" and in a ruling totally non-GPL
related, is illegal.
> software been distributed to me or not? How does the AGPL handle a
> situation like this, if the software were under the AGPL?
>
> - Jordi G. H.
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFILPwyLeTfO4yBSAcRAr7bAKCYehgtuEg55zSaw9qouQ7jprh/1QCdGOD3
oXb9Q31YrWkGHEPLgKTakzM=
=gUF8
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ron Johnson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/15/08 20:38, Gregory Seidman wrote:
[snip]
> repository. As a result, KHTML is used in exactly one environment
> (Konqueror/KDE) and WebKit is used in all kinds of places (Safari, the Qt
> library, Adobe AIR, Google's Android, GNOME's Epiphany, etc.).

????

Epiphany uses Gecko.

- --
Ron Johnson, Jr.
Jefferson LA  USA

ESPN makes baseball players better.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFILQRjS9HxQb37XmcRAkCYAKCwt8dxyS/IGwDNK/bmLIqtNSyT0ACgps3K
N5sogYSAKaTRdCdbQbyM9GQ=
=7yds
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lee Glidewell]

The stable one does, yes, but it's switching to WebKit. The epiphany-webkit
package has been in the Testing repository for some time now.

It's very fast, but last time I used it, it had quite a few hiccups when
loading dynamic pages.

On Thursday 15 May 2008 08:49:55 pm Ron Johnson wrote:

> Epiphany uses Gecko.
>
> --
> Ron Johnson, Jr.
> Jefferson LA  USA
>
> ESPN makes baseball players better.



--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ron Johnson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/15/08 23:05, Lee Glidewell wrote:
> The stable one does, yes, but it's switching to WebKit. The epiphany-webkit
> package has been in the Testing repository for some time now.
>
> It's very fast, but last time I used it, it had quite a few hiccups when
> loading dynamic pages.

Interesting, and good to know.  Thanks.

> On Thursday 15 May 2008 08:49:55 pm Ron Johnson wrote:
>
>> Epiphany uses Gecko.

- --
Ron Johnson, Jr.
Jefferson LA  USA

ESPN makes baseball players better.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFILRCYS9HxQb37XmcRAj32AKCCXI7TvyoQCI/6CSAeTw64wHZ7zACg5ktC
+E1lo7FxB37ZivrqN7wuoOQ=
=jwy9
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Gregory Seidman]

On Thu, May 15, 2008 at 09:44:50PM -0500, Jordi Guti?rrez Hermoso wrote:
> On 15/05/2008, Gregory Seidman <gsslist+debian@...> wrote:
>
> >  Looks like Apple did terrible harm by devoting resources to improving
> >  the functionality and releasing them to the world, eh? Oh, but it
> >  isn't getting back to KHTML quickly, you say? That sometimes happens
> >  in a code fork.
>
> Well, the rules (LGPL) say that they have to give back the code.

No, they don't. They say that if you distribute something built with the
code, you have to release the code. There is a common misconception that
the (L)GPL forces people give their changes to the original authors (or
current maintainers). This is not supported by the actual language of the
(L)GPL, nor by the GNU Foundation's intent in creating the (L)GPL.

Furthermore, if you actually read the Free Software Definition
<http://www.gnu.org/philosophy/free-sw.html> you will notice that the
four freedoms listed specifically support Apple's behavior. They wanted to
run the KHTML code as a Mac web browser (freedom 0), they wanted to adapt
it to work well on the Mac (freedom 1), they wanted to distribute it with
their operating system (freedom 2), and they wanted to make it a
best-in-class web browser engine (freedom 3).

> Which they did, in large chunks, a year later, in ways that were
> impossible to put back into KDE. They didn't break any written rules,
> just didn't act in a way that is traditional in the free software
> community. They acted like a corporation would (this is not a compliment,
> despite what the "profitable == moral" people think).

So the problem is that they aren't "traditional"? Yeah, whatever. They
produced a better, more flexible, more functional version of the library
and have consistently fulfilled and exceeded their responsibilities for
maintaining it as Free software. That they did it by taking it in-house
instead of trying to convince the people who tied it to KDE that it should
be more general is utterly irrelevant.

> Forking is generally seen as a hostile falling apart within our
> community. Forking happens with big disagreements, negative publicity,
> and internal flamewars. Xemacs vs Emacs, XFree86 vs Xorg, Funpidgin vs
> Pidgin... And I don't see Apple's forking as a friendly move either.
> And it's taken a long time for KDE to benefit from it, and in the
> meantime the whole thing caused flamewars within KDE.

It's easy for people to take offense. Apple did what it did for business
reasons, not to piss off KDE. The KDE folks didn't like that Apple made
their code way better and released it in a form that people outside of KDE
actually wanted to use? Yeah, not feeling any sympathy here. Apple took a
weird, niche browser from a bunch of not-invented-here coders and made it
good. So good that the library ON WHICH KDE IS BASED decided to incorporate
it.

Is it hostile to fork code? How about creating an independent, competing
codebase (e.g. KHTML vs. Gecko)? Again, no sympathy.

> Fiasco, I insist.
[...]

And I call bullshit.

> >  Not KHTML? Actually, since WebKit is part of Qt
> >  these days, KDE could just ditch KHTML and use WebKit instead.
>
> It's not so easy. Technical obstacles loom ahead:
>
>    http://www.kdedevelopers.org/node/3073

The technical obstacles there are not with ditching KHTML, but with porting
the advantages KHTML currently has over WebKit; the article doesn't go into
detail about what those advantages are. It also makes two important points:
bug-for-bug compatibility with Safari has advantages (if you're using the
same engine as a significant installed base, web sites might actually gear
content to work around your quirks instead of just ignoring you), and
pushing their patches through Qt's branch (i.e. WebKitQt) is a good
alternative to dealing with Apple's turnaround on patches. It sounds to me
like it's mostly a problem with bruised egos, for which I have (say it with
me) no sympathy.

> - Jordi G. H.
--Greg


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jordi Gutiérrez Hermoso-2]

On 16/05/2008, Gregory Seidman <gsslist+debian@...> wrote:

> On Thu, May 15, 2008 at 09:44:50PM -0500, Jordi Guti?rrez Hermoso wrote:
>  > On 15/05/2008, Gregory Seidman <gsslist+debian@...> wrote:
>  >
>  > >  Looks like Apple did terrible harm by devoting resources to improving
>  > >  the functionality and releasing them to the world, eh? Oh, but it
>  > >  isn't getting back to KHTML quickly, you say? That sometimes happens
>  > >  in a code fork.
>  >
>  > Well, the rules (LGPL) say that they have to give back the code.
>
>
> No, they don't. They say that if you distribute something built with the
>  code, you have to release the code.

That's what I meant.

>  That they did it by taking it in-house
>  instead of trying to convince the people who tied it to KDE that it should
>  be more general is utterly irrelevant.

No, that's the whole point. Because they didn't work with free
developers, they actually created a lot of strife for KDE. They took
the code and told the kdevelopers to fork off.

> It's easy for people to take offense. Apple did what it did for business
>  reasons,

Ah, here we go. I was waiting for the "profitable==ethical" slant. Whatever.

>  Is it hostile to fork code? How about creating an independent, competing
>  codebase (e.g. KHTML vs. Gecko)? Again, no sympathy.

Competition is good. Forking fragments efforts.

> a problem with bruised egos,

Did you read the article at all? It's not about egos. It really is
*hard* to put Webkit into KDE. Apple ignored KDE's patches, and gave
the impression that they wanted gratis employees, not collaborators.
They didn't play nice with KDE, whatever other benefits to Webkit may
bring to the world at large, but KDE got a lot of problems because of
the whole thing.

- Jordi G. H.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jordi Gutiérrez Hermoso-2]

On 15/05/2008, Rich Healey <healey.rich@...> wrote:
>  > How does this work with GPLv3? They changed it from "distribute" to
>  > "convey". Is Airbus conveying the software to its customers or not? If
>  > there is a way to bring a USB dongle and get some of the software from
>  > the entertainment system in the Airbus passenger seats, has that
>
> I believe that's called "Stealing" and in a ruling totally non-GPL
>  related, is illegal.

I'll ignore the usage of the word "steal" in the context of non-rival
goods, which to me looks like a silly word to use here.

Setting that aside, you bring up an interesting point. If I take GPLed
code, I modify it internally, and somehow it leaks outside, is the
person who takes it infringing copyright or not? I say they're not,
since the code isn't copyrighted to me even if I modified it. On the
other hand, they can't force me to distribute the source either, since
I didn't convey the code, right? It just got leaked somehow.

Curious hypothetical situation.

- Jordi G. H.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Gregory Seidman]

On Fri, May 16, 2008 at 07:34:19AM -0500, Jordi Guti?rrez Hermoso wrote:
> On 16/05/2008, Gregory Seidman <gsslist+debian@...> wrote:
[...]
> >  That they did it by taking it in-house instead of trying to convince
> >  the people who tied it to KDE that it should be more general is
> >  utterly irrelevant.
>
> No, that's the whole point. Because they didn't work with free
> developers, they actually created a lot of strife for KDE. They took the
> code and told the kdevelopers to fork off.

There is no strife here. Apple didn't try to take over the KDE project, or
the KHTML project. They took the code and ran with it. KDE developers took
offense because they expected that anyone who improved their code would do
so with the same goals as the developers, i.e. improving KDE. That is an
unrealistic expectation. Apple didn't care about KDE and is under no
obligation, legal or ethical, to care about KDE. If the KDE developers want
to benefit from Apple's improvements to the code then they will have to put
in some effort, but they got along just fine (as far as they were
concerned) without those improvements before Apple got involved.

> > It's easy for people to take offense. Apple did what it did for
> > business reasons,
>
> Ah, here we go. I was waiting for the "profitable==ethical" slant.
> Whatever.

I never made that implication. Consider that Apple had a motivation (need a
web browser component) and had five options to get it:

1) license some non-free code from someone
2) write their own in-house and keep it closed
3) write their own in-house and release it as FOSS
4) bend an existing FOSS project to their needs
5) take FOSS code and adapt it to their needs without interfering with the
   current maintainers

Which of these is best for the FOSS community? #1 and #2 provide no value
to anyone but Apple. #3 provides arguable value, but who needs yet another
immature, competing browser engine? #4 would piss off lots of people and
probably wouldn't even work. Only #5 is both respectful of the FOSS
community and actually produces worthwhile software. And remember that the
profit motive is what makes the first two choices, which are of no value to
FOSS, less viable.

> >  Is it hostile to fork code? How about creating an independent, competing
> >  codebase (e.g. KHTML vs. Gecko)? Again, no sympathy.
>
> Competition is good. Forking fragments efforts.

Bullshit twice over. Forking builds on what already exists. Unless your
competing codebase is based on designs that are both significantly better
than what you're competing against and so fundamentally different that they
can't be accommodated by the existing codebase, a whole new codebase is a
waste of duplicated effort in *addition* to fragmenting effort. Both
forking and entirely new, competing codebases fragment effort, but at least
forking minimizes wasted effort reinventing the wheel.

> > a problem with bruised egos,
>
> Did you read the article at all? It's not about egos. It really is
> *hard* to put Webkit into KDE. Apple ignored KDE's patches, and gave
> the impression that they wanted gratis employees, not collaborators.
> They didn't play nice with KDE, whatever other benefits to Webkit may
> bring to the world at large, but KDE got a lot of problems because of
> the whole thing.

Apple had no more reason to play nice with KDE than KDE had to play nice
with Apple. Their goals are completely unrelated. Apple doesn't want gratis
employees, they want *paid* employees whose vested interests are dictated
by their employer. As long as Apple and KDE have different goals then they
will not benefit one another by working together except accidentally, e.g.
through Qt. The hearts and minds behind KHTML considers it important to be
able to embed kparts in web pages to handle various content types. Apple
doesn't give a rats ass about integrating with KDE, nor should they. They
do, however, consider rich text editing a priority, and KDE isn't as
concerned about that.

I'm still not feeling sympathy for the KHTML folks. It sounds more like
*they* want the gratis employees, but paid by Apple. They want Apple to
deal with KDE's turnaround on patches instead of having to deal with
Apple's turnaround on patches. Both sides want their own release cycles and
control of the codebase. And they both have it!

As things stand, Apple has shown itself to be a better custodian of the
library, in the sense that it has greater functionality with a broader
appeal (note that those are not separate -- the functionality WebKit has
over KHTML is of broader appeal than the functionality KHTML has over
WebKit; I'm not going to open a can of worms about which one is objectively
more functional). More end users benefit from Apple's codebase than KHTML.

Should KDE simply give up control of the codebase and go with WebKitQt?
Well, it's an option, but it's really up to them. If control of the
codebase and the advantages of KHTML over WebKit are worth more to them
than the improvements in WebKit, then they are right to hold onto their own
codebase and they can put the effort into incorporating WebKit improvements
as they have time and interest. If not, however, it is only ego that makes
them hold onto KHTML.

I'll repeat, for those who skimmed: Apple is under no obligation, legal or
ethical, to care about KDE.

> - Jordi G. H.
--Greg


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Brian McKee]

On Fri, May 16, 2008 at 9:09 AM, Gregory Seidman
<gsslist+debian@...> wrote:
> Apple doesn't give a rats ass about integrating with KDE, nor should they. They
> do, however, consider rich text editing a priority, and KDE isn't as
> concerned about that.

This is the one statement I think could be modified - Apple doesn't
care about about integrating with KDE, and thus lost the opportunity
to keep reaping the benefits that the KDE guys could have provided on
going.   I'd like to think that the companies that try harder to work
with the existing community will do better in the long term -
spending some of their resources on things they didn't care about
would return them effort by others on things they do care about.

There's nothing illegal or immoral about it - it's just short sighted
to believe that the code was worth taking, but the coders weren't
worth the effort required (in a direction they didn't care about) to
keep them on board.

Brian


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Gregory Seidman]

On Fri, May 16, 2008 at 01:40:30PM -0400, Brian McKee wrote:

> On Fri, May 16, 2008 at 9:09 AM, Gregory Seidman <gsslist+debian@...> wrote:
> > Apple doesn't give a rats ass about integrating with KDE, nor should
> > they. They do, however, consider rich text editing a priority, and KDE
> > isn't as concerned about that.
>
> This is the one statement I think could be modified - Apple doesn't
> care about about integrating with KDE, and thus lost the opportunity
> to keep reaping the benefits that the KDE guys could have provided on
> going.   I'd like to think that the companies that try harder to work
> with the existing community will do better in the long term -
> spending some of their resources on things they didn't care about
> would return them effort by others on things they do care about.

Why do corporations contribute to FOSS? Because (in their analysis) the
benefits of doing so outweigh the costs, including the opportunity cost of
pursuing another option (see my previous post on the options Apple had).
At a finer granularity, there's some analysis about *how* they will
contribute. Is the benefit of potential future improvements to the code by
the current developers worth the cost of working within the KDE community?

Remember that while cost ultimately boils down to dollars, time to market
and PR can be measured in dollars as well. Will an acceptably functioning
adaptation of the code be unacceptably delayed by going through the
existing community? On balance, is the PR issue with walking into a
community and trying to change its focus (even bearing the gift of code)
greater than the PR issue of forking it?

Also, remember the crucial difference in focus. If what the KDE guys are
working on for the foreseeable future (i.e. their stated priorities) is not
of interest, the potential future benefit of their improvements to the code
goes way down. In addition, giving up that benefit isn't really giving up
that benefit.

Just as the KDE guys can expend some effort to take improvements from
WebKit and port them to KHTML, Apple can expend some effort to take
improvements from KHTML and port them to WebKit. If there is some
improvement that is of sufficient value and is easier to port than
reimplement, you can bet that's what will happen. That kind of
cross-pollination is one of the beauties of FOSS. If KHTML is consistently
improving in ways that matter to Apple, I wouldn't be surprised to see
Apple making an effort to make the codebases converge.

Right now, cost/benefit analysis recommends a separate codebase (and
community). That can change, but it's only going to change if the KDE guys
are working on things that matter to Apple. If KDE's and Apple's interests
become aligned, there could be a convergence. Since they weren't initially
(and still aren't), there is a fork.

> There's nothing illegal or immoral about it - it's just short sighted
> to believe that the code was worth taking, but the coders weren't
> worth the effort required (in a direction they didn't care about) to
> keep them on board.

I don't think of it as taking the code without the coders. It's taking the
code without the agenda. Apple has their own agenda. Anyone willing to
follow that agenda, including people working on KHTML, are welcome; on the
other hand, Apple expects to have to pay people to follow their agenda,
which is why paid Apple employees are working on WebKit. This is the only
way they could work with the code without treading on KDE's agenda.

While many authors feel strongly that they have the right to set the agenda
for their code, that is specifically what the (L)GPL seeks to avoid. Just
as we object to being told what we can do with closed code, so should we
object to being told what we can do with Free code.

> Brian
--Greg


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[dotancohen]

2008/5/15 Jordi Gutiérrez Hermoso <jordigh@...>:
> Power to the users. If they break the laws, that's their problem. We
> don't need paternalistic corporations doing the job of law-enforcement
> agencies.

Engineering does not work that way. Neither does medicine, nor
driver's licenses for that matter. _First_ you learn the trade, then
you are permitted to practice it in a public setting. The government
won't wait until you kill someone to prevent you from doing something
dangerous.

For instance, most BMWs are computer-limited to 250 kph. The
drivetrain could probably get them close to 300 kph, but the computer
limits them. That's great, the engineers can then design a braking
system that is good for 250 kph, and tires that are designed for 250
kph. If you reprogram the computer to allow 300 kph, and don't upgrade
the tires and braking systems, you are endangering everyone else on
the road. Also, you forget about pollution controls, which are also
regulated by the government.

> Sure, but it's *my* responsibility not to harm others. If by
> negligence or stupidity I harm others, then by all means, put me on
> trial and remove me from society until I reform. Don't take away
> freedom from me just because I might misuse it; I will also mostly use
> it properly.

If it is the case that most people use power responsibly in your land,
then I want to move there. Most places in the world are not blessed
with such responsible citizens.

> Right, I don't have any details about this. But if I am interacting
> with the software, I do believe we have a fundamental right to know
> how it's working or to hire anyone knowledgeable enough to do modify
> it for us, regardless of their affiliations.

No, you don't.



Dotan Cohen

http://what-is-what.com
http://gibberish.co.il
א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Ron Johnson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/16/08 14:09, Dotan Cohen wrote:
[snip]
> you are permitted to practice it in a public setting. The government
> won't wait until you kill someone to prevent you from doing something
> dangerous.

Sure they do.  Happens all the time.

- --
Ron Johnson, Jr.
Jefferson LA  USA

ESPN makes baseball players better.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFILd3oS9HxQb37XmcRAvCSAJwJw6QcYp4QwPcziFsgodYuSks7pACg7XWL
tyM0Bsab68xxwVHiGQUQgkc=
=zPXG
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...