When you create closed source code you have a much higher chance of flaws because your code can not tested nearly as much as open source can. As the leader of an open source project, FreeSWITCH http://www.freeswitch.org/ , I am fortunate to have a very large crowd of beta testers who help ensure our releases are as stable as they can be. If you are selling the application and never letting anyone see the source you run a very high risk of missing something in Q/A and releasing buggy software. When people pay for it the will get angry so I am not surprised such a suggestion is being made but I find it unpractical to enforce since if it "works right" is hard to judge in some cases besides maybe medical equipment or other situation where human lives are at stake. Blue screens of death are hardly an excuse to sue anyone.
Our project (FreeSWITCH) uses the MPL for the main application and BSD for satellite libraries that we create that can be used by other projects etc.
Once you decide to have open source code, it's more logical to stick with the fact that at least the core code is FREE and come up with ways to develop a product on top of it if you want to have something to sell. Otherwise it sounds like an "open source tax" and businesses do not like uncertainty. If they choose to use a code base they need to know it will always be available.
Everything on my Ubuntu installation is 64 bit. Every single application. Since I'm using Chromium, I guess that I have V8 in 64 bit. Just add the Chromium repository to Apt, then apt-get the source. You don't even have to know how to compile. (I do know how to, sort of, but I'm certainly not proficient - just let your installer do the work!)
I suspect it's using ia32-libs and not actually 64 bit. I have two reasons for suspecting this.
1) Chrome does not support 64 bit builds
2) The Ubuntu Chrome Daily PPA page says "no native 64bit debs planed for now. The amd64 package is using ia32-libs."
Yep, like i said, it's a shame, The idea is that we would use it in our project which is a telephony server that runs much better on 64bit, that's really the only show stopper from our being able to try it instead of the spidermonkey library we use now.
since it's open source, you can add 64-bit yourself. That's the whole point of open source.
The whole point of open source is for projects to work together and combine their efforts to make better software. As I said I am the author of an open source software. It has over 300,000 lines of code of it's own then a large list of dependency libs that added up account for about 2.5 million lines of code see: http://fisheye.freeswitch.org/browse/FreeSWITCH A library developer makes a library for other people to use. Adding 64 bit support to someone else's library is an exercise best left to the lead developer since it's his decision to support it or not.
I was looking at using v8 in our open source soft-switch/pbx/telephony application server FreeSWITCH http://www.freeswitch.org/
We currently are using spidermonkey from Mozilla and it has it's ups and downs in the scalability department since it was not designed for thousands of concurrent sessions in a single process. The documentation for v8 was impressive but sadly, 64 bit is not supported. It would be nice to get 64 bit supported so we could experiment further with it because it looks really well written.
Several years ago I wrote a javascript module for Asterisk open source PBX
More recently I added it for my own project FreeSWITCH ( http://www.freeswitch.org/ )
We actually also support LUA, Python, Perl, JAVA and MONO as ways to script telephony apps.
It's quickly becoming a great new way to prototype and deploy audio driven apps for your phone system.
Any circuit design must contain at least one part which is obsolete, two parts which are unobtainable, and three parts which are still under development.
