home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / gnu / misc / discuss / 4685 < prev    next >
Encoding:
Text File  |  1993-01-28  |  7.1 KB  |  165 lines

  1. Newsgroups: gnu.misc.discuss
  2. Path: sparky!uunet!sybus.sybus.com!myrddin!tct!chip
  3. From: chip@tct.com (Chip Salzenberg)
  4. Subject: Re: Public Domain C Compiler?
  5. Message-ID: <2B688B1D.6EA2@tct.com>
  6. Date: Fri, 29 Jan 1993 01:40:45 GMT
  7. References: <2B4A0FD5.FD6B@tct.com> <BURLEY.93Jan17153735@apple-gunkies.gnu.ai.mit.edu> <2B5ACF96.171C9@tct.com> <BURLEY.93Jan19155421@apple-gunkies.gnu.ai.mit.edu>
  8. Organization: TC Telemanagement, Clearwater, FL
  9. Lines: 154
  10.  
  11. According to burley@apple-gunkies.gnu.ai.mit.edu (Craig Burley):
  12. >Fact remains, a purchaser must do quite a bit more research to ensure
  13. >that a "PD C compiler" has source available than a "GPL-protected C
  14. >compiler" once that purchaser learns what PD and GPL really mean.
  15.  
  16. I'd contest that point.  All the purchaser need do is make one very
  17. simple stipulation: "We purchase only programs that include the source
  18. code necessary to produce the delivered executables (if any)."  Now
  19. where's the "quite a bit more research"?
  20.  
  21. >I pointed out that the GPL carries with it various useful elements
  22. >that PD doesn't.
  23.  
  24. No way.  You pointed out the differences between GPL and PD, and then
  25. made a bald claim that they constituted improvements.  Such a claim is
  26. not proof.
  27.  
  28. >So it is easier for me to say "get GPL-protected stuff" then "get PD
  29. >stuff as long as it comes with source, make sure it's the actual
  30. >source used to build _your_ version, etc" and explain what both mean.
  31. >Naturally, I do that ...
  32.  
  33. So if they have to be educated anyway, what's the problem with PD?
  34. That education will always be needed, forever.  So there's no reason
  35. not to release any given program as PD instead of GPL.
  36.  
  37. >Explaining the intricacies of how to protect themselves against
  38. >bait-and-switch tactics possible for PD (but, to my knowledge, never
  39. >used) just about requires teaching them software engineering.
  40.  
  41. No software distribution scheme will eliminate fraud, period.
  42. Remember that we're talking about a customer who asks for source.
  43. Misrepresenting delivered software, including PD software, is fraud.
  44. Anyone willing to act illegally in this way (fraudulent PD delivery)
  45. will also be willing to act illegally in another way (GPL breakage).
  46. GPL does not have an advantage over PD in this way, specifically
  47. because PD binaries don't land on anyone's computer unrequested.
  48.  
  49. >Simply put: given GCC, a GPL-protected C compiler, and "PDC", a (so
  50. >far mythical) PD C compiler, a user knows more about GCC than PDC...
  51.  
  52. So the GPL is a known quantity, once you know it.  This is unique?  If
  53. your praise of GPL-covered programs is that their licensing terms are
  54. consistent, that praise is awfully faint.
  55.  
  56. >I wasn't saying the GPL is a condom.  What I was saying is that because
  57. >the GPL will ensure that g77 will always be distributed source-available
  58. >(which PD would not), it is far less likely it will be made the
  59. >carrier of a virus.
  60.  
  61. No way.  It's not the GPL that protects you, it's source distribution
  62. that protects you.
  63.  
  64. Once you've decided to distribute a binary, you're open to virus
  65. infection, GPL or no.  Virus creation is illegal!  Once a virus writer
  66. has decided to commit an illegal act, do you really think he would
  67. give a moment's consideration to the GPL?  Not a chance.
  68.  
  69. >How does violating the terms of the GPL avoid a big fine?
  70.  
  71. If he were to distribute the source to his derivative work (e.g.
  72. the "g77+virus" work), he would finger himself as the virus maker.
  73. And he's off to court.  He wouldn't ever do that.
  74.  
  75. >Now, g77 is a GPL-protected Fortran compiler.  A virus writer cannot
  76. >legally distribute a binary of g77 without the source ...
  77.  
  78. As if a virus writer strives to live within the law.  Hah.
  79.  
  80. >or the copyright owner of g77 can sue even if laws are insufficient
  81. >to attack the virus writer on the basis of having disseminated a virus.
  82.  
  83. But those laws _are_ quite sufficient -- if the virus writer is
  84. identified (which he almost certainly will not be, since he won't
  85. do anything as stupid as publishing virus-infected sources).
  86.  
  87. >Further, identifying the virus writer is much easier since each
  88. >distributor of the g77 binary is legally required to distribute
  89. >source as well, so the sources can be used to track how and where the
  90. >virus appeared.
  91.  
  92. But all the hypothetical virus writer need to is upload the binary
  93. to (say) a BBS.  What will the copyright holder do -- sue the BBS
  94. owner?  No way.  So the virus writer gets off scot free.
  95.  
  96. >Further, the customers with the infected g77 can fairly easily
  97. >rebuild g77 from sources patched to not include the virus once info
  98. >on the virus gets out.
  99.  
  100. That's also true of source-available PD.
  101.  
  102. >It is much easier to tighten the distribution channels for the GPL
  103. >stuff just by telling all ftp sites & such to always compile from
  104. >scratch or not distribute binaries [...]
  105.  
  106. The FSF can't do that.  The GPL does not prohibit binary distribution,
  107. and FSF can't go back in time and change it just because a virus
  108. writer throws a monkey wrench in the current plan.  Or are you now
  109. forced to resort to a hypothetical GPL 3, which won't cover existing
  110. programs anyway?
  111.  
  112. >>You do your argument a disservice by bringing up such irrelevancies
  113. >>as viruses.
  114. >
  115. >Viruses are hardly irrelevant to the business world.
  116.  
  117. But they are not relevant to PD vs. GPL (at least in my opinion),
  118. and that's what I meant.
  119.  
  120. >End-users also want to be sure they can get support for their
  121. >software.
  122.  
  123. >They might get quite annoyed if they find a bad bug in, say, f2c+PDC
  124. >and discover that the binary they're using for their particular machine
  125. >has no source (or they can't find it) ...
  126.  
  127. Anyone who loses source code is in trouble, GPL or no.  After all,
  128. even GPL programs have local fixes, and those fixes aren't always
  129. propagated, in particular if the resulting binaries are for local use
  130. only.
  131.  
  132. >At the moment, I'm unaware of a more effective means for
  133. >disseminating knowledge widely in a form that also serves as a useful
  134. >tool, and that also invites dissemination of fixes and enhancements
  135. >to that knowledge that, themselves, make the tool even more useful.
  136.  
  137. That's great for the tool, but not necessarily for people who'd
  138. want to take pieces of the tool and use them in ways not approved
  139. by RMS.
  140.  
  141. >In practical terms, that's the difference between PD and GPL.  Sure,
  142. >if the PD source has been distributed even once, _theoretically_
  143. >anyone can get at it, but that assurance is not practical in today's
  144. >society -- many people _will_ end up with the binary [...]
  145.  
  146. Well, there's the core disagreement.  I don't see the world that way.
  147.  
  148. >Please hurry up and write a high-quality PD C compiler and distribute
  149. >it widely with sources.
  150.  
  151. I'm working on it.  Really.
  152.  
  153. >Of course, once the PDC comes out with better optimization than GCC,
  154. >there's every reason to expect that people will learn from PDC how
  155. >to add those optimizations to GCC [...]
  156.  
  157. What GCC and (in particular) G++ need are a more rational internal
  158. structure and a complete rejection of block-copy-as-reuse-method,
  159. with the result of a lower maintenance load.  Optimization is gravy.
  160. -- 
  161. Chip Salzenberg at Teltronics/TCT  <chip@tct.com>, <73717.366@compuserve.com>
  162.   "you make me want to break the laws of time and space / you make me
  163.    want to eat pork / you make me want to staple bagels to my face /
  164.    and remove them with a pitchfork" -- Weird Al Yankovic, "You Make Me"
  165.