93 replies to this topic

[MedEvil]

I would like to talk about "the technical solution".
For a group of people who a so concerned about moral integrity, you sure have a strange moral.

It's moraly wrong for you, to embed a file in a script, cause then somebody could maybe says i don't like that.
But at the same time you have absolutely no problem to put the problem on the user. You say, he can download the file or he can run the script that will patch file x.
How noble of you!


If someone doesn't like us to distribute his software, i see absolutely no reason why we should keep on promoting it, by delivering a script for it.


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.
Should he inform us that our assumption was wrong, like Bart for instance did. Then we take this software down, without discussion, out of courtesy, without regard who is legaly right.
And then, hopefully no smartass will come up with the idea of circumventing the developers wishes with some trickery in a script!

[was_jaclaz]

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

[thunn]

Sounds about right.

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

In this case, I'm an offender.

Thought in most cases I do my best.
In the VBox script I've added instructions to dl the .msi directly from the vbox website, in bartPEcore the pebuilder.zip is acquired directly from official dl locations, and .. I don't need to continue.

This sometimes feels like a gray area, but it is not.
If we wish a long healthy life for wb, we should all be 'on point' with regaurd to this matter. So, I'll re-read this later and review any possible changes that may need to be made on my part.

[MedEvil]

Two things jaclaz.

There is no such thing as abadonware, as it would require the rights holder to officialy give up his rights.
No company going out of business have ever done so.
This means that using 'abandoned software' as if it were freeware, is not only moraly wrong but also legaly wrong. Just that there's noone anymore who would enforce the copyright.

If you get first a written or spoken permission to do something, you can no longer act in good faith.
Cause faith comes from believing not from knowing!

And we're full circle at:
Who has the permission from M$ that we're allowed to recreate PE and enhance it to a mobile OS which works on any machine without anyone having to enter and verify a registration key?

[thunn]

Circular logic, my fav.,
Thinking on the subject, I wanted to advise others that I've have notified Acronis about the development of 'TrueImage Server Lite'. I sent them a complete copy of the script with screenshots upon completion. I'm sure they're not happy, but, a user cannot do anything with the script unless they possess a valid product licence.
comments?

--edit--
No? Good.

[was_jaclaz]

There is no such thing as abadonware, as it would require the rights holder to officialy give up his rights.
No company going out of business have ever done so.
This means that using 'abandoned software' as if it were freeware, is not only moraly wrong but also legaly wrong. Just that there's noone anymore who would enforce the copyright.

Maybe what I wrote wasn't clear?

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)

(re-bolded for better outlining)
I intentionally EXCLUDED from the definition anything related to Commercial or Shareware programs which is what is commonly called "Abandonware" to create the neologism of "FREE Abandonware".
There is a number of programs available on the Internet which License while excluding the re-distribution, allows for special agreements for doing so. Hypothetically this could be the case of the already cited Free Foxit PDF Reader, should the Company shut-down before anyone is able to contact them to ask for a re-distribution agreement.
This would pose a problem.
As you might note, I posted this particular "Abandonware sub-category" as an exception to the previously listed CANs/CANNOTs, as it looks to me like a "grey" area, where the Author is willing to donate FREEly his Software, but he wants to distribute it from his own site. If the site is not anymore available, and the Author cannot be reached, embedding this app (i.e. re-distributing it) would mean a judgement of prevailing relevance of the original Author's will to distribute the software FREEly over the clause limiting it's re-distribution.

If you get first a written or spoken permission to do something, you can no longer act in good faith.
Cause faith comes from believing not from knowing!

Can you elaborate on this?
Are you saying that we should avoid reading EULAs to be able to "believe in good faith" that a file is re-distributable?

And we're full circle at:
Who has the permission from M$ that we're allowed to recreate PE and enhance it to a mobile OS which works on any machine without anyone having to enter and verify a registration key?

Maybe, but this has nothing to do with embedding a file in a .script.

If you wish to discuss this topic, please do start another thread, this one already contains enough "distractions"....



jaclaz

[MedEvil]

If you wish to discuss this topic, please do start another thread, this one already contains enough "distractions"....

I for sure will not start another thread for this rediculous discussion which get's us nowhere and will therefore refrain from replying to each of your points seperately.

This topic is not about embedding software, but about legal - or, in your case, moral responsibility toward the developers.

IMO you jump too conveniently around.
There should be 'one' rule that applies to all software.
But your problem is, that your preferd way of doing things, would make this forum impossible if applied to the OS too.
So you have this rule for shareware and this for freeware and a third one for M$....

Let's handle this like real computer freaks. Let's decide if eighter all things not being black are white, or all things not being white are black.

And while at it could we please come to a decision, if we're talking about purely legal or purely moral here, cause moral and legal hardly ever are the same.

[Galapo]

Well, I guess it comes down to the individual, too, not just the board policy.

So for me, I have removed app script of Foxit Reader from my site until I get a chance to modify it to grab install files or something.

Regards,
Galapo.

[MedEvil]

So for me, I have removed app script of Foxit Reader from my site until I get a chance to modify it to grab install files or something.

Galapo, this is exactly what i wanted to prevent.
Would you all please show some backbone and not start running for the woods, before anything is official!

First commandment of MedEvil: You shall not bow down under the lash before you were even hit!

[Alexei]

@jaclaz
I replied to "...what puzzles me..." with "It all began with...", just to point the beginning of "nasty discussion".
What's inpolite in that? Also, there is a big "gray area" between "impolite" and "flame".
What about "warning" to yourself? Anyway, it was just side note to help you resolve your puzzle.

Unfortunately, you completely ignored the core point of my post, i.e. automatic "extract at upload and embed at download".
Strange...

Alexei

[was_jaclaz]

@Medevil

Really, the topic, though I evidently lack the capability to make it clear enough, can be summed up in a few points:
1) There have been findings of illegal activities on the board (redistribution of non-redistributable copyrighted material) embedded in Winbuilder
2) The owner of the board does not want this to happen and to prevent it proposed to only let .scripts to be hosted on the board once they have been manually inspected by himself or by a selected board of "veriifiers"
3) I objected that this could cause an enormous amount of work for these people and will probably lead to delays in the availability of .scripts, besides possibly ingenerate in the .scripts developers the idea that there will be some kind of judgement and censorship on their work
4) Thus I proposed an alternative where the single .script developer is made responsible of what he embeds in a .script and the embedded files are transparently seen by everyone, including the final user, that is made more aware of the contents of what he is going to download and install on his system
5) Then I started this thread, to hear the opinons and ideas of .scripts developers and possibly find an even better way to do this

You repeatedly tried to bring the discussion on other grounds, the point it is not about the opinion of .scripts developers on the legal or moral implications of adopting or not adopting this policy, it is about the best (where best means easier, more transparent, less centralised, less prone to misunderstandings) way to make this policy effective.

As already said, in my personal opinion the "one rule that fits all software" is actually very simple:
"Do not embed other people's software into .scripts"
that would be 100% safe, but would/will create some kind of inconveniences to the end users and probably make Winbuilder a bit less "attractive", expecially to newbies.

Thus we need, as I see it, to find a way to let .script developers easily find what it can be embedded and what cannot, hence the tentative categories.

This is the topic, if you have anything to contribute to it, you are very welcome.


@Alexei

Yes, your idea:

The only possible solution is to have them separated at boot-land and embedded on client end.
That requires additional step at upload/download, i.e. extract at upload and embed at download.
Some work is necessary, but in return we would have worry-free, but backward compatible system.

is excellent , as I see it, as well as your previous one, though still the need to somehow categorize software is needed.
Using as reference my tentative categories above, software of types #1 and #2 can not be hosted, even in an unmodified form, on boot-land, while software of type #3 should be splitted in two sub-categories, #3a (software for which re-distribution is not allowed, that cannot as well be hosted on boot-land) and #3b (software for which re-distribution is allowed only in an unodified form); software of types #4, #5 or #6 poses no problems.

I wonder why there is the need to re-embed the software of types #3b, #4, #5 and #6 I mean, the latter three can be embedded from the beginning, and still we must provide a way for end-user to use his own files of softwares of type #1, #2 and #3a, so something, pardon my technically "caveman" ideas, like a subdirectory in the Winbuilder tree like "\ThirdPartyFiles\" to host them will be needed anyway, so files of type #3b, though hosted on boot-land and downloaded automatically from it, could go there as well.

I am not sure I have understood this:

In addition scripts may have "commercial" indicator for each embedded file to strip it at upload automatically.

Can you elaborate on it?

jaclaz

[MedEvil]

Jaclaz you're right we had different ideas about what this thread is about.
You just wanted to hear only ideas on how to implement the new system, while i wanted to talk about if we really need a new system.

General problems i see with the new system are:
- If scripts dl the needed software from a website, they break very easily.
- The proposed solution of hosting them here at boot-land, does not help one bit with the 'do not redistribute' problem.
- The idea of uploading scripts and software seperately to make it more transparent is nonsense.
Having the files seperately only makes things easier to see for a noob, which i hope will not be the one checking up on things!

At last i would like to add somrthing else.
WB has only 2 advantages over BartPE, Peters nativeEx and the fact that all needed software comes prepacked in the script. Those two things make WB very attractive for unexperienced users.

I hope, i don't have to loose a word about all the advantages of BartPE over WB.

[online]

Much many roosters to crow, and the morning never comes!

This is one of my local sayings (translated in english I don't know if it "works" ).

Now, I see that we are risking to sacrifice on the altar of easiness for end user a project and a concept that should be protected at any rate, instead.

At this point of debate I think that if we truly want that laws are respected (agreed or not agreed) and before somebody really uses we should must semplify things to the board, not to end users.
From point of view of the end user (that is of mine), "we" (you) could increase the easiness of script creation...

Even if I see quite risible from the point of view of legal issue to act various workarounds as to download requested files through WB, or to download files, to install these and after to apply a script (I don't see which difference there is compared to embed files in a script, but the law is the law... and it doesn't admit ignorance! ) I still think that is just so that we must do (if we truly want respect the law, agreed or not agreed).

Sure many programs should be a bit more complicated to share, but in my opinion should be better so rather than to complicate highly things to the board.

Alternately I think that a .script developer when embeds files in a his script should must show program's EULA with its re-distributable clause absence (I'll just do this with my scripts).

At bottom we are talking "only" about this, if I am not wrong.

And finally maybe this could be just that "single" rule about we're talking too...



Btw: obviously the respect of law (agreed or not agreed) has its cost... and "we" must only decide if "we" want to pay it...

[Alexei]

is excellent , as I see it, as well as your previous one, though still the need to somehow categorize software is needed.
Using as reference my tentative categories above, software of types #1 and #2 can not be hosted, even in an unmodified form, on boot-land, while software of type #3 should be splitted in two sub-categories, #3a (software for which re-distribution is not allowed, that cannot as well be hosted on boot-land) and #3b (software for which re-distribution is allowed only in an unodified form); software of types #4, #5 or #6 poses no problems.

I wonder why there is the need to re-embed the software of types #3b, #4, #5 and #6 I mean, the latter three can be embedded from the beginning, and still we must provide a way for end-user to use his own files of softwares of type #1, #2 and #3a, so something, pardon my technically "caveman" ideas, like a subdirectory in the Winbuilder tree like "\ThirdPartyFiles\" to host them will be needed anyway, so files of type #3b, though hosted on boot-land and downloaded automatically from it, could go there as well.

I am not sure I have understood this:
Can you elaborate on it?

jaclaz

Let's suppose we accept the idea of Extract at Upload Embed at Download (EUED).
Let's call 3rd party files "safe" and "unsafe" in as "to be hosted on boot-land" (B-L).
I'll use Q&A form for clarity:
- Why not to keep "safe" files embedded at B-L? For consistency and visibility reasons.
- Why not to keep all "unsafe" files in one local directory? It's messy, names may duplicate, unfriendly to end-user, etc.
- Why embedding is still needed? For backward compatibility and convenience of developers and end-users.
- How upload works?
WB connects to B-L and verifies embedded files in local script against files hosted on B-L.
WB asks uploader (script developer) about Embedded files not hosted on B-L.
If uploader marks file as "safe" it's uploaded to B-L, i.e. added to hosted files.
Otherwise file is marked as "unsafe" in the script and is not uploaded to B-L.
WB adds Files Reference (FR) with names and properties into the script.
- How download works?
WB reads list of local files (it's new WB configuration file, let's call it "files.ini").
WB saves previous version of script.
WB downloads script
WB resolves script's FR to local files (from files.ini)
WB verifies (via MD5) if "safe" files need to be downloaded from B-L or they can be extracted from saved script.
WB downloads files (marked "safe" at FR) from B-L
WB extracts "unsafe" files from the old version of the script.
WB verifies all FR entries are resolved (uresolved entries cause Error "missing file...").
WB embeds files into the script.
- Why WB should save previous version of the script? Because end-user may have erased original files (uninstalled 3rd party software).
- What are properties of FR entry? FileName, MD5, "safe"-flag, "embedded"-flag, optional "comment"
- Why do we need Files.ini? To let end-user specify location of his local (usually "unsafe") files.
- Should Files.ini entries override other information? Yes, to let end-user more control (for ex. override safe "limited trial" with local "full version").
- What does Files.ini entry specify? ScriptName (or ProjName.ScriptName), FIleName, LocalPath (or LocalPath.LocalFileName)
- What to do if uploader marked "unsafe" file as "safe"? He manually marks file "unsafe" in the script and re-uploads it.
- Is Files.ini one per WB installation? Yes.
- Is FR section always present in the script? Yes, but if missing it's created at upload.
- What happens if script on B-L has "embedded" flag in FR (for ex. uploaded not via WB)? The script can not be downloaded, and normally should be deleted (or relocated) automatically.
- How to force WB to re-download/re-embed embedded file? Manually clear "embedded"-flag in the FR entry.
- What would happen if file is marked "safe" in FR, but not hosted by B-L? Error "Missing Hosted File...".
Final note: the only changes end-user would notice after implementation of EUED would be Files.ini and FR-section in each script.

Alexei

[pscEx]

Let's suppose we accept the idea of Extract at Upload Embed at Download (EUED).
...

That's a mass off suggestions and explanations.
My first impression:

But it seems to be hard (and unscheduled) work for Nuno to implement.

Maybe this suggestion can help:

• Nuno just implements the 'Plugin' feature Alexei posted at a different place
• Alexei writes a 'sceleton plugin' which does the main functionality

Then let's see whether to add the not-main functionalities or features

• by Alexei's programming
• by user written plugins
• by developers changing the OpenSource 'sceleton plugin'

Just a suggestion. I do not want to give any instructions to Nuno or Alexei.

Peter

[MedEvil]

but the law is the law... and it doesn't admit ignorance! ) I still think that is just so that we must do (if we truly want respect the law, agreed or not agreed).

There seems to be some fairytale idea around about what the law is and what illegal is.

For instance on an everage day, unless you stay at home and maybe even then, you break about 5 laws, not counting the ones you break knowingly, like speeding.

So how come nobody arrested you today?

Because our law system works on two fundamental rules.
- as long as noone complains, no trial
- as long as the costs of a trail outweight greatly the advantage of it for society, again no trial

If any government should ever come up with the idea of enforcing all laws all the time at all places, society would come to a complete stop within minutes.

Companies work under an even other set of rules.
- does a trail bring me money, buyers, advantage over my competitor? --> trial
- does a trail just cost me money, reputation ... --> no trial

That, for instance, we can fiddle here with PE, without M$ stepping on our toes is only doe to the fact that there's nothing to win, just to loose here.

[Brito]

I won't mind at all, having the possibility to expand wb with 3rd party plugins sounds a good idea!

Just let me finish a few other things I've started in the meanwhile and I'll start working on it along with the new beta talks.

If a new plugin feature is tested and proven to work well then it would surely become included by default.

[Alexei]

@Peter
Unfortunately, EUED feature has to deal with too many internals of WB, just list a few: file transfer, extract/embed, script modification, ini processing, etc. Such deep integration would require etremely complex protocol because of necessity of plugin to request functional support from WB. Logic necessary to support such sophisticated protocol may exceed the logic of EUED. Sorry
Functoinal Plugins are good for things like "get info about something", "get list of something", "process script text somehow", etc.

Alexei

[pscEx]

@Peter
Unfortunately, EUED feature has to deal with too many internals of WB, just list a few: file transfer, extract/embed, script modification, ini processing, etc. Such deep integration would require etremely complex protocol because of necessity of plugin to request functional support from WB. Logic necessary to support such sophisticated protocol may exceed the logic of EUED. Sorry
Functoinal Plugins are good for things like "get info about something", "get list of something", "process script text somehow", etc.

Alexei

@Nuno
I understand your arguments against WinBuilder becoming OpenSource.
I also do not want to publish my source code or having a CVS for modifying, recompiling etc. or even using commercially by everybody.
But you maybe should think about Open(ForSelectedPeople)Source.

Peter

[MedEvil]

But you maybe should think about Open(ForSelectedPeople)Source.

I still think the support of plugins would be the best way to go.

[Alexei]

I won't mind at all, having the possibility to expand wb with 3rd party plugins sounds a good idea!

Just let me finish a few other things I've started in the meanwhile and I'll start working on it along with the new beta talks.

If a new plugin feature is tested and proven to work well then it would surely become included by default.

Plugins (if implemented) need pre-defined communication protocols.
Simplest protocol may be like that:
WB:The following info is a script of NNN lines;
Plugin:OK
WB:sends script
Plugin:Processed OK, result length=MMM lines;
WB: reads result
Of course, that's not exact messages, but their meanings.

But, most interesting feature would calling plugins from scripts via communication protocol defined in the script.
However, I don't think it's for near future

For now it may be several protocols like:
- This is source script, return it with processed macros (do macro substitution)
- This is module name, return its dependencies
- This is language name and messages, return them translated.


Alexei

[MedEvil]

But, most interesting feature would calling plugins from scripts via communication protocol defined in the script.
However, I don't think it's for near future

We already can do that. Pedroles 'make script' used to work this way.
But the real reason for a plugin system is to get more functionality into WB than a script can provide/handle.

If i, for instance, would wanted to write a plugin for WB, i for sure would not want to have to rely on the script interface. It's far too limited and ...

[online]

There seems to be some fairytale idea around about what the law is and what illegal is.

It seemed to me that this thread meant about that, but I will been wrong.
However I have two personal basic approaches: the first is when an action is relative exclusively to myself, the second is when my behaviour can damage others one.
In second case I become very much prudent.
Furthermore I have neither technical capability nor language or specific preparation to continue this probably actrattive debate: I should can neither to propose technical alternatives nor to follow as I would want the debate itself (Google Translate never help me enough).
Probably I am also not very clever (I'am serious), but I do a considerable effort (about the time invested too) to continue.
Only a (maybe) positive thing about myself: at least I'm tried to do it...

MedEvil, thank you so very much for your welcomed reply (I'm very serious)
and thank you at all!

[phox]

I have been absent from the Forum for month and a half
and usually when I come back, there are so many changes
that I am forced to start from beginning.

This time I was surprised to find that only on nativeEx Project
there are some changes and main activity is discussion of legality.
Even that discussion is very unpleasant.

Without undermining problem of legality, let me remind you that
all Projects are based on illegal manipulation of MS PE.
The fact that (until now) MS did not react doesn’t change the reality.

My argument is that legality overkill will not help much. Too much
of rules will lead to difficulty of implementation. Complex technical
solution will just complicated the WB.

As most of legality problems are located in Application scripts
my suggestion is to make scripts without application files and
let users to provide legally those files.

In published scripts should be only REG settings and additional dll’s,
as the rest could be easy generated with Pedro Le script generator.

On the other side, WB and core scripts should be made simpler,
not more complicated.

So, please:

@Admin, don’t insist too much on legality, as the base is already illegal!
@Script developers, don’t complicate situation with complex technical
solutions. Life is not possible to regulate with them!

[was_jaclaz]

@phox

Though your opinions on the matter at hand are appreciated , these three things need to be made more accurate (bolded italic are my additions):

Without undermining problem of legality, let me remind you that
all Projects are based on illegal, as I see it, manipulation of MS PE.

The fact that (until now) MS did not react doesn’t change the reality, as I perceive it.

@Admin, don’t insist too much on legality, as the base is already illegal, in my view!

Please, do not reply to this post, this thread has had enough diversions, if you feel like discussing the legality (or illegality) of Winbuilder, start a new thread.

jaclaz