Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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.

  • stevea
    replied
    Originally posted by indigo196 View Post
    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.

    Leave a comment:


  • indigo196
    replied
    Originally posted by hobophobe View Post
    (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.

    Leave a comment:


  • Mota_boy
    replied
    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.
    Last edited by Mota_boy; 01-08-2008, 02:04 PM.

    Leave a comment:


  • stevea
    replied
    Originally posted by linuxhansl View Post
    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".
    Last edited by stevea; 01-02-2008, 05:09 AM.

    Leave a comment:


  • linuxhansl
    replied
    Originally posted by stevea View Post
    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.

    Leave a comment:


  • stevea
    replied
    Originally posted by Redeeman View Post
    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.
    Last edited by stevea; 01-02-2008, 12:56 AM.

    Leave a comment:


  • duby229
    replied
    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 ) 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.

    Leave a comment:


  • bridgman
    replied
    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.
    Last edited by bridgman; 12-31-2007, 11:14 AM.

    Leave a comment:


  • Redeeman
    replied
    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.

    Leave a comment:

Working...
X