robert@isgtec.UUCP (Robert Osborne) (08/03/89)
Some comments/questions:
1) FSF does not have to worry about the "machine-readable" problem since
if the program being distributed in punched_card|newsprint|$10000
dollar CD|etc. is useful it only has to be "machine-read" once.
Thereafter FSF or somebody equally philanthropic :-) can distribute
in an "approved" format. One does not have to get the source of the
new programs from the developer.
2) What if I think up some new, neat-o-keen, idea|algorithm (Fat Chance :-)
*patent* it and then use BISON/G++ to implement it, I then distribute
my source. Would not any future distribution of source be made
illegal by my patent. Or would I lose this patent (by my subsequent
distribution of same source.). Am I stupid/naive for asking
this question?
3) What ARE the *better* ways of making money from our software (assuming
we don't sell it, but instead distribute it).
4) I'm a software hoarder (oh no!) and I work for a company (see .sig)
that provides hardware and software to create 3d images from CAT scans.
(simplified version of what we do, *I disclaim*).
The development required from my department, has so far taken
approximately 100 man months of effort.
(This is only a small section of our company the whole effort is much
larger) The users of out product are radiologists and surgeons.
Verrrry few of these people are computer literate,
(with some exceptions), nor do they desire to become so.
Where would hospitals (society) find 100+ man months of *volunteer*
FSF type of help to create, support, maintain such a software
project? How does this kind of project fit into the FSF world
view?
Rob.
(This posting DOES NOT reflect the views, opinions, or version of reality
of my employers)
--
Robert Osborne ...uunet!mnetor!lsuc!isgtec!robert
...utzoo!lsuc!isgtec!robert
ISG Technologies Inc. 3030 Orlando Dr. Mississauga. Ont. Can. L4V 1S8dsill@ark1.nswc.navy.mil (Dave Sill) (08/04/89)
In article <115@isgtec.UUCP> robert@isgtec.UUCP (Robert Osborne) writes: >Some comments/questions: > : >2) What if I think up some new, neat-o-keen, idea|algorithm (Fat Chance :-) > *patent* it and then use BISON/G++ to implement it, I then distribute > my source. Would not any future distribution of source be made > illegal by my patent. Or would I lose this patent (by my subsequent > distribution of same source.). Am I stupid/naive for asking > this question? Your patent would be available to anyone wanting a copy. If you want to keep it secret you'd have to make it a trade secret. (This is what Coca Cola uses to protect its formula.) You'd have to make everyone that needed to know the algorithm sign a non-disclosure agreement. Of course any reasonably knowledgeable person could disassemble your binary to discover the algorithm; just as chemists could theoretically reverse-engineer Coke's formula. I guess you'd also need to copyright your algorithm, but I think there are circumstances under which copyrighted material must be made public. >3) What ARE the *better* ways of making money from our software (assuming > we don't sell it, but instead distribute it). I believe RMS' idea is that programmers should earn money doing consulting and supporting. A possible scenario would be that your company would pay you to write the software (which would be copylefted). They'd distribute it; possibly bundled with a maintenance agreement or warranty which would allow them to charge whatever they want for it. Their customers would have access to the source, so they would have the option of purchasing maintenance or support elsewhere. The "danger" in this scenario is that your company would be required to give its software to its direct competitors. This is offset by the fact that the competitors would also have to give your firm any enhancements or fixes they distribute to their customers. Another offsetting factor is that your firm, as the developer of the software, would get a big jump on the competition in the span between its first release and the time any competitor would be able to distribute an enhanced version. And of course, by that time your firm would probably already be shipping their next version. >4) I'm a software hoarder (oh no!) and I work for a company (see .sig) > that provides hardware and software to create 3d images from CAT scans. > (simplified version of what we do, *I disclaim*). > The development required from my department, has so far taken > approximately 100 man months of effort. > (This is only a small section of our company the whole effort is much > larger) The users of out product are radiologists and surgeons. > Verrrry few of these people are computer literate, > (with some exceptions), nor do they desire to become so. > Where would hospitals (society) find 100+ man months of *volunteer* > FSF type of help to create, support, maintain such a software > project? How does this kind of project fit into the FSF world > view? See my response to #3. Nobody's suggesting that programmers quit earning money for writing software. I'd suspect that in a vertical market such as 3D CAT imaging, it wouldn't matter a whole lot if your company freely distributed its sources. Who would your customers buy support/maintenance from? At first, your firm would be the only choice. Is there any proprietary hardware bundled with your products? If so, what good would your software do your competitors, especially considering that they'd have to "show you theirs" after you "showed them yours"? >Robert Osborne ...uunet!mnetor!lsuc!isgtec!robert > ...utzoo!lsuc!isgtec!robert >ISG Technologies Inc. 3030 Orlando Dr. Mississauga. Ont. Can. L4V 1S8 -- Dave Sill (dsill@relay.nswc.navy.mil)
jym@APPLE.COM (08/05/89)
> Where would hospitals (society) find 100+ man [sic] months of *volunteer* > FSF type of help to create, support, maintain such a software project? > How does this kind of project fit into the FSF world view? What percentage of these 100+ person-months would you estimate has been dedicated to retracing others' steps? Chances are, like most software projects, yours has spent a lot of time and money reinventing wheels, or buying them. And let's not forget how exciting it is to reinvent wheels, or how much society advances while wheels are being invented. The way I see it, the more software we make free, the fewer resources we have to waste on duplication of efforts. And that frees us up to work on the Next Big Thing. And the next, and the next, and the next . . . <_Jym_>
julian@uhccux.uhcc.hawaii.edu (Julian Cowley) (08/05/89)
In article <115@isgtec.UUCP> robert@isgtec.UUCP (Robert Osborne) writes: > Where would hospitals (society) find 100+ man months of *volunteer* > FSF type of help to create, support, maintain such a software > project? How does this kind of project fit into the FSF world > view? I doubt that you could find volunteer help for a project of that size, but an organization such as the American Medical Association might be able to provide funds for one. Once the source is available to hospitals, consulting companies could be hired to do custom work on the system if the hospital wanted. julian@uhccux.uhcc.hawaii.edu uunet!nosc!humu!uhccux!julian julian@uhccux.bitnet University of Hawaii at Manoa
mellon@zayante.pa.dec.com (Ted Lemon) (08/05/89)
The hospital doesn't have to find the volunteers. They will wind up paying for the software in the cost of the hardware. The case where you have to buy hardware in order to use a piece of software is a classic situation in which a copyright doesn't make a big difference anyway. Also, the GNU project has been going on for several years now, and lots of people have donated time. I suspect that more than 100 man months of effort are donated every year. If I thought it would materially advance medical technology, I'd probably be more than happy to do volunteer work on a cat scanner program. Imagine if the next generation of cat scanner didn't require a complete rewrite of the previous generations code. Wouldn't technology progress a little faster? It probably wouldn't take 100 man months to make the software work. _MelloN_
peter@apexepa.UUCP (Peter Palij) (08/05/89)
>The "danger" in this scenario is that your company >would be required to give its software to its direct competitors. >This is offset by the fact that the competitors would also have to >give your firm any enhancements or fixes they distribute to their >customers. Another offsetting factor is that your firm, as the >developer of the software, would get a big jump on the competition in >the span between its first release and the time any competitor would >be able to distribute an enhanced version. And of course, by that >time your firm would probably already be shipping their next version. In my experience, there are very few firms which have the *management* capacity to succeed under such an open senario. The problem is that the infrastructure required to sell, deliver, maintain, document, etc. a major piece of software causes "the managers" to forget about the next rev of the software. Often management's focus is so diverted by these "building a major company" issues they lose sight of the reason for their success, their customers and third party developers. Engineering in these companies is given carte blanch (after all, the success of this first product proves they walk on water and know what they're doing), whereupon engineering proceeds to splinter into 2N projects (N == # of engineers) of which only a few actually may relate to the current business. The competition, which is usually a small, focused start-up (or "tiger team" in a large company) then turns around and begins to eat into the first company's market. (Yes, I know there are significant exceptions, that doesn't deny that this is very normal senario.) So what is a rational company to do if this is the norm and it is a normal company run by normal managers? It makes the technology proprietary and protects that technology any way it can (after all, that's what all the major companies do). It certainly has NO interest in making the competition's life easier by providing the keys to the kingdom. (Anyway, it is always easier to call a lawyer than to question your basic assumptions about the way the world works.) Personally, I firmly believe that the original senario is a doable, and in fact a very profitable, approach to the software business. But because it assumes a non-normal management perspective (the urge to "build a major company" replaced by the urge to build a technologically agile, long-term profitable company), it is *very* unlikely to become the normal way of approaching the software business. -- ----------------- Peter Palij uunet!apexepa!peter Apex Software Corporation peter@apexepa.uucp Phone: (412) 681-4343
phssra@mathcs.emory.edu (Scott R. Anderson) (08/07/89)
In article <55@ark1.nswc.navy.mil> dsill@relay.nswc.navy.mil (Dave Sill) writes: >In article <115@isgtec.UUCP> robert@isgtec.UUCP (Robert Osborne) writes: >>3) What ARE the *better* ways of making money from our software (assuming >> we don't sell it, but instead distribute it). > >I believe RMS' idea is that programmers should earn money doing >consulting and supporting. Generally, programmers should earn money for any work they do, which would include writing software from scratch, not just supporting it. For example, for a small software project, a hospital would hire a programmer and pay them for the amount of time they put in. The hospital gets what they pay for, i.e. a working program, and any software produced is then freely available to others. For a large software project such as being discussed here, a National Institutes of Health grant or some similar funding source would be required to pay the programmers who write the software. This happens all of the time at medical schools: many Radiology departments are quite busy writing their own software, using government grants. * * ** Scott Robert Anderson gatech!emoryu1!phssra * * * ** phssra@unix.cc.emory.edu phssra@emoryu1.bitnet * * * * * ** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *