Make encloseJS open source

[robinrodricks]

Consider making encloseJS open source. I understand you would like to build a commercial product out of it, but the concerns will be the same.

1. How can we detect any code injection?
2. We cannot understand the exact method of compilation?
3. If there is code injected to convert our app to botnet, how can we know?
4. If at some time you stop maintaining encloseJS, and we are dependant on it, then what will we do? Go back to using vanilla nodejs apps?
5. Since its closed source nobody can make any improvements. It remains one-man effort only.
6. Since its closed source the project may "die" if you stop maintaining it

All these fears and problems go away when its open source. Also github is for open source projects. Make encloseJS open source!!!!

[radutopala]

:+1: good questions

[darkguy2008]

I have to agree, I've been following this project very closely and got sad by some of the reasons already stated by @hgupta9

[leanderlee]

Yes please! @igorklopov please contact me, we can even work out some sort of compensation.

[FGRibreau]

:+1: I have the same questions @igorklopov, I can't use it commercially if it's not open-source.

[oebspm]

Whatever you decide, to make it open source or not to make, just do it. This is very interesting project!

[robinrodricks]

Make it open source and accept donations. Many people will donate a lot to your project. Like FlashDevelop (see how many donations http://www.flashdevelop.org/wikidocs/index.php?title=FlashDevelop:Site_support)

[yieme]

Project is a great idea. I've the same concerns as those mentioned above. Even if pricing for commercial was acceptable (which I'm not seeing).

FYI: JXcore which looks to be in a similar problem space and is backed by the company Nubisa is going Open Source as they announced here

[igorklopov]

Thank you for your feedback. I understand you. I promise i will find a solution that will satisfy everyone. Also i will write here more information.

[robinrodricks]

Easy idea : Keep it closed source, and payment for open source (eg $100).

A. So people with security concerns can pay that to get the code, and see how it works etc etc, and when you have the source there are no worries. Bugs can be fixed yourself. And keep price cheap so lots of people will buy it. If its too expensive no one will buy it, people will not buy something that's not needed (NodeJS already works and is free, encloseJS is not needed).

B. And people who just want to use the app can use the closed source encloseJS for free.

Tough idea : Keep it open source, and accept donations. Only then you are begging for money, not selling anything, so harder to get donations?

[joepie91]

@hgupta9 "Open-source" necessarily means it allows redistribution, so keep that in mind. Requiring payment for it doesn't necessarily keep anybody from redistributing their copy.

[IonicaBizau]

Yes, I'm also voting for open-sourcing! :+1:

[Fonger]

Vote for opensource

[odnarb]

+1 Open-sourced business models are certainly doable. We all know the benefits of open source so I won't get into that.

As stated the business side can still charge licensing for certain use or provide support packages at different costs.

Everyone can win. :)

[DavidBenko]

+1

[ahmadnassri]

fully agreed, very hesitant of using it because of the binary obscurity ...

[BurakDev]

+1 :heart:

[simast]

So instead of open sourcing.. the "solution" was to make it into a subscription based commercial only version? The 1.0 enclode evaluation version is completely unusable for a free non-commercial project right now due to the nagging message visible in the output and all the other limitations imposed. Did not expect this to be honest, quite a disappointment.

[joepie91]

@simast Quick question: what are you using EncloseJS for? There may be better options.

[simast]

@joepie91 for free non-commercial closed source command line utility. I am not aware of any other options right now..

[droninn]

Use nexe version 0.4.1 https://www.npmjs.com/package/nexe. It works, and has a MIT license.

[joepie91]

@simast Why the closed-source aspect if it's non-commercial? Aside from the fact that "code protection" is a farce to begin with, and can't work, and that "closed-source" is fundamentally a legal problem and not a technical one...

[ahmadnassri]

I have no problem paying a license fee, but that still does not ease my mind about what's going inside my binary ... security concerns should be addressed, and the only way I can imagine that happening is by open-sourcing.

there are many successful models of monetizing open-source projects, this doesn't have to be 100% free.

[droninn]

I'm with @ahmadnassri, what goes into those binary files scares me.

[serkanp]

If you get scared :) then don’t use it.. If you “really” need it.. Then pay for the work done by him.. Your application can also work without compile.. Use it like that..

i am sure that he is not a stupid man who will put "scary" codes in his "commercial" app. he wants to earn money.. he spend hundreds of hours over it.. it's a choice to make it open-source or closed-code.. and it's your choice to use/buy or not.. he is trying to make a useful thing for you.. support him.. not blame..

i have a software company and i need a protection for my code.. this app fits my needs.. i have a commercial application works in all platform.. and its a must for me.. i tested it, i used it.. and i know its ok.. i paid for it.. get commercial support..

[ahmadnassri]

@serkanp you're missing the point, nobody's blaming him, or not appreciating the effort that went into making this cool and extremely useful product.

your application might be a simple one, while I'm building systems that are to be used by banks, governments and other entities that require a certain level of certification and compliance to what systems are doing. these are requirements by law, and of course by logic.

I'm not putting a credit card processing system for example into this compilation tool, without getting a full picture of what's the bundled package looks like and what (if any) calls, collection, monitoring, storage it might be doing.

furthermore, I want to compensate him for his effort, and I'm willing to pay a fair price (as will others) but not under this model, since it does not satisfy my security needs.

[serkanp]

@ahmadnassri you are missing the point too :)) if your application is that critical,if you are earning money from that code then write your own compiler.. or ask the developer for the source-code price.. make a license agreement with him.. pay the full source-code price for your company.. then use it whatever you like.. (as you know, everything has a price..)

why do you beg him to open the source code to everyone and wait for donation? :)

by the way: dont worry, my app is not that simple :)) it works live on 5.000 client's pc.. some of them linux, mac, armv6, armv7, windows any version..
and those pc's are critical customer pcs.. i had that worries.. also i use different compilers for different languages from very big companies.. how can we be sure if they did not put a "scary" code in it.. there is a developer writing that code for his company.. and he can put any dangerous code.. can you get the source code from them? no and yes.. yes:they have a "fair" price for the source code bro..

[joepie91]

@serkanp Asking to be paid for a distribution license is reasonable (within the framework of how copyright works today). Asking to be paid for access to the source, however, is not. That is just a normal part of auditability.

That one has access to the source code, does not necessarily mean that one is also allowed to redistribute it (whether in its original form or a modified form).

[ahmadnassri]

@serkanp there are laws and legal contracts in many government, financial and healthcare systems forbidden the use of tools without proper security vetting.

[jokesterfr]

Even for commercial usage: I was using it as a demo, to convince my boss we can use Node.js in our apps. If it's closed source or add limitations, my boss won't give me the green light for sure. Be able to test freely, is also a good point. I'm not saying we are not willing to pay (you deserve money for your work), but if there is a competitor, we will use it.

[dustinblackman]

:+1:

[nevf]

People need to make money, that's a no brainer. So like others have said provide the source in the commercial version. That's the way C++ libraries have been selling for ever.

[ashking]

Any further thoughts on this @igorklopov?

[nevf]

@ashking I suggest everyone looks at jxcore https://github.com/jxcore/jxcore at least until such time as this issue is resolved.

[ashking]

@nevf I've used jxcore for some time in 2015. They claimed to protect the source but that was not entirely true. More info here: http://markhaase.com/2015/06/25/cracking-jxcore-again/

Also on their latest updates, they do not mention anything about source protection. Yet is it worth to rely on jxcore for source protection? I don't think so.

[ashking]

jxcore just packages source. I don't think they provide source protection: https://github.com/jxcore/jxcore/commit/1e19c2b34c481b26ccb82d992dc9f1e76e74d016.

[nevf]

@ashking The date on that is Apr 18, 2015. jxcore does encrypt the executable. They've messed up the main jxcore web site in the last few days and it is missing altogether. Hopefully it will return. However there is lots of docs.

[ashking]

@nevf No, unfortunately, the statement was wrong. they don't do code protection. https://github.com/jxcore/jxcore/issues/857#event-579583412

[nevf]

@ashking Thanks, I thought they did. I do know that anyone looking at the .exe won't make much sense of it. I did look for specific strings in a Hex dump app and couldn't find them. It may be because the .exe is compressed. You may be interested in this article: http://markhaase.com/2015/06/25/cracking-jxcore-again/

[joepie91]

@ashking Reminder: 'code protection' is not technically possible, as the client is fundamentally untrusted. The usual concerns about DRM apply here as well. Your problem is likely a legal problem, not a technical one.

[charlesfracchia]

I was wondering why there are ~156 certificates in any binary that enclosejs generates? Many of the certificates contained are root certs and don't seem to be region specific. It looks to me like enclose is trying to validate incoming connections? But why would you need to do this if my script only prints a single line to the console? I don't want to be paranoid, I'm probably missing something, but I would nonetheless love to understand why this is needed.

Methodology

1. created a simple meow.js script containing a single command: console.log("Meow?");
2. used enclose on Ubuntu 14.04.3 (after installing required lib32stdc++6) to generate the meow binary
3. used a hex editor to have a look around and was surprised to find a LOT of certificate strings
4. used string meow to dump all the strings from the binary for easier inspection
5. estimated number of embedded certs using strings meow | grep BEGIN\ CERTIFICATE | wc -l (this is not necessarily the most accurate
6. (optional) use binwalk -eM meow to conveniently extract the certs

[igorklopov]

Enclosed binary has full nodejs runtime inside. If you make your research against official node binary, you will surely get same results. Your application outputs Meow and does not need all certs - it is true. But your application can suddenly require some js file from disk (not included into binary at compilation stage), and that file can start network activity (that needs that certs).

[ChicagoDave]

+1 open source

[philipz]

+1 open source, Please~~~

[BurakDev]

Since we have this issue open, @igorklopov switched project to a commercial version and added some limits on free version (network and time usage).

[darkguy2008]

Sucks though, this project should be open source...

[jaredallard]

Maintainer for nexe here, I just want to give my two thoughts on this thread here. EncloseJS is perfectly reasonably closed source. The developer clearly has decided they want money for their work, that is perfectly acceptable. EncloseJS also offers things that nexe does/can't. Like working packaging at the moment, without any odd issues, code protection (to an extent) and apparently code optimization to an extent as well.

As is the situation right now, for dependability you should really focus on relying on projects that have revenue powering them. This (usually) enables dependability and stability. Unlike the open source side right now.

[kethinov]

@jaredallard I don't think most of the people here are hostile to enclose seeking revenue. Many are excited about the project but unable to use it because it's a binary blob that isn't necessarily trustworthy. Closed source compilers are a giant security red flag in many organizations. I personally don't think @igorklopov is doing anything malicious in the binary bits, but a security policy is a security policy.

It's certainly @igorklopov's right to structure the project this way, but I think the disappointment from a wide range of people is also entirely appropriate as well. Two well intentioned sides can reasonably disagree.

Also, on an unrelated note, your project is fucking awesome and I've been a big fan for some time.

[ChicagoDave]

My only complaint is I'd like a more convenient low-cost license for non-commercial use. I'd pay a one-time fee, but not an annual fee. Similar to how I pay for WebStorm and other utilities I use.

[jaredallard]

@kethinov Yes, I agree there and that's something I forgot to talk about. Open source does allow a lot more freedom of usage, especially with such an open license.

[joepie91]

@jaredallard I have to point out here that open-source and commercial are not opposites. The two can coexist just fine (insofar any commercial software can exist 'just fine', but this is a tangent), and so any revenue-related arguments only apply to the cost issue, not the issue of it being closed-source.