I would like to know what types of protection they are using with the Github Enterprise (http://enterprise.github.com) solution. As I don't own a company that could potentially be buying it, I don't feel confortable to lie, just to get a copy and try to see it by myself.
But I'm really interested to know what kind of strategies they used to protect the code they deliver, as it potentially can be used by any other rails application.
This question is not "How to protect my Ruby Code", but how they protected and entire appliance with not just Ruby code but a lot more dependent services, running on an ubuntu linux server.
I have some theories that could help:
They could be using Ruby Encoder to protect the ruby code
They could be using TrueCrypt to create a special partition to install all the code and needed application and have created a special loader to somehow execute that code without giving read/write permission to any other user on the system.
They are currently using a modified RubyEncoder.
Source: I asked
I don't know Ruby but they say:
Does the license include access to the source code?
No. Licenses cover the use of the software only. Modification and redistribution are not permitted.
It doesn't necessarily have to be protected using any technology, which can eventually be broken. You are singing a contract, if you do not follow the regulations in it, you may end up in court. I guess it's a matter of mutual trust.
Related
is there good copy protection mechanism to protect my jar file from being copied DVD or is there licensing which can limit number of machine installation.
I have software which i require to distribute on DVd. i want my client to just run the application in machine.
advance thanks for your help.
Copy protection can't prevent your file to be copied but you can make it fail when it is run on unlicensed machines. Selection of a copy protection mechanism is a matter of budget and time. There are many companies with many products.
You can go with not yet cracked technologies like iLok etc. This is applicable for very high revenue cases. But if your target audience is less than 1000 people then a simple in-house solution might work. Consequence of a complex method is typically many calls to support line and unhappy customers.
Things got a lot easier after clients are all connected to internet. You can make some simple parts to run on server which a cracker would never dive into for a replacement. Or the app might download the contents from server after installation. Latter is what I did for my app and I never had any problems.
I am working on a RSS reader application. And I need to find a backend database. I want the database be embedded because I don't want the users to install a database server.
I know SQLite is a good choice, but I am wondering if there are any other nosql choices?
(I don't yet have 50 rep points to comment on, and build upon, the accepted answer; otherwise I would, sorry!)
You can embed MongoDB in your OEM solution but there are two things to consider:
It is written in C++, so if you are coding in a different language you might need to write a wrapper that launchers the database process separately.
MongoDB is licensed under Gnu AGPL-3.0 which is a copy left server license. The accepted answer, and the Google group quote, both correctly state that this would normally force you to also be AGPL licensed. However, they MongoDb states that the intention of the license is to allow refinements to their code to be submitted back, and that your product will remain separate. This makes me think that the normal copy left rules don't apply.
The goal of the server license is to require that enhancements to MongoDB be released to the community. Traditional GPL often does not achieve this anymore as a huge amount of software runs in the cloud. For example, Google has no obligation to release their improvements to the MySQL kernel – if they do they are being nice.
To make the above practical, we promise that your client application which uses the database is a separate work. To facilitate this, the mongodb.org supported drivers (the part you link with your application) are released under Apache license, which is copyleft free. Note: if you would like a signed letter asserting the above promise please request via email.
Source: http://www.mongodb.org/display/DOCS/Licensing
According to the Google Group, yes it can, but it doesn't cover how exactly.
Yes, but it isn't pretty and will
force your app to be AGPL licensed. If
you are interested take a look at how
the tools handle the --dbpath option.
Source: http://groups.google.com/group/mongodb-user/browse_thread/thread/463956a93d3fb734?pli=1
If you're using .NET, one option might be RavenDB, which is a document database, and can be embedded.
Please checkout https://github.com/Softmotions/ejdb
This project being developed to resolve this issue.
How about Couchbase Lite? It's an open source, embeddable document database. While it can function as a standalone document database, its real value is in its ability to synchronize with remote document databases. It may be aimed at iOS / Android, but it can run on anything with a JVM.
https://github.com/couchbase/couchbase-lite-java
There is no straight forwarding way to use MongoDB as an embedded library in terms of a well-reusable library. Eliot - head of 10gen - spoke of "it would be nice to have one" - but there is nothing available that could be reused in a sane way.
Looks like a lot of OEMs are trying to get Mongo on to their hardware and devices for real-time processing. A link from MongoDBs website
I usually use Buildroot to create a cross-compiled Embedded Linux root file-system along with all the user space packages.
I noticed that MongoDB is one of the packages that's already integrated as one of the Buildroot builtin packages.
You may check out MongoDB make file for some hints regarding how to built it for Embedded Linux.
According to this page:
No central approval process for adding packages. When you upload a package to the NuGet Package Gallery (which doesn’t exist yet), you won’t have to wait around for days or weeks waiting for someone to review it and approve it. Instead, we’ll rely on the community to moderate and police itself when it comes to the feed. This is in the spirit of how CodePlex.com and RubyGems.org work.
This makes me feel uneasy. Before I download a Firefox add-on, I know it should not contain malicious code, because AFAIK all add-ons on addons.mozilla.org are reviewed by Mozilla. Before I download a open source project from codeplex.com or code.google.com, I know it should be safe because anyone can check it's source code. And I can also use WOT (web of trust) to check how other people think about the project.
But before I download a package from NuGet official package source. Take this one for example. I do no know who made this package, nor what is contained in the package. It seems to me that anyone can pack anything into a package, give it any name they want (like "Microsoft Prism", as long as the name is not taken), then upload it to the official package source.
Should I be worried about the safety of the packages on NuGet official package source?
Your uneasyness should apply to software you obtain from any source:
Binaries downloaded from Sourceforge.net, Codeplex.com, etc could feasibly contain malicious code (either planted by the original submitter or, more likely, inserted by a hacker into the website) that may pass unnoticed until someone (you?) gets bitten and raises the alarm.
Even if you compile your own binaries from source downloaded from one of the former websites, it could still perform malicious acts unless you go over all the source code and understand what it does.
Even software downloaded from 'app stores' (e.g. Apple iTunes, Android Market) could feasibly contain malicious code; some of these review processes are partially automated but are still not infallible, and the human review that also occurs is definitely not infallible!
There have been examples in the past of boxed software containing malware!
Perhaps there is a continuum of trust that you can have in software (delivered as binaries or source code), and something like the Nuget Package Gallery (and CodePlex.com and RubyGems, etc) probably lies on the less-trustworthy end of the continuum.
There are potential solutions to this sort of problem, such as those proposed by the Trusted Computing Platform Alliance, however they come with huge restrictions on the freedoms that we currently enjoy in developing software and sharing the software we develop as we see fit, without the need for licenses or cryptographic keys obtained from central authorities at great expense.
I believe that the community will come up with conventions and mechanisms for ensuring that Nuget becomes a trustworthy source of software libraries for .Net developers, whilst retaining the agility it has with not requiring a formal review process. However, the ultimate responsibility rests with yourself as a user to ensure that your IT security isn't compromised, and the precautions you take are a function of the criticality of IT security in the context of the software you are writing (e.g. home projects; probably low. Banking, medical, process control projects; probably high!)
NuGet doesn't manage trust. Even if it did, you would still have to be concerned about trusting what NuGet trusts.
You should absolutely be concerned about the safety of the code in a NuGet package. You should be concerned about the safety of any code you are not familiar with.
The approach I take to using packages, both personally and professionally, through NuGet and NPM are below:
Lock in the semantic version number completely. Explicitly specify the major, minor, and patch numbers. Don't assume that new updates will be safe or that their semantic version will be accurate.
Use only well known current versions for production.
Experiment with anything in a test environment with limited access e.g. under an account which isn't a local administrator, no local access to highly privileged credentials, no access rights to privileged resources granted to the test machine's IP.
Check the vendor. For example if the package is released by Amazon and it's an AWS SDK, then that package is probably safe to use if you trust Amazon.
For example the only packages I would trust right now to just go and add them in a production environment are Newtonsoft.Json and Nhibernate. My biggest concern with new open source packages that anyone can publish, is that they actually work as described before I buy-in and waste my time on something that doesn't meet my needs.
I feel as though if you did enough research on the package to see if it's suitable for a production environment, you probably have learned enough about the software and its community to determine if you can trust it's not doing anything maliciously. Researching the software and it's community really means more to me than NuGet's stamp of approval decided by one central authority that we all pray is perfect.
Basically, I want to get an update of the standard command-line subversion client for Windows. I used to be able to get downloads of this quite easily, but it seems like registration is required these days.
I object to registration, but equally, I prefer not to use workarounds that e.g. involve registering with details that won't stay valid.
I already have TortoiseSVN - this isn't about clients in general, but specifically about the standard command-line client. I also don't need the server stuff - just the client.
It looks like I can download the source, but building from that probably involves the usual dependency-finding issues and so on. As this is likely to be a recurring issue, I'd prefer to avoid it if possible.
I'll be more than happy with a torrent link. Googling for that specifically, though, just leads to a lot of what look like pirate versions of commercial clients.
Any ideas? Or is there some good reason for collecting these registration details that might override my objections?
EDIT
Applogies to everyone I "sigh"ed at or whatever over SlikSVN suggestions. Clearly, I need to do better at avoiding making bad assumptions.
Which site are you downloading from? Just taking a look at the download links from the SVN project home (http://subversion.apache.org/packages.html), I see four options for Windows, several of which do not have registration, at least. The SlikSVN link is free and has command line utilities.
You could also install Cygwin, which is definitely free and comes with other useful utilities.
You can get a free one here:
http://www.sliksvn.com/en/download
As you said, you can certainly download and build the source code; it's free software under the Apache License 2.0. But if you want to download an executable without Collab's registration, try SlikSvn.
Binary distributions of the subversion client are available from the official subversion site.
http://subversion.apache.org/packages.html
I'm looking for a way to give out preview or demo versions of our software to our customers as easy as possible.
The software we are currently developing is a pretty big project. It consists of a client environment, an application server, various databases, web services host etc.
The project is developed incrementally and we want to ship the bits in intervals of one to two months. The first deliveries will not be used in production. They have the puropse of a demo to encourage the customers to give feedback.
We don't want to put burden on the customers to install and configure the system. All in all we are looking for a way to ease the deployment, installation and configuration pain.
What I thought of was to use a virtualizing technique to preinstall and preconfigure a virtual machine with all components that are neccessary. Our customers just have to mount the virtual image and run the application.
I would like to hear from folks who use this technique. I suppose there are some difficulties as well. Especially, what about licensing issues with the installed OS?
Perhaps it is possible to have the virtual machine expire after a certain period of time.
Any experiences out there?
Since you're looking at an entire application stack, you'll need to virtualize the entire server to provide your customers with a realistic demo experience. Thinstall is great for single apps, but not an entire stack....
Microsoft have licensing schemes for this type of situation, since it's only been used for demonstration purposes and not production use a TechNet subscription might just cover you. Give your local Microsoft licensing centre a call to discuss, unlike the offshore support teams they're really helpful and friendly.
For running the 'stack' with the least overhead for your clients, I suggest using VMware. The customers can download the free VMware player, load up the machines (or multiple machines) and get a feel for the system... Microsoft Virtual PC or Virtual Server is going to be a bit more intrusive and not quite the "plug n play" solution that you're looking for.
If you're only looking to ship the application, consider either thinstall or providing Citrix / Terminal services access - customers can remotely login to your own (test) machines and run what they need.
Personally if it's doable, a standalone system would be best - tell your customers install vmware player, then run this app... which launches the various parts of your application stack (maybe off of a DVD) and you've got a fully self contained demo for the marketing guys to pimp out :)
You should take a look at thinstall(It has been bought by vmware and is called thinapp now), its an application virtualizer.
It seems that you're trying to accomplish several competing goals:
"Give" the customer something.
Simplify and ease the customer experience.
Ensure the various components coexist and interact happily.
Accommodate licensing restrictions, both yours and the OS vendor's.
Allow incremental and piecewise upgrades.
Can you achieve all of these by hosting the back end (database, web server, etc.) and providing your customers with a CD (or download) that contains the client? This will give them the "download/upgrade experience" that goes along with client software, without dealing with the complexity of administering the back end.
For a near plug-and-play experience, you might consider placing your demo on a live linux or Windows CD. Note: you need a licensed copy of Windows for the latter.
Perhaps your "serious" customers might be able to request their own demo copies of the back end as well; they'd be more amenable to the additional work on their part.
As far as OS licenses, if your vendor(s) of choice aren't helpful, you might consider free or open-source alternatives such as FreeDOS or linux.
Depending on if you can fit all the needed services into a single OS instance or not...
Vmware Ace or whatever they're calling it nowadays will let you deliver single virtual machines under strict control, with forced updates, expiration and whatnot. But it sounds easier to just set up a demo environment and allow remote access to it.
The issue here I guess is getting several virtual machines to communicate under unknown circumstances - if one is not enough?
An idea then is to ship a physical server preconfigured with virtualisation and whatever amount of virtual servers needed to demonstrate the system.
Using trial versions of the operating system might be good enough for the licensing dilemma - atleast Windows Server is testable for 60 days, extendable to 240 when registering.
Thinstall is great for single apps, but not an entire stack....
I didn't try it yet, but with the new version of thinstall you are able to let different thinstalled application communicate.
But I guess you're right a vm-ware image would be easier