Folding Forum

...surely so long as the clients are not included in the download package, but downloaded directly from Stanford during the install routine, then this script would not be in violation of the EULA?

Not true. Read the EULA again. It was changed a while back.

About Ivoshiee, the obvious answers are not always the right ones. Did you consider that maybe Ivoshiee was grand-fathered in prior to when the tighter restrictions were added to the EULA, or maybe that he successfully lobbied PG for that permission afterwards?

I'm not saying that CadBane couldn't use the same methods as Ivo, I'm just saying that CadBane doesn't have the same standing in the community as Ivo. CadBane would still need to earn that permission.


P.S. I don't speak for Pande Group. But I am speaking from years of experience. I don't know how rigourous or not they would be with CadBane's group. I just know it's not a walk in the park. I wish him the best of luck with it. We can always use fresh blood and fresher tools.

Well we the developers are willing to provide all the support necessary. The Clients and cores are all stock Stanford files the only difference is the GUI that is used. Technically everything would report and give the same problem which it does. And yes I do not believe we have any intention of abandoning out project at all in fact it make folding to easy to abandon and we would get a lot of hate mail if we stopped. in 5-10 years who knows I may actually be helping my friend program this. Every little feature that is in F@H has its own checkbox or radio button or textbox in the configuration panel. We have gotten a lot of grace for our GUI especially from the Farmers out there because it make maybe a setup that takes usually 30-60min down to about 3-5min.

"Use of other software to connect to the Folding@home servers is strictly prohibited. This prohibition includes 3rd party installers which download directly from Stanford web sites, unless written permission is granted from Stanford University. "

Sounds to me like you'll need to develop a really good tool and then request permission for it from Vijay/Stanford.

If that is the case, then I hope you develop a great tool for the F@H community and Stanford look upon it kindly

*Add: oh yeah, just don't distribute it so that the default is for a particular team or via unlicensed torrents/without user's permission...

If it does end up passing I dont see us stopping development of the GUI (Basically what it is) as long as there are still people folding who want simplicity with their setup. Its basically all of folding@Homes folding strategies packaged into a very need and simple (yet detailed and feature packed) GUI. It works as Stanford originally intended F@H to do but we give it a GUI update. Jedi can be hard to budge when he like a system but given enough prodding, and this is what you have to do, or facts you can make him budge. Its just exhausting. The Tracker contains over 3000 lines of code. Even if we dont get the support now we will still keep developing in the hope of one day getting a good enough program that Pande will approve its use.

CadBane wrote:Joe I hope I have found the right place to see if it is ok to do what we are doing with a 3rd party Interface called FAH GPU Tracker V2 which pretty much fills the bill for what the quoted is covering. The Tracker was designed go give the utmost simplicity in setting up the clients for GPUS (GPU2 & GPU3) the cpu and CPU SMP system. We came up with this system after playing around with folding@home learning everything we could for about 2 years and then making a GUI with a Status monitoring system as well as a configuration panel with everything you could ever imagine for setup of clients. We even have implemented a system for remote control of multiple systems such as farm that you can configure them all by use of a web xml file. the system has been tested to work. But the client would have official F@H files in it such as the cores and clients which to use we will need some kind of permission from Stanford. The main thing we have done is to program and create an all around monitoring, configuration and for the most part Noob Friendly setup system. I would like to talk to you more about it, If you would be willing to talk could you please PM me or tell me in this topic?

All core and client files are stock and exactly the same as distributed from Stanford. All that is added is a smart GUI for management.

You quoted me with this message?

Do you want to put on the same level something I could wip together in a day to the project I was undertaking? You realise my project's base code consisted over 40.000 lines? It''s easy to steal something here and there, I gave people source code for programs like your's years back with the notice that it's useless as you can't actually use without breaking EULA. You have not included a single bit of functionality in your gui which I have not given out code to do just that in the past, not a single bit. Not saying you copied it, but you could have, I'm saying it's in no way new or inovative.

Now I stopped working on it since I got ZERO reply in this thread ( edit: reminder this quote is moved from another thread about standardizing the client/core's interface ) from the one person who might be able to fix a couple of small things so a proper 3rd party gui could work WITHIN the boundries of the EULA, I stopped because even after I had gotten permission to work on it and being promised some level of coorporation I could not get the mpich installer to be distributed with another packager so I could run it silently like deino. I stopped because all in all I felt like I was alone fighting an uphill battle.

And that was even after I 'passed' the approval rate.

It's btw EASY to not include the clients but download them, it really is so why you're breaking EULA for this is beyond me! Also it's against EULA to write to configuration files directly, which I'm suspecting is how you control the clients. And AGAIN, it's not impossible to stay within the EULA and use the programs own ability to generate it's configuration file.

Please next time you quote me, make sure you make sure why you quote me, as it almost seemed as if you wanted to put your project at the same level as mine. Which it is clearly not, for two reasons, one of which is in your favour! Your solution works, well if you don't consider breaking EULA's important, mine which is limited by such agreements has difficulties with very specific aspects ( installation of mpich package mostly, then the project's monitoring part was getting to big for it's intend and I think HFM.net is doing almost everything I wanted to do and a better alternative, then the hw recognition engine was not fail proof and I had a project issue where my web based installer didn't include the needed references ).

All in all, I think I have less work fixing what is wrong with my project, then you would have by rewriting your gui to adhere to official EULA.

Edit:

I have to come clean, it's not that easy to download the clients ( as evident with the MPICH package, yes it's easy to download but not to automate the setup procedure ). There are catches to every approach, but it's most certainly doable which is enough of a point to make.

Look, I like 'your' idea, I like the enthousiasm, I envy it even since I lost mine abit.

Maybe I should renew the project, make it active again, and work around the deino issue by including an smp client myself? That's your approach it seems, and you think it will work.

Or maybe, and that's more likely as it is what I been doing: waiting for the next SMP client and next GPU client, hoping that some of the ideas did get carried over, hoping that it will be possible to use a framework such as mine to install/control and monitor those client's without breaking EULA. Well I'll leave the monitoring to HFM.net, as long as I can provide a gui for control that's fine with me and so much easier as well ( monitoring current clients is HARD, not to get basic info that's easy but to get extrapolated info that's hard ).

What going to do is have Pande take a look at it and if its like I could possibly get the permission and if not then I will ask what kind of changes we can make to it to bring it to where they would like it to be. Basically a refine present how it it kind of thing. Sorry for not originally understanding you post. I hope you can forgive me. When we originally embarked on this project we did not know it was against EULA, but since I found out I am taking steps to get info on what we need to change from the heads or get the permission to do what we are doing.

@ MtM, et al, the MPICH is going away when all of the a1 and a2 work units are done. And then I guess the SMP installation will be very similar to installing the CPU client.

Might be time to dust off some of that software.

Good luck

No actually I don't mean that, and I'll tell you why. ( edit: ok offcourse I sound like an ass and I don't actually hope it either in the sense that I would like no gui to be given some needed permissions ( which would have went further then downloading the client from a webpage ).

I spend much more time and effort into this then you could ever have, evidencing by your lack of knowledge about important aspects already. I don't think you will get permission, well offcourse you might as finstall also has it as did I. But I hope you're not going to profit from an longer lasting effort then your own, for I would sooner come back and fix my minor problems ( which they are, since if you can make an installer which works I sure can as well as it would mean some more coorporation from Stanford and that was the only thing missing ). And I feel I earned that right, allot more then you have.

On the other hand, I have no problem with making everything open source, most of the code needed I have already made public more then once. Maybe you would like to join an open source effort into making a gui which can do hw detection on all platforms ( .net on windows / mono on linux/osX ), install clients appropiate for the hw ( with preconfigured profiles specific for that hw ) and be able to monitor them ( through another open source project ) and control them using a central gui?

How does that sound

7im wrote:@ MtM, et al, the MPICH is going away when all of the a1 and a2 work units are done. And then I guess the SMP installation will be very similar to installing the CPU client.

Might be time to dust off some of that software.

as it is what I been doing: waiting for the next SMP client and next GPU client

Sometimes changes take time...

All I 'wanted' though was a responce to this thread( this thread = thread which was split off ) sooner then why it was resurrected now ( I only posted because of the quote ).

All the rest is old news anyway

CadBane wrote:<snip>The Tracker contains over 3000 lines of code. Even if we dont get the support now we will still keep developing in the hope of one day getting a good enough program that Pande will approve its use.

Who is this 'we'? Can you show me some of your source ( or all? ) I'm curieus, very curieus as you might guess

Btw another reason I didn't like this forum was that I couldn't fix the text box scroll to the end so I couldn't multi quote or make allot of edit's or a long post in one haul.

Edit:

To be clear, I know I sound like an ass but you have to show me you're not some snot brat who wants to walk away with the 'glory'', you got to earn that ( not by personality btw but by actually doing things )

So I'm curieus about your code, show me so I can check against know projects and compare how simular they are. Or show me to impress me, or even just to take away any suspicion and proof to me that you're really addicted to this and have the skills needed to get things done! Because if so I will expand your code base with what I know, there might be more things besides the EULA you missed and if you're so enthousiastic and capable it's the dutie of those who can help to help isn't it so?

Im not the coder there are three of us who work on the project. I am also working on trying to get exactly what they would like us to do to bring it within the EULA. Currently one of our developers is MIA as a hard drive died on him. I am getting ready to take a trip my parents are dragging me on before I go to college. But we aren't ready to release code just yet if we do, we are fixing numerous bugs and adding a feature or two to the UI.

There is no shame in showing bugged code when trying to get approval, and approval is earned.

Edit:

Just to summarise, so far you will not name the person's responcible for the actual programming, you are reluctant to talk about source code and then expect us to accept your bid?

3000 lines of code is needed to talk to a console client through standardin, just to configure the client through a gui without breaking EULA

get your coders in this forum

Please wait until we have a we have an EULA compliant system. I am trying to get him to do it slowly so he doesnt yell at me like crazy. And I have named him just not in this thread.

Ok I'll wait.

I should have said something diffrent though, get your coders in this forum, and make a new thread? I responded to your quote of me but you're mostly discussing breaking EULA instead of technical issues which should belong in this thread. That's what my reference to the code needed to configure a client externaly was for.

So maybe your subject deserves it's own thread.

I was posting to try and find out how to get the permission we needed and when I got asked questions I answered them best I could. I am currently waiting for Pande to respond to ToTOWs message as he has been helping me through the process.

WOW, a pissing match and I'm not one of them .

C'Mon, as long as Science prospers, does it matter who/how/why?