Stallman: If you want freedom don't follow Linus Torvalds

[halfmanhalfamazing]

Stallman: The fact that Torvalds says "open source" instead of "free software" shows where he is coming from. I wrote the GNU GPL to defend freedom for all users of all versions of a program. I developed version 3 to do that job better and protect against new threats.

Torvalds says he rejects this goal; that's probably why he doesn't appreciate GPL version 3. I respect his right to express his views, even though I think they are foolish. However, if you don't want to lose your freedom, you had better not follow him.

http://www.pcworld.idg.com.au/index.php/id;211669437

Richard Stallman is nuts IMO. But he's right about this. That Torvalds says 'OSS' and not 'FS' does show where he's coming from.

Torvalds has long shown that he's a pragmatic type of guy, his main goal is good software that works. His use of the term 'OSS' proves it.

Stallman just wants software to be free for some religious edict of his; free for "freedom's" sake. If the software is actually good/functional appears to be a secondary consideration.

Torvalds continues to prove that he doesn't look through the religious looking glass. He's looking through the superior product looking glass.

[joshuapurcell]

The older I get the more I understand where Stallman is coming from. That being said, I understand why Torvalds says 'open source' instead of 'free software'. Both have valid reasons, and the last decade shows that both stances can exist and work towards their common goals together... whether or not they always want to do so.

[Thetargos]

I tend to agree with the general stance about RMS. I don't agree much with him, nor do I see things as "fanatically" as he seems. If I may do an analogy, RMS is "radical" of Free Software... Somewhere in his discourse I get lost, he talks about some (four) basic freedoms and stuff, but I believe that the BSD license expresses one freedom that Stallman has never considered: The freedom of keeping it to yourself.

I know why Linus has stuck with v2 of the GPL and why opted out a BSD-style of license for Linux (he has chosen to remain in control of Linux, and the GPL allows him that, ironically). I think that Linus is not only being pragmatic, but tackles the "freedom" issue differently, respecting even others freedom to protect themselves (the whole issue about DRM in the kernel for certain applications [such as voting booths and the like], even though he is also against DRM for media, for instance.)

[chikamichi]

As Francis Pacibia said, "free spirit takes liberties even with freedom". I guess Linus, while sometimes hard-boiled, sticks to this one.

[philipjohn]

Well there is a very thin line between open source and free softwares. But still they can be used synonymously in my opinion.

[Redeeman]

those who compare RMS and free as in freedom to religion really doesent know anything about what they are blabbing on about.

my advise: investigate what religion REALLY is all about before you speak out like that.

[hobophobe]

Imagine a scenario where a piece of medical equipment runs on open source software, but it's GPLv2 and the hardware is Tivoized. Imagine that improved algorithms are discovered or new functionality, or in the worst case (gulp) a bug.

What is the hospital to do? They don't have the drm keys for updating the machine, and the company that made it is (choose one, they're the same really):
1. Out of business
2. Practicing anti-feature of "you gotta buy a new machine/pay us a lot of money to update your old one"
3. Will update for free, but it will take 6 months for them to do it

And now imagine that you, someone you love, whoever, is in the hospital and needs that machine to work for their life to be saved. DRM is encumbering the proper use of technology and can in fact kill.

So no, I don't think it's insane to support freedom. Freedom lets the hospital administrators decide to change that software. Freedom allows patients to have informed consent to use a particular version of the software at their choosing.

In the hospital, in the voting booth, in any critical area where the software can make a big difference I want the ability to audit that software and I want the controller of the machine to be able to change it. I want the version of software to be easily identified by the voter and the patient so that there is transparency in these processes, because it protects freedom and protects life.

As I understand Linus' position, he believes in the market forces to compel companies to not lock down machines and kill people. Stallman's position is that the risk they won't is too great, that they should be compelled by the license to do so.

I believe for Linus' scenario to work people must be informed of the situation. One would hope the controversy and arguments between Linus' camp and Stallman's camp would tend to make people see the issue and therefore choose to pressure for no DRM.

Whether it will remains to be seen.

[rbmorse]

Your strawman doesn't stand up. In real life, in the unlikely event that such a scenario would even develop in the first instance, and it really is a case of dire consequence (in the legal sense), you hope your hospital has someone on the legal staff that attended at least the first semester of law school and then you fix the software even if it means cracking some DRM schemea.

Don't distribute the patch without permission, though <g>.

I'm with you on the voting thing, though, but I don't think that quite fits the definition of dire consequence.

[Redeeman]

you do realize that cracking some DRM can be a seriously hard job? especially if its not purely software based.

and you dont think voting has dire consequences?

The person elected for president in USA could nuke some country, so you dont think a software malfunction or planting of malcious software is a dire thing?

[rbmorse]

Only if I don't like the result.

[yoshi314]

we need both stallman and torvalds like people.

stallman is very radical. he goes to the far right, so that we can sit in somewhere in the middle, so to speak.

stallman lives by free software ideals. he is one of the most radical free software 'evangelists'. without stallman we would look like radicals.

when people like him are around we are merely people fit somewhere in the middle with sane beliefs ;-)

aww, hard to explain.

without stallman we wouldn't have gnu toolchain. without torvalds, we would still wait for hernel (hurd). without stallman's gnu project linus wouldn't have a working os environment, and vice-versa.

these two people represent two aspects of opensource/free software that complement each other. stallman's ideals and torvalds' practical approach are what got gnu/linux where it stands now.

stallman might seem crazy; but thanks to him we look normal and sane ;-)

[mgc8]

we need both stallman and torvalds like people.
stallman is very radical. he goes to the far right, so that we can sit in somewhere in the middle, so to speak.
Hmm, that's quite true from an utilitarian point of view... sure he makes life easier for the rest of us, because he does all the heavy-lifting. If we had more "radicals" like him there wouldn't even be a need for a "free software movement", it would simply be the natural state of things.

However, there's a big problem with the "freedom to keep it to yourself" argument -- it is like saying the laws against theft infringe upon people's right to take whatever they want from wherever they want and keep it to themselves... Of course, in an ideal society we wouldn't need such laws, and everyone would be happily sharing out of their own good will. But as we know this is not what happens in real life -- the GPL does exactly that, it keeps potentially greedy entities(people/companies) honest. It arose as a necessary evil and is quite smart in the way it turns the horrible copyright and patent laws on their heads.

Frankly, I believe the BSD point of view is the more utopian/unrealistic one -- it assumes that people are honest and the "market" will somehow work out and companies will not abuse the software developed that way. In contrast, the GPL is quite realistic -- it assumes people will try to abuse it one way or the other and it provides measures (draconic to some) against that.

In the end, I'll just say that people who deride Stallman because of his strong views are missing the big picture -- we *are* in the middle of a fight for our own freedom, and each one of us is in some way resposible for what happens. Sticking heads in the sand and ignoring it as something that'll pass or is of no immediate concern will not help...

[yoshi314]

If we had more "radicals" like him there wouldn't even be a need for a "free software movement", it would simply be the natural state of things.i'm not that sure. they're purists, which believe proprietary stuff should die. this is unrealistic right now.

plus, that doesn't help gnu/linux adoption.

imho there shouldn't be too many of these people (but there definitely should be *some*).

if linux were following stallman's principles to the letter we couldn't be able to use proprietary drivers (which are sometimes a necessary evil) or use devices that use additional firmware blobs (some modems and maybe some other stuff i don't know about, etc).

Frankly, I believe the BSD point of view is the more utopian/unrealistic one -- it assumes that people are honest and the "market" will somehow work out and companies will not abuse the software developed that way. In contrast, the GPL is quite realistic -- it assumes people will try to abuse it one way or the other and it provides measures (draconic to some) against that.
imho some bsd people are almost like RMS in their views (esp. theo de raadt ;-) ) and they make more problems than solutions.

[hobophobe]

Your strawman doesn't stand up. In real life, in the unlikely event that such a scenario would even develop in the first instance

(Wikipedia) Therac-25 (http://en.wikipedia.org/wiki/Therac-25) was a radiation therapy machine ... It was involved with at least six known accidents between 1985 and 1987, in which patients were given massive overdoses of radiation ... At least five patients died of the overdoses.

Is my scenario unlikely? Yes. Do things like this happen? Yes.

I'll admit that a product being open source but locked down is better than it not being open source. That alone is a major boon, an extra safeguard against accidents.

The question is whether that's enough. Once you know a piece of equipment is faulty you want to resolve that gap in ability ASAP. The quickest way is to patch it then and there. Impediments to that patch are going to be hard to justify when peoples' health is on the line.

[mgc8]

i'm not that sure. they're purists, which believe proprietary stuff should die. this is unrealistic right now.
Well, proprietery software is not going to disappear, just as free software is not going to. Not even if they are outlwaed. There will always be a place for proprietary software even in a mostly-free world, just as now there is place for free software in a mostly-proprietary world.

The problem is that the more people are "purists" regarding a certain social issue, the more they create a pole that "normal" people are attracted to, enabling a favourable atmosphere overall. If there are only few (or just one, I don't know many public figures that align with Stallman's views) then they are easily cast as "extremists/weirdos" and ignored. The point is, if more people start publicly supporting a stance like this, the population will start believing it.

It's just the way humans work :) You can see this happening in both "good" causes like environmentalism (with the likes of greenpeace being quite extreme in their views) and "bad" (here the extreme right and religion come to mind).

plus, that doesn't help gnu/linux adoption.
This depends... I'd say regular people like the connotations of "free software" (with both meanings of "free") while "open-source" doesn't say much to them. At the same time, corporations work in reverse, so if "enterprise" adoption is desired then "open source" definitely is the way to go. I think in this case the existence of the somewhat separate FS/OS movements is beneficial, in that it can indeed promote adoption. We should only be careful not to forget about the freedom part and mix everything up.

if linux were following stallman's principles to the letter we couldn't be able to use proprietary drivers (which are sometimes a necessary evil) or use devices that use additional firmware blobs (some modems and maybe some other stuff i don't know about, etc).
Indeed, that would definitely be a short-term problem. But in the long term? I'd say having too many proprietery drivers is a bad precedent, and we should do everything to discourage them -- something I am glad to see the kernel developers actually doing. I really hope AMD delivers on their promise and the other companies realize the stupidty of proprietary drivers (I mean, really, would anyone buy a car if it came with a little chinese guy doing all the driving for you? and one that didn't speak your language either) ;)

[rbmorse]

Is my scenario unlikely? Yes. Do things like this happen? Yes.


Sigh. Wrong example for your argument. The Therac 25 case is well known. None of the issues involved would have been resolved by independent programmers in the field. The issue was bad engineering design and inadequate code review.

So, I don't know what this has to do with your failed strawman.

[yoshi314]

Well, proprietery software is not going to disappear, just as free software is not going to. Not even if they are outlwaed. There will always be a place for proprietary software even in a mostly-free world, just as now there is place for free software in a mostly-proprietary world.of course . that's why i think stallman is wrong. he believes proprietary stuff should disappear.

I'd say having too many proprietery drivers is a bad precedent, and we should do everything to discourage them -- something I am glad to see the kernel developers actually doing.that's right.

linux community is doing a great job keeping in touch with reality. they say that blobs are not the way to go, but on the other hand they don't prohibit them and they are actively trying to phase them out as much as possible (pick any reverse engineered driver that matured enough and got into the kernel as an example. i'd risk saying that in the early days of linux 90% of stuff was reverse engineered).

i think that linus' is doing a better job, simply because his beliefs do not hinder linux adoption in the short time, and he is realistic about it.

kernel is being developed in the similar way - if there's a need to do something it simply gets done, with no real long-term goals. (there's no real roadmap, only plans for two next releases maximum; etc. maybe except for "keep it stable, don't bloat it, keep the code clean" sort of thing :) )

[hobophobe]

Allow me to clarify.

The definition of Tivoization is hardware that has only allows some set of signed/trusted software to run with/be installed on it.

A critical system can exist.

That critical system can be open source.

That critical system can be Tivoized.

The software that is trusted to run on that critical system has faults.

There are systems that currently exist that fit those features as far as I know.

Your position seems to be that these do not exist at all, or do not exist concurrently:

The faults in the trusted software running on that critical system are dangerous to people and/or property.

AND

The manufacturer of that critical system will not (as a matter of fact, devoid of intentions, motivations, ability, etc.) fix the faults.

My use of the Therac example was to make it clear there have been critical systems that do have faults that are dangerous to people and/or property. And there will be in the future.

Companies drop support from products that are still in use all the time. Companies make mistakes. They delete their signing keys. They forget to do offsite backups for months and then have a fire. They compute the cost of lawsuit settlements versus cost of recalls.

Where are you claiming this hypothetical fails?

[rbmorse]

Liability law canon as applies to medical devices, mostly. It makes the use of hypotheticals a really bad idea, as you have illustrated. The legal ramifications of fscking with code on medical machines are a reality that simply can't be ignored.

Find a better example (not involving medical technology) to support your basic philosophical argument, then go back and read what Yoshi said. I'm done.

[rbmorse]

I'm being harsh.

Your little hypothetical is fine, as far as it goes. But it's totally irrelevant because it ignores the reality (there's that word, again) that in many, many cases external considerations that have nothing to do with programming, the specific device in question, or even computers in general, determine the terms under which software is/should be licensed. And that's why your use of a medical device as an example in this argument is such a bad one.

Now...you don't have to like that reality. But it exists. And it's something that Linus recognizes (nee, to which he is highly sensitive) and RMS does not. Actually, RMS does recognize it but he dismisses it as wrong. Which is fine for him, but those of us who live in the real world have to deal with the real world. Like Howard the Duck we are trapped in a world we never made. But we're still trapped. And the kids still get hungry.

Peace.

[hobophobe]

In my last post I withdrew any direct association with medical technology and generalized the hypothetical to any CRITICAL SYSTEM. This includes everything from software used in nuclear power plants and weapon systems to flight controlling software to car anti-lock brake and other similar software. Water heater software. Garbage disposal software. CRT software.

Any software anywhere in the world that controls devices capable of Grievous Bodily Harm and/or destruction of private property.

For God's sake, the only time I mention medical technology in that last post is to specifically point out that I originally used that example to show there are situations where lives are in the hands of software. That is, I tried to make it clear that any association with the medical field was purely coincidental.

It's great you still focus on the original example which I took pains to move away from. But I did move away from that specific in order to get to the meat of the hypothetical: Tivoization can be a detriment and that it is unacceptable for any system in which lives and property are at stake.

Whatever you were replying to doesn't wash with the reality of my previous post. For all your bold talk of 'the real world' you should try explicating now and then the actual words on the actual screen.

I still challenge you to actually critique the argument itself. I don't expect you to, as you haven't made any attempt to yet. You prefer to focus on a non-issue and leave the real claims unanswered. It's a common tactic which I believe is known as a Communist Clupeus harengus.

You're welcome.

[rbmorse]

Ok. you win. Your little strawman stands up to dead fish. It is, in fact, perfectly unassailable. If you ever visit planet Earth let me know. I'll buy you a beer.

[hobophobe]

I guess I should feel like an ass now. Unfortunately my sarcasm detector is tivoized and has a flaw that is causing a false negative. So I feel complimented instead.

Damn.

On a lighter note, I was pretty tickled at your view that we must accept the world at face value. It flies in the face of one of the few bits of wisdom I've picked up over the years, "everything is negotiable." I reject your reality and, indeed, substitute my own.

Also, better get in those "planet Earth" references whilst you still can. I hear in a few years it'll get reclassified as a planetoid.

[stevea]

Your strawman doesn't stand up. In real life, in the unlikely event that such a scenario would even develop in the first instance, and it really is a case of dire consequence (in the legal sense), you hope your hospital has someone on the legal staff that attended at least the first semester of law school and then you fix the software even if it means cracking some DRM schemea.

Hopefully your staff lawyer also attends the 2nd semester of law school where they discussed LIABILITY. The medical instrument analogy is nonsense. What if you crack the DRM but failed to realize that the model xyz4006.7731 scanner manipulated an inverted image internally, so you remove the patient's good left temporal lobe instead of the damaged right one ? Exactly such an error occurred due to an image reconstruction software error several decades ago. No one rational would use such a software method for a life critical system; even in an emergency.

Stallman is certainly a zealot and he makes himself seem petty with his insistentce on the "GNU/Linux" title for the OS. Yes the FSF has contributed greatly with GCC, and all the many posix-ish utilities, BUT he failed to grasp the "open" bazaar software development model. I recall patiently hearing year after year in the late 1980 and early 1990s about the FSF kernel and how if we just waited another year or two it would be ready. It was a closed-off "we do software in Boston" attitude that killed the FSF kernel.

Linus started with something much simpler and less complete and produced Linux as "process" rather than a finished work of art. That fact is that Linus is completely within his rights to remain at GPLv2 and Stallman is WAY out of bounds complaining. It's simply not Stallman's code and Linus can do as he pleases.

If Stallman want's to gen' up the old FSF kernel work as a replacement to Linux, and license it as he pleases - well then go ahead. I'd welcome the competition to this too narrow market. Linus only has copyright on about 540 kernel source files out of a total of almost 24000 - it's not a superhuman task to re-write & replace the Linus portion with a GPL3 varient.

GPL3 rev is in part an attempt to prevent DRM. It seems laudable at first glance, but where does this effort end ? Must every cell phone or home NAS that runs GPLv3 code also require a programmable flash and an i2c port to reprogram it ? This would make GPLv3 code unacceptable for many commercial purposes. Making the source available w/ the binary - fine. Something like a TIVO or a WRT54 or a setup-box was built to accept software updates from the network interface so documenting an update procedure - OK. Forcing the system design to readily accept updates - no! The marketplace can handle that issue.


Funny - I just looked at the GNU/Hurd source repo and Hurd source is covered by a mish-mash of GPL(v1), GPL2, "GPL2 or later at user's disgression" and LGPL. Stallman should get his own house in order before throwing stones.

[linuxhansl]

RMS and Linus seem to have different definitions of "Freedom".

Maybe this is a good analogy: Should people in a democratic society be allowed to vote for a new law which would remove their right to vote?

RMSs answer would be "No". He would restrict freedom in order to preserve freedom.
Followers of the BSD license paradigm would probably reply with "Yes" to this question. If the society is free they should have the right to abolish their own rights if they choose so.
I suppose Linus is in the middle somewhere being the pragmatist that he is.

I happen to agree with RMS here.

[stevea]

RMS and Linus seem to have different definitions of "Freedom".

Maybe this is a good analogy: Should people in a democratic society be allowed to vote for a new law which would remove their right to vote?

RMSs answer would be "No". He would restrict freedom in order to preserve freedom.
Followers of the BSD license paradigm would probably reply with "Yes" to this question. If the society is free they should have the right to abolish their own rights if they choose so.
I suppose Linus is in the middle somewhere being the pragmatist that he is.

I happen to agree with RMS here.

I don't believe your analysis is accurate. RMS and Linus both agreed on GPL and GPLv2; so there is very substantial agreement on what "freedom" means.

The places where they disagree sufficiently to follow divergent paths are clearly the differences between GPLv2 and GPLv3. These are the anti-DRM and anti-MS/Novellization issues primarily I believe. I am personally not opposed to GPLv3, but I see it as step toward the "license as pointed weapon" which I do not like, and because of the extensive changes it may not hold up in court (GPLv2 is only barely tested in US courts). Unless there is a clearcut issue I think it's reasonable to take a "wait and see" approach to GPLv3.

Your comments about BSD and democracy are completely off base and off topic. No one is talking about BSD style license. Also if you do not understand why a pure democracy is vile and evil thing you should read some history, or the US federalist papers of ~235 years ago..
--
I just re-read Linus comments on the LKML and his primary objection seemed to be (some time ago) that the GPLv3 *seems* incompatible w the GPLv2. If he GPLv3'ed the 540 or so kernel files the Linus owns then there may be a huge task involved in getting the other 22000 kernel files v3-ized before they can be combined into a composite work. Moger says it's compatible but I think a court should determine that first. There is a very solid argument that the peole who wrote, say the scsi driver and licened it's use under GPLv2 may NOT be on-board with the more restrictive v3 terms. When GPLv3 and GPLv2 sources are combined in one binary - then which terms apply ? *IF* you claim the answer is the GPLv3 terms then I think the authors of the GPLv2 components would have a perfect right to say that you cannot apply these additional anti-DRM restrictions according to GPLv2 terms and that the GPLv3 people are illegally restricting use of this derivative work.

[Redeeman]

you got it wrong.

the GPLv3 has _ZERO_ anti-drm clauses or restrictions, and the people who say that simply does not know what they are talking about.

I suggest you actually read the good document, before you talk about it.

GPLv3'ed software can have as much nasty and evil drm it wants to.

[bridgman]

I think the point is that "Tivo-isation" (preventing a replacement binary built by the owner from operating in the same way as the original vendor-supplied did) is often used to protect DRM implementations. GPLv3 is pretty clear about not restricting the owner's ability to replace binaries. I don't think that's a huge problem for DRM implementations but it is a concern for any environment where "trusted code" is part of the solution.

[duby229]

There seems to be two major differences between GPLv2 and GPLv3... Unfortunately the vast majority of the document has been rephrased to accommodate these two changes...

1: Prevention of "tivoization" This is the case where a company (Tivo) creates a commercial product based on GPLd code, but dont allow you to use your modifications of the code on the said product. You can only use their version of the code and that is it. While it technically abides the license by distributing the code, they dont allow you to use any of the modifications that you might have made on the product they are selling. GPLv3 specifically addresses this, even though this is explicitly implied in the GPLv2 it is not directly stated, where-as it is directly stated in GPLv3

The question is does this break compatibility with GPLv2? My opinion is no it does not. Heres why; GPLv3 still abides the same basic rules except that it addresses a circumstance that older versions do not.Otherwise exactly the same rules apply. The same restrictions and the same rights. I believe that the "Tivoization" clause is compatible and will hold up in court easily.


2: Prevention of "MS/Novell" type deals. (a.k.a "cheesy type foods" hehe :D ) I dont know much about the deal. t is more complex then my brain is capable of understanding, but what I understand (And if I'm wrong, please correct me) MS is saying that "Linux" and a number of the userspace tools that it relies on breaks some of their software patents. Even though to this day they have never clarified which patents are being infringed, or even what software is infringing them. Using this patent infringement threat they created what they called a "covenant" with Novell that essentially protects them from MS infringement threats. However in exchange for this protection Novell has to share their code with MS. What code is being shared is not entirely clear. Some folks have speculated that Novel is giving MS access to OSS code. This would in fact be a GPL violation... Who knows at this point. We know that MS is allowing Novell to use its code that supposedly infringes on it's patents and that Novel has given MS code in exchange for protection.

Now what the GPLv3 does is it tries to extend that protection from any group or person to the whole community. If MS is in fact using GPLd code sooner or later that code should be upgraded to GPLv3, and when that happens and MS starts using it........ I think you guys can catch the drift from here on out. I think it is pretty damn clear that MS is in fact using GPLv2 code from Novell and other sources that they have in fact violated the GPLv2 license by not abiding the copyleft clause.... And there is not a damn thing that the FSF can do about it. The GPLv2 does not accommodate that kind of a situation. The GPv3 does. Ms has what they have and there is nothing that anybody can do about it. However due to the pace of OSS development and the GPLv3 explicitly forbidding that kind of behavior the OSS community will be able to outpace MS in the next decade or so. But only the GPLv3 protects us from MS's copyleft violations. So the GPLv3 must be adopted.

The question is..... Does this issue break compatibility with the GPLv2? It just might. I think that at this point it really --needs-- to be tryed in court. Actually the truth is I would totally --LOVE-- to see this issue go to court. I wanna see exactly what patents MS claims have been infringed. I wanna see exactly what GPLd code they are violating. I wanna see whether or not a judge will determine compatibility between the GPLv2 and the GPLv3. I honesty would absolutely love to see this issue go to court.

[stevea]

you got it wrong.

the GPLv3 has _ZERO_ anti-drm clauses or restrictions, and the people who say that simply does not know what they are talking about.

I suggest you actually read the good document, before you talk about it.

GPLv3'ed software can have as much nasty and evil drm it wants to.


GPLv3 section 3 basically says that if you crack a GPLv3'ed DRM scheme that you are absolutely free to use the "crack". This is a direct response to some US DRM legislation which makes it illegal to device a DRM cracker, and different than in GPLv2. This term goes hand-in-hald with the anti-patent terms. No - GPLv3 does not prohibit DRM, but no one said that. GPL (even GPLv2) is anti-DRM in the sense that if you own a GPLv2 binary then you can legally get the source and can then readily devise a method to subvert the any GPLv2 DRM protection. GPLv3 goes farther and says that you explicitly have the right to use and spread the method of subversion, and if it's patented - tough-luck for the patent+copyright owner, *if* the DRM is derived from GPLv3 licensed work.

In the last para of my previous post I was thinking anti-TIVO, but wrote anti-DRM. The point is that any term that restricts the rights of the copyright owner moreso in GPLv3 than GPLv2 would seem to make them incompatible ... but IANAL. What if someone licensed his copyright code under GPLv2 based on the idea that his code COULD be locked into hardware where it is not accessible to user-update ? Let's say that a home product vendor uses GPLv2 code for the purpose of (among other things) tracking how many hours your HDTV has run for the purpose of warrantee validation. Getting the source code is fine so long as the company does NOT have to disclose an installation method. Clearly (to me) this GPLv2 code is incompatible with the GPLv3 anti-TIVO stuff based on the intent of the copyright holder being incompatible w/ GPLv3.

Linus is right - that it would take a lot of cajoling and arm-twisting to make the ~hundred Kernel copyright holders agree that GPLv3 is compatible with their intentions and GPLv2 license. ... then the thousands of application copyright holders.

[linuxhansl]

In the last para of my previous post I was thinking anti-TIVO, but wrote anti-DRM. The point is that any term that restricts the rights of the copyright owner moreso in GPLv3 than GPLv2 would seem to make them incompatible ... but IANAL. What if someone licensed his copyright code under GPLv2 based on the idea that his code COULD be locked into hardware where it is not accessible to user-update ? Let's say that a home product vendor uses GPLv2 code for the purpose of (among other things) tracking how many hours your HDTV has run for the purpose of warrantee validation. Getting the source code is fine so long as the company does NOT have to disclose an installation method. Clearly (to me) this GPLv2 code is incompatible with the GPLv3 anti-TIVO stuff based on the intent of the copyright holder being incompatible w/ GPLv3.

Linus is right - that it would take a lot of cajoling and arm-twisting to make the ~hundred Kernel copyright holders agree that GPLv3 is compatible with their intentions and GPLv2 license. ... then the thousands of application copyright holders.

I do not understand your point.
GPLv2 was written to grant certain freedoms (the ones that RMS happens to deem important) to the licensee. By choosing that license the kernel developers (and others who chose that license) acknowledged the importance and validity of these freedoms.
When GPLv2 was written DRM and exclusive hardware were not an issue. GPLv3 simple extends the *very same* freedoms to other new scenarios.
Accepting GPLv2 but not v3 is hypocritical.

[stevea]

I do not understand your point.
GPLv2 was written to grant certain freedoms (the ones that RMS happens to deem important) to the licensee. By choosing that license the kernel developers (and others who chose that license) acknowledged the importance and validity of these freedoms.
When GPLv2 was written DRM and exclusive hardware were not an issue. GPLv3 simple extends the *very same* freedoms to other new scenarios.
Accepting GPLv2 but not v3 is hypocritical.

That statement is ridiculous. GPLv2 and GPLv3 are two similar but different licenses. It is completely sensible that some people will wish to license their software according to one license and not the other, since they have different terms. I would agree that the general intent of GPLv3 is similar to GPLv2, and that in some part it extends and details the notions of GPLv2. So completely sane and rational humans may agree or disgree with the differences or extensions based on their intentions.

GPLv2 generally states that anyone should get source w/ the binary and that anyone is free to modify and use the source for derivative work, so long as they pass along the source with the binary. That is a basic statement of FOSS.

GPLv2 attempts to prevent Tivo-ization, may prevent the use of patent (see patent retaliation), force authors to give up all patent rights for GPLv3 derived work, and greatly restricts the terms that may be added to the license and yet be compatible. I see that there may be cases where an author does not wish for these additional restrictions to apply to his code.
==
"If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission".

[Mota_boy]

Well withtout saying reason to further, but making some thinking to others i agree with both linux and stallman in "one kind of" way of my own as everybody else would, kind of way, sorry might sound bit stupid.
But still i`m try to make people thing alternative way to work and so on, and like anyone else would say, i know that you would agree, butt then you are butt ugly.

And sorry about my not perfect english.

[indigo196]

(Wikipedia)

Is my scenario unlikely? Yes. Do things like this happen? Yes.


The researchers also found several engineering issues:

* The design did not have any hardware interlocks to prevent the electron-beam from operating in its high-energy mode without the target in place.
* The engineer had reused software from older models. These models had hardware interlocks that masked their software defects. Those hardware safeties had no way of reporting that they had been triggered, so there was no indication of the existence of faulty software commands.
* The hardware provided no way for the software to verify that sensors were working correctly (see open-loop controller). The table-position system was the first implicated in Therac-25's failures; the manufacturer gave it redundant switches to cross-check their operation.
* The equipment control task did not properly synchronize with the operator interface task, so that race conditions occurred if the operator changed the setup too quickly.[clarify] This was evidently missed during testing, since it took some practice before operators were able to work quickly enough for the problem to occur.
* The software set a flag variable by incrementing it. Occasionally an arithmetic overflow occurred, causing the software to bypass safety checks.


I am not sure that the Therac-25 example is the best one to use... it was a failure of both software and hardware.

[stevea]

I am not sure that the Therac-25 example is the best one to use... it was a failure of both software and hardware.

Let me speak to this. I've spent most of my career working on embedded software, much it involving medical instrumentation (mostly CT scanners, but also MRI) and much of it involving avionic - aircraft electronics. Fortunately most of my work was not on a safety critical path, tho' some was.

Yes such problems still happen, tho' it's far less likely to happen today than in the 1970-1980s.

In the US both the FDA and FAA have developed similar very rigid methodologies for software development. The FAA DOA-178B for example requires that the entire design is detailed and documented and it goes through a design review with outside auditors. During the code development each module undergoes a design review that requires the code confirm precisely to the approved spec. If problems are discovered during implementation that require design changes; then they go back to the paper design phase, and the entire design, not just the changes , are re-audited.

The problem is that subtle errors in software can result in horrible and mostly unpredictable repercussions. I was recently working on a real-time kernel approved for avionics applications. The kernel had recently been modified to allow the use of dual-processors (SMP, like the intel core2duo) and a subtle race condition was introduced when you attempt to set the system time at an instant when another thread is in the middle of reading the time the whole notion of time could be fouled up. The design was fine, the designer understood race conditions, but several sets of human eyes read the code and missed this one.

It's relatively easy to add independent and redundant safety locks on systems to prevent the therac type overdose problems. The independent nature of the calculation helps prevent systemic problems. There are much bigger problem than the safety interlocks on "guns". Much of the observation is also based on calculations that may have gone awry. What if your physician gets an incorrect report of the amount of radiation applied (tho' within safety limits per application). What if they get an incorrect report of the tumor size of location ? What if the clock time in a bit of avionics has it's clock stall, so it wildly over-reports rates of turn and velocities and these over-reports cause some safety locks to kick-in ?

There was a nice article in American scientist (the Sigma Xi publication) a number of years go on faults in engineered systems. The specific example topic was bridge failure, long before the Minnesota tragedy. The gist was that generally we learn new solutions only from such failures b/c we don't have the ability to foresee new failure modes except by experience.

The current software challenge is to PROVE that we have at least eliminated the known failure modes. This is not currently possible except in a few axiomatically proven code implementations.