How to determine if a file is redistributable

As all of you know, there has been some discussions over the re-distributability status of Third Party Files.

It has been suggested to find a way to make .script developers responsible about the use of Third Party Files embedded into .scripts, from which it derives the need to help them in determining whether a file or package is re-distributable under the new, proposed policies.

Let me be very clear about this, to avoid any misunderstandings, we are talking here in the future tense, no Rule has been changed till now, current Rules can be found here:
http://www.boot-land...?act=boardrules

They are subject to discussion, as they have always been, here:
http://www.boot-land...?...opic=82&hl=

Let's start from the following, integrally copied from the closed thread here:
http://www.boot-land...?...=3124&st=50

I favore the system of 'good fath', we host/embed software that is eighter share- or freeware and is therefore intended to be distributed and assume in good faith that the developer will welcome this promoting of his software.

Good!

This applies to a large part of freeware and shareware.

Still, it does not apply to the freeware or shareware that explicitly denies re-packaging or re-distribution.

To continue on the example posted about Foxit PDF-Reader:
http://www.boot-land...?...=3197&st=12
it's hard to use the "therefore" as you did or sustain that you, in good faith, presumed that they will welcome this promoting of their software:

6. REDISTRIBUTION: You can not redistribute Foxit Reader under this agreement, please contact sales@foxitsoftware.com for information on our free redistribution agreement.

as I see it the .script developer should ask for re-distribution agreement, if he wants to embed the file into his .script.

As said, I think that most Freeware/Shareware Authors or Rights Owners will graciously release this permission, and the more will do with Winbuilder everyday gaining popularity.

So, I think we can start to draw some "tentative" lines:
1) Software that needs any form of registration to be downloaded from the original site CANNOT be embedded
2) Software that cannot be downloaded from the original site CANNOT be embedded (say it's Warez )
3) Software that explicitly prohibits re-distribution or re-packaging in its EULA or homepage CANNOT be embedded
4) Any software that does not belong to any of the above categories can be assumed to be freely redistributable "in good faith" and thus CAN be embedded
5) Any software that cannot be downloaded from the original site, but that was at one time available for public download, provided that it's EULA does not explicitly prohibits re-distribution or re-packaging, CAN be embedded
6) Any Software CAN be embedded as long as the .script developer obtains a re-distribution agreement from software Author or Owner

The above should cover most of the situations, with the exception of:
Any Freeware (NOT Shareware, NOT Commercial Software) whose Author is not anymore reachable to ask him for a free re-distribution permission (say it's FREE Abandonware)

Whenever any software is embedded, Nuno will provide a way within Winbuilder to actually list the embedded files, and a way to credit the Author/Owner in a perceivable manner for the end user of the .script.

The same information needs to be included in the download description or in the post (see proposed amendment to Rules #1.a).

What do you think of this?

jaclaz

P.S.: This thread is intended only as a way to create guidelines for as much as possible easily understand what will be acceptable and accepted to be hosted directly (as is) or indirectly (embedded into .scripts) on boot-land servers.
If you want to discuss the way the new policy will be coded and eventually enforced, please use this thread:
http://www.boot-land...here-t3244.html

So, I think we can start to draw some "tentative" lines:
1) Software that needs any form of registration to be downloaded from the original site CANNOT be embedded
2) Software that cannot be downloaded from the original site CANNOT be embedded (say it's Warez )
3) Software that explicitly prohibits re-distribution or re-packaging in its EULA or homepage CANNOT be embedded
4) Any software that does not belong to any of the above categories can be assumed to be freely redistributable "in good faith" and thus CAN be embedded
5) Any software that cannot be downloaded from the original site, but that was at one time available for public download, provided that it's EULA does not explicitly prohibits re-distribution or re-packaging, CAN be embedded
6) Any Software CAN be embedded as long as the .script developer obtains a re-distribution agreement from software Author or Owner

This meets exactly my opinion.

I think it's very descriptive, and does not leave any question open.

EDIT:
To be complete, maybe we add:
7) Any Software CAN be embedded which is written by the .script developer

Peter

@Psc, I did not request your permission to encoded a certain program you've contributed. These details should not be overlooked, I'm speaking of the C proof fo concept you ported to Delphi recently. Lot's of nice comments don't make up for, may I use the file? ..
regards, -t

@Psc, I did not request your permission to encoded a certain program you've contributed. These details should not be overlooked, I'm speaking of the C proof fo concept you ported to Delphi recently. Lot's of nice comments don't make up for, may I use the file? ..
regards, -t

No, I did not port.
I used the description what's happening to write my own code.

Here some parts.

function hashIt(const Input: DWORD; var res: array of Byte): boolean;

...

begin

...

  if CryptAcquireContext(@cryptProvider, nil, nil, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT or CRYPT_MACHINE_KEYSET) then

  begin

	if CryptCreateHash(cryptProvider, CALG_MD5, 0, 0, @handleHash) then

	begin

	  if CryptHashData(handleHash, @nulls, sizeof(nulls), 0) then

	  begin

		if CryptHashData(handleHash, @input, sizeof(input), 0) then

		begin

		  if CryptGetHashParam(handleHash, HP_HASHVAL, @dataHash[0], @lenHash, 0) then

		  begin

			for i := 0 to lenHash - 1 do

			begin

			  res[i] := dataHash[i];

			end;

			Result := true;

		  end;

		end;

	  end;

	  CryptDestroyHash(handleHash);

	end;

	CryptReleaseContext(cryptProvider, 0);

  end;

...

  for i := 1 to ParamCount do

  begin

	line := AnsiUpperCase(AnsiReplaceText(ParamStr(i), '/', '-'));

	If Debug then Writeln(Output, 'Parameter: ' + line);

	if line = '-D' then

	  debug := true

	else if line = '-W' then

	begin

	  pnpKey := cwPNP;

	  setupKey := cwSetup;

	  signingKey := cwSigning;

	end

  end;

  If Debug then Writeln(Output, 'RegOpenKeyEx ' + pnpKey);

  res := RegOpenKeyEx(HKEY_LOCAL_MACHINE, PAnsiChar(pnpKey), 0, KEY_READ, regKey);

  If Debug then Writeln(Output, 'res ' + IntToStr(res));

  if res = ERROR_SUCCESS then

  begin

	If Debug then Writeln(Output, 'RegQueryValueEx ' + cSeed);

	res := RegQueryValueEx(regKey, cSeed, nil, nil, @seed, @len);

	If Debug then Writeln(Output, 'res ' + IntToStr(res));

	RegCloseKey(regKey);

  end;

// build hash

  if hashIt(seed, hash) = true then

  begin

// write 'privateHash'

	If Debug then Writeln(Output, 'RegOpenKeyEx ' + setupKey);

	res := RegOpenKeyEx(HKEY_LOCAL_MACHINE, PAnsiChar(setupKey), 0, KEY_WRITE, regKey);

	If Debug then Writeln(Output, 'res ' + IntToStr(res));

	if res = ERROR_SUCCESS then

	begin

	  If Debug then Writeln(Output, 'RegSetValueEx ' + cPrivate);

	  res := RegSetValueEx(regKey, cPrivate, 0, REG_BINARY, @hash[0], sizeof(hash));

	  If Debug then Writeln(Output, 'res ' + IntToStr(res));

	  RegCloseKey(regKey);

// write policy

	  If Debug then Writeln(Output, 'RegOpenKeyEx ' + setupKey);

	  res := RegOpenKeyEx(HKEY_LOCAL_MACHINE, PAnsiChar(signingKey), 0, KEY_WRITE, regKey);

	  If Debug then Writeln(Output, 'res ' + IntToStr(res));

	  if res = ERROR_SUCCESS then

	  begin

		If Debug then Writeln(Output, 'RegSetValueEx ' + cPolicy);

		res := RegSetValueEx(regKey, cPolicy, 0, REG_BINARY, @nulls, sizeof(nulls));

		If Debug then Writeln(Output, 'res ' + IntToStr(res));

		RegCloseKey(regKey);

	  end;

	end;

  end;

  If Debug then ReadLn(Input);

...

Peter

Your post answers any doubt with respect to my question. I was really greatfull to receive such prompt assistance with that particular problem.

And no, port is not accurate at all as your exe preinstalls the correct hash vs. a fix on the fly.

Your post answers any doubt with respect to my question. I was really greatfull to receive such prompt assistance with that particular problem.

And no, port is not accurate at all as your exe preinstalls the correct hash vs. a fix on the fly.

Sorry, I forgot to say:

Yes, you may use

Peter

As all of you know, there has been some discussions over the re-distributability status of Third Party Files.
1) Software that needs any form of registration to be downloaded from the original site CANNOT be embedded

Unfortunately, it's not clear enough
Let's suppose webmaster of some web-site had in mind following schema:
Home--->Registration--->EULA--->Download,
but using direct link to download page allows downloading without Registration and acceptance of EULA.
This is true for many web sites and this creates a problem.
One position is that you could obtain the direct download link from somewhere (search angine, etc.).
Another position is that the site should be used as designed.
jaclaz, your opinion?

Alexei
PS
It's pretty clear when downloaded file contains EULA and copyright notice, but what if it doesn't?

Well, if I hypothetically would want users of my app to register, I would make sure that the registration step could not be bypassed, nonetheless, in my opinion the Author of a software has all the rights to put ANY limitation to it's use as he fancies, and it is only a site programming error or misconfiguration that allows a (slightly) malicious user to download directly the app.

I would call this behaviour "cheating".

By the same principle, one could claim that a "warez" release (from which EULA and/or activation/validation has been hacked off) is legal because there is nowhere info about it.

Besides the fact that such an excuse (ignorance) won't be accepted in a Court, it surely cannot be invoked, from an ethical standpoint, by one of ours .script developers that all are (or should be) considered as "advanced internet users".

Just do a Google search for:
"parent directory" ghost.zip

does that mean that because a number of (unexperienced or illegal prone) web users have left some directories "open" you are allowed to get everything you wish from there?

It is just like your house, you may lock it's door when you go out or forget it unlocked, but the latter does not authorize me to get in and take whatever I like.

We could rephrase as follows:

1) Software that needs for which any form of registration is asked by the Author to be downloaded for it's downloading from the original site, no matter if the request can be bypassed by using direct links or any other workaround, CANNOT be embedded

jaclaz

Now, due to actual reasons I have a new question to be discussed here:

I'm working with VMWare Player script.

I currently included everything EULA concerning stuff into the ISO.

That causes a new 'EULA confirmation' on every boot.

It is easy to avoid this confirmation and to save some space in the ISO by

• Not copying
  • EULA.txt
  • EULA.rtf
  • richtxt32.ocx
  • richedt20.dll
• adding some lines to the script
  

  FileCreateBlank,%AppData%\VMWare\preferences.ini
  TXTAddLine,%AppData%\VMWare\preferences.ini,"pref.eula.0.appName = #$qVMWare Player#$q","Append"
  TXTAddLine,%AppData%\VMWare\preferences.ini,"pref.eula.0.buildNumber = #$q55017#$q","Append"

Legal? Grey? Illegal?

You have to consider, that I do not publish the result of the script, I only publish the script.

The result of the script (the ISO) is built by the distinct user.

Happy discussions!

Peter

You have to consider, that I do not publish the result of the script, I only publish the script.

It's very simple:

If you publish (only) script, you publish application files embedded in it.
Ergo, individual clients are required to accept EULA on every boot!!!

This is another example why application files should not be embedded in the scripts.

It is easy to avoid this confirmation and to save some space in the ISO...

You could save lot of space
if you UPX all application files before embedding!

I have done it and it works.

It's very simple:

If you publish (only) script, you publish application files embedded in it.
Ergo, individual clients are required to accept EULA on every boot!!!

This is another example why application files should not be embedded in the scripts.

A clear answer! Thanks.
But you misunderstood me:

In the script I do not include 'suspicious' files.

I only

• exclude some 'EULA' files
• include a flag that the EULA is accepted.

(My personal opinion is that I'm allowed to do so. But I want to hear different opinions, if any)

Peter

A clear answer! Thanks.
But you misunderstood me:

In the script I do not include 'suspicious' files.

I only

• exclude some 'EULA' files
• include a flag that the EULA is accepted.

(My personal opinion is that I'm allowed to do so. But I want to hear different opinions, if any)

Peter

Every installation of VMware Player requests EULA acceptance.

It's better to ask user to download and install (accepting EULA) VMware Player
and make script to collect necessary files from installation folder in host machine.

In that way you transfer legal issues to user and script is smaller.

Ill go with the Grey? Area.

if you UPX all application files before embedding!

Dont some applications have problems with UPXing

Dont some applications have problems with UPXing

This one not!

Are we talking about this EULA?:
http://www.vmware.co...ula/player.html

@psc
I guess that phox is referring to embedded files (which you do not provide, if I get it right)

.....
3.3 Restrictions. You may not (i) sell, lease, license, sublicense, distribute or otherwise transfer in whole or in part the Software or the Software License Key to another party; (ii) provide, disclose, divulge or make available to, or permit use of the Software in whole or in part by, any third party (except Designated Administrative Access) without VMware's prior written consent; or (iii) modify or create derivative works based upon the Software.
.....

whilst you are posing a slightly different problem, the way you setup the .iso, result of running your .script on files that the user must get by himself, can be "tweaked" into not displaying the EULA at every run.

The license is not very clear, but this:

9.1 Player:

Additional License Terms :

VMware grants you a nonexclusive, nontransferable license, without rights to sublicense, to (i) use the Software solely for your own internal information processing services and computing needs in connection with permitted uses of the Software; (ii) use the documentation accompanying the Software. Subject to the above, each copy of the Software may not be used by any other person, whether or not such person is employed by or otherwise associated with your entity. You may not share or use concurrently the Software.

Distributing the Software. If you are interested in distributing the Software electronically or via internal Web site, CD or other media, or are interested in placing a VMware provided logo on your printed material, please send a request to player_distribution@vmware.com and we will provide you with a copy of our distribution agreement for your signature.

So it is even possible (though cannot say how probable) that VMWare will allow a distribution of files embedded.

Now the point is, (I don't know how it works since registering is required to download the player), what happens with the downloaded file?
Is it a SETUP.EXE or .MSI that requires acceptance of the EULA before installing?
If yes, there is no need to have the user accept it every time.
Or does your .script use directly the downloaded file "by-passing" the EULA acceptance step set forth by VMWare?
How does VMWare Player works in a normal install?
Does it requires acceptance of the EULA every time it is run or just once?

If just once, you may make your .script require acceptance of the license just once at the time of build.

jaclaz

I have great difficulty to understand:

why we are insisting to expose Forum to legal vulnerability
and continue endless discussion about it, by allowing embedding
application files in the scripts.

In "normal" situation, every user is responsible for legality of use
of his computer and software in it.

Why in the case of scripts, we insist to deprive him from that responsibility
and transfer it on the Forum, unnecessary?

It's better to ask user to download and install (accepting EULA) VMware Player
and make script to collect necessary files from installation folder fro host machine.

In that way you transfer legal issues to user and script is smaller.

That's what I'm trying to do:

I have VMWare Player on my PC and I already accepted the EULA.

My question was:

If I transfer the 'EULA-accepted-flag' to the PE, is that legal / grey / illegal?

Peter

If I transfer the 'EULA-accepted-flag' to the PE, is that legal / grey / illegal?

Let user worry about that.

As far as he doesn't distribute final ISO, he is safe (I think).

I have great difficulty to understand:

why we are insisting to expose Forum to legal vulnerability
and continue endless discussion about it, by allowing embedding
application files in the scripts.

I warned about that from in the very beginning

In "normal" situation, every user is responsible for legality of use
of his computer and software in it.

1. It's a big question, when installation of 3rd party software happans:
- when it's embedded into the script
- when WB creates ISO
- during PE startup
2. It's not WB business to enforce 3rd party EULA at end-user side. I believe it's enough to include one disclamer that user accepts all EULAs related to all included software.
3. Regarding particular question of psc: just add checkbox to the script "Ask EULA confirmation at every run". Even better to make this flag global and check it in any script if necessary.
4. In general, with carefully written license you can transfer all responsibility for everything to the end-user. Extreme example: "You can not download any file from Boot-land web site, unless you verified that such download is allowed by the EULA related to that particular file. You agree to visit all related web sites before the download and verify that such download is not against your local law."

Alexei

It's a big question, when installation of 3rd party software happans:
- when it's embedded into the script
- when WB creates ISO
- during PE startup

Let me repeat for n-th time:

1. NO embedding of files in scripts, except author's children!

2. WinBuilder is 100% legal and benign software:
what user will do with it, is purely user's responsibility!

3. What user will start on his machine has nothing to do
with WinBuilder and Boot-Land Forum!

This approach will keep Forum out of legal vulnerabilities!