> -snip-

> hou've catched a cold :-) ?


>>I simply don't believe that keeping you're own source code of some classes protected would benefit you're business. I've lots of custom classes and I freely give them to some colleages to play with them. They may add some improvements which would be a benefit to yourself. If i don't spread my classes all my colleages would be busy reinventing the wheel. Of cource i won't give them source code of whole commercial deployed programs but i think you can improve you're business by thinkinh this way. One good example is the LINUX OS.


>Call it selfish; call it a reason to hire me as a consultant. I've developed a lot of code, mostly wrappers on APIs, classes that shield VFP app developers from constantly being aware of the low-level underpinnings of my setup and configuration management environmet and the like. I've discussed the theory behind a lot of what I do to manage installation and ongoing configuration and installation management. My clients have gotten the benefit of the development I've done, implementing application hives, distributed upgrade implementation, network configuration and station management. I've looked at releasing some of the toolkits on a shareware basis; my experience with shareware in the past has been that it never covered the cost of what I had to do to support it.

That's why i don't have anything posted yet here on the UT. Everything a made is strongly interated with my framework. Picking something out of it, would raise a lot of questions. I didn't have documented all my classes so it would be a tremendous job for a moderate programmer to figure out how it works.

I did choose to ive my code to a few selected Colleagues which do have my support. I simply cannot support hundreds of programmers.

>I'm perfectly happy to help someone with advice and some support code, and there's plenty of stuff that I give away, but I'm not willing to either try to make a canned commercial product out of it, or to release stuff that's so complex that there's no chance of someone figuring it out without a lot of help. A fair percentage of the people who've played with CLSHEAP and API_APPRUN have needed some help figuring them out, and they're easy, hiding most of the gory details from the exposed surfaces of the classes. The idea of releasing them as source was so that once the functionality exposed by the class was used, you could go under the hood and play around. I'm thrilled to death to get someone saying 'Hey - I like what it does; here's something that could make it better!' That kind of feedback and cooperation gives me warm fuzzies, and results in enhancements to the code. I get infinitely discouraged when, after releasing it, I get a message saying "Hey - since you figured this out, figure out how to make it do what I want it to do." The idea was to first make some functionality available, and to explain how it works; to serve as a springboard for someone to delve into a couple of areas that I find absolutely fascinating, process and memory management.

I fully agree.

>Everything I release here on UT I release as PD code - you're free to use it; I ask that you at least give some attribution of the source in your comments in code. Microsoft gives us the source for various wizards, and contrary to common belief, does clearly indicate what can and cannot be redistributed in the REDIST.TXT file. The best of the third-party tools that I've used, things like SDT, MaxFrame Pro, the late Tom Rettig's TRO, all came with source, not only for what you were intended to put into your application, but also for the tools used to help put things together to build your app. These vendors put some restrictions on redistributing some of the tools that they provide. I appreciate having the code to play with, and am more than happy to comply with their wishes about redistribution. They didn't have to provide us with the source to the tools, but they felt that making that code available to the developers who paid for it that much more useful, and served as a guide to what really went on in the guts of the product.

As a matter of fact i do think they had to include the sourcecode. If they didn't, they had less chance to sell the product because its a tremendous added value to the developer. Like Doug mentioned, I hesitate to buy something without sourcecode.

>Take a look at REDIST.TXT; it clarifies many of the issues about what Microsoft feels that you can and cannot redistribute with your application.

I just did and the wizards themself (app) and some of them in prg form are on this list, So they may be distributed. My problem with such lists is that they could become incomplete (with the adds of servicepacks and other 3rd party add-ons) leaving you with the question if you can or cannot distribute this. I like to see it just the other way arround.

for example: GenDBC.prg is NOT on this list NOR CpZero.prg AND Filer.scx. Can i distrubute them with my applications? I'll say: yes, That's what the're made for.

This leaves us programmers in confusion. That's why i said: If there is no clear statement that you can not distribute it i'll distribute them when i need it. The company of who sells the product 'll have no aruments to sue me for this matter: they had to include a clear statement that you cannot redistribute them.

I hope i did clarify myself in my standpoint,

Regards,

Walter