I am making asset for assets story. I want sell it there.
But my assets most consist of scripts. Anyone can buy it and after a litle modify put in a assets store.
How can I defense it?
I believe there is no way to fully prevent it, but the Asset Store use terms got you covered:
http://unity3d.com/company/legal/as_terms
Section 2.2 of "End User's Rights and Obligations"
Licensor grants to the END-USER a non-exclusive, worldwide, and perpetu- al license to the Asset to integrate Assets only as incorporated and embed- ded components of electronic games and interactive media and distribute such electronic game and interactive media. END-USER may otherwise not reproduce, distribute, sublicense, rent, lease or lend the Assets.
If you discorver someone has in fact modified and is reselling your work, you have the legal upper hand.
Related
I recently purchased a django-react code off fiverr. I don't know too much about web development.
This may be just paranoia but is it possible that there could be some malicious malware in these kind of Files. And that if I run the server then something could happen to the pc I run it on?
Short answer, is it possible for HTML, PY, JS etc. files to contain malicious content, yes. If you run this server on a PC can any malicious content do bad things to the PC that it is being run on, yes.
Ok, so that is the scary side of this done. Let's consider the question a little more objectively. Let's think about how these files can contain malicious content, and more importantly what can you do about it.
The author deliberately wrote malicious code into the files
Of course this is possible, but in my opinion unlikely. People producing malware are looking for a return on the investment of their time. Writing a solution to your request on fiverr and including malicious content is a huge investment for minimal return.
Also, please bare in mind that any contractor / freelancer is building their career on trust. If they get caught writing malicious code for customers then their reputation will be impacted. There is a great book on Who Can You Trust? which goes into the details about trust on platforms sharing goods and services.
If you do want to check for issues in the code, then I would use a static code analyser (e.g. Fortify) and a penetration test.
The author has included an open source module that has malicious content
This in my opinion is more likely. There have been examples in the past of modules published via sharing mechanisms e.g. NPM have contained malicious content. Here are a couple of examples:
Malicious NPM package
Bitcoin Stealer
The good news here is that it is quite easy for you to check for known issues. For example, as you have JS files I assume there is a dependancy on npm, you can use npm-audit to check the dependancies for security advisories.
In summary, in your position I would start by ensuring that the dependencies used by the code don't have any significant security advisories. Then, if the system is critical enough I would use a static code analysis tool (e.g. Fortify) to check the custom code. Finally, always good for a public facing system is getting a good penetration test done.
The key point here, is to think about the risk profile for the system and then decide what investment you need / should do to ensure the security of the system. Is this a customer facing system taking sensitive information (e.g. bank / credit card details), or, an internal intranet system? The first will require more stringent security checks to ensure that you keep your customers safe.
I'm working on an app that, as one component, accesses the imgur API. I'm trying to work out if it is considered "Commercial" based on three separate possible models. As you can understand, as the sole developer, I'm just a hobby programmer and I want to know if I can build this without a heavy monthly bill from imgur.
From the imgur API doc page;
Your application is commercial if you're making any money with it (which includes in-app advertising), if you plan on making any money with it, or if it belongs to a commercial organization.
What does that mean in these scenarios:
If I'm building an application that as a component of it uses the imgur API, that is not paid for, does not have any ongoing costs, but has a Patreon/GoFundMe/KoFi account attached to it to support development, is that considered "Commercial" here?
If I build the app, but charge a flat $5 for it, and no advertisement/in-app-purchases, is this considered commercial?
If I build the app, do not charge for it, do not post ads, but accept one-off donations towards developmnent, is this considered commercial as per the above?
If I'm building an application that as a component of it uses the
imgur API, that is not paid for, does not have any ongoing costs, but
has a Patreon/GoFundMe/KoFi account attached to it to support
development, is that considered "Commercial" here?
Possibly. Donations can very well be considered a source of income. In addition, you need to look at the second part of the Imgur ToS that you quoted:
plan on making any money with it, or if it belongs to a commercial
organization.
Will the app remain free forever after a limited period of development?
If I build the app,
but charge a flat $5 for it, and no advertisement/in-app-purchases, is
this considered commercial?
Yes, this can be considered commercial. Because you're charging money for the app.
If I build the app, do not charge for it,
do not post ads, but accept one-off donations towards developmnent, is
this considered commercial as per the above?
This is very similar to the first scenario.
The important thing to understand is that there is a great deal of latitude in enforcing the ToS. This is both to ensure the convenience of users, and also to ensure that Imgur's services aren't abused. One of the statements in their ToS states something to the effect of "Don't use us as your CDN". It would seem that is what you're thinking of doing. Unless your app is for a demonstrably social/charitable purpose like curing cancer or world hunger, Imgur might just as well choose to enforce the ToS. Don't risk it. Go for a paid service (Imgur's or another).
To be really sure, one can directly contact Imgur with a link to the app and check with them.
How safe is to use an online SVN repository?
I want to develop collaboratively with some friends. I know you can create non-public accounts in some of those services, but I can't fell confortable to send all of our intelectual products to another company manage. After all, if your idea works, those companies can easily find your source code!
Do you think this care is important? If so, what is the best solution?
My question isn't "how good it is" or "which is better", I just want know if you trust them and why (or why not).
Below I give you SVN repositories examples:
XP-Dev
Unfuddle
Assembla
Thank you all!
If you have something valuable enough to be stolen, it's time to get a lawyer anyway. Get him involved from the start, have him review whatever agreements the various hosting sites have to offer, and make sure they can be held accountable for breaches of security, including the value of your source code in the hands of competitors.
It is definitely important to be concerned about your source code in the cloud. At the end of the day you have to weigh up the cost of installing, securing, maintaining, backing up yourself vs a $10/month plan with a hosted SVN service. There are always going to be a certain sector that will never upload code into a hosted repo, i.e. banks, military, etc, but for the majority of us the risk is low and minor compared to the benefits of not doing it yourself. Make sure the provider you choose enforces SSL, has regular backups (at least hourly granularity), their datacenter provider is SAS70, and a policy allowing you to download your full SVN repo dump if you choose to leave, or go elsewhere, and how long the provider has been in business, do they have a good track record, and does the provider enforce a password policy.
I am planning to release a .NET product as Beta in the next couple of weeks. I want to know what points should be considered before releasing a product. I think the following needs to be taken care of:
Professional Icons/Splash and About screens
Obfuscation of assemblies
Sign the assemblies - Strong Name
Professional Security Certificate (Verisign/Thwate) - Authenticode signing assemblies
Google AdWords, AdSense and Analytics
Writing blogs etc about the application features
A way to get bug/features from BETA users
Basically the question is how to release an effective BETA and make my product popular?
Obfuscation of assemblies
Only if obfuscation does not decrease the quality and usefulness of (automatic) bug and crash reports.
Professional Security Certificate (Verisign/Thwate) - Authenticode signing assemblies
I don't think this is an important point for a BETA. If you can afford it, its a plus. However, it won't make your application more popular. Also, you won't loose potential users if you miss a certificate - whoever downloads and installs your application will not abort just because your stuff is not signed.
But there's another point missing: you need a fancy website. 'fancy' means: it must look professional, fit to your product and lead straight to a download link. The product needs to be easily installable - really easy. Small download size is also a plus in my opinion.
Writing blogs etc about the application features
Increases your google ranking, but needs to be used with care. If you fill hundreds of blogs, everybody will know it's YOU advertising your product. Nobody likes self-advertising. Let your users spread the word for your. A good application in a market niche won't need much advertising ...
Professional Icons/Splash and About screens
Is a good point to make the application look more polished, but the effect on potential users needn't be positive: nobody likes BETAs with awesome splashscreens and icons if they crash all the time.
The question
how to release an effective BETA and make my product popular?
has little to do with all the points you stated.
It is 95% marketing thing than technical.
But I would consider the most important ones for Betas:
Easy way to submit bug-reports/feature request (2 clicks, no more; 1 minute of user's time).
Usability.
Product demos to get started easily.
The first is crucial as it will give you the first feedback on the application.
I was asked implement a licensing schema for our product. They are very expensive products with few customers sparsely distributed around the world and basically every one of them has a design environment (a windows application installed on single windows machines, from 1 to 150 client machines per customer) and a web server that hosts production environment (1 to 8 machines per customer). Our product is licensed for server usage so customers can use any number of clients; we've decided not to license the server part (because it's subject to SLA agreements) but only the client, because, after some time without capability to use the client the system becomes basically useless.
Our basic assumption is that the customer is "honest enough" and only thing we would like to cover is stopping the client design environment if not properly licensed with a time expiration license.
I've evaluated different licensing product and they are or too expensive or too difficult to manage, so I've come up with this simple solution:
The license will be a simple signed XML file, signed using the standard XML Signature feature of w3c, using a private key that will be given to the admin department on a USB key; if they lose of copy it then the licensing schema will fail but it will be their fault
The client will open the license file on startup and check its validity using a public key embedded in the binaries
If license XML is valid and the data in it (expiration date and product name) are correct than the designer work; if not, an appropriate message will be shown
Any ideas about possible problems or how to improve the scenario?
I have yet to see a licensing scheme that wasn't broken in a few weeks provided there was sufficient interest. Your scheme looks very good (though be certain that if someone really wants to, they'll break it).
Whatever you do, you should follow Eric Sink's advice:
The goal should simply be to "keep
honest people honest". If we go
further than this, only two things
happen:
We fight a battle we cannot win. Those who want to cheat will succeed.
We hurt the honest users of our product by making it more difficult to
use.
Since you're implementing a license scheme for a program designed for corporate use, you can go even simpler and just keep some kind of id and expiration date along with a simple signature on the client and refuse to start if the license expired or signature failed. It's not that hard to break it, but no licensing scheme is and if you consider your customers honest, this will be more than enough.
It's not completely clear from your question how your scheme works. Does every instance of the client software have a different key? How long does the license last? Do you have a different key per customer? How is the license paid for? How is a license renewed?
If you are trying to control numbers of usages of the client code then only the first one above will do it.
At the end of the day, in the world you appear to inhabit, I suspect that you are going to have to live in trust that there are no blatant infringements of your license. Most decent sized organisations (which it sounds like your customers would be) have a responsibility not to infringe which can lead them to serious consequences if they break the license agreements. They will be audited on it periodically too and you probably have some statutory rights to go and check their usage (if not you should write it into your license agreement).
Where it becomes very dangerous for you is if the contents of the USB keys find their way onto the web. In that regard any scheme which uses a published key is vulnerable to a wilful disclosure of the secrets.
I'm certain there is a lot of literature on this subject, so it is probably worth you continuing your research.
BTW I'm not sure about your reference to SLAs in the middle part about your server licensing. Licensing and SLAs are very different. A license is the clients obligation an SLA is yours.
if you give them the private key, what is to prevent them from creating more signed XML files instead of buying additional licenses from you? or is it a site-license? if the latter, what is to prevent them from creating licenses for other people/sites?
in general, development licensing schemes tie the license to a particular machine using the MAC address and/or hard drive serial number, or sometimes just with an activation key (which is usually just a hash of the hardware info)
and typically the encoding is done with a private key that you keep secret, and the license is verified with a public key; the client never has the private key, otherwise they can - if so inclined - generate their own licenses
I agree with Steven A. Lowe (I don't have 15 reputation, so I couldn't vote him up).
This also seems too complicated. Do you want it to be unbreakable? you can't. Any sufficiently motivated guru would find a way around it.
Sometimes a simple licensing scheme works best:
I suggest a simple encrypted file that the admin puts somewhere the client can access - it would contain the client name and expiry date. You use the client name from the file in all printed reports (that's what most PHBs care About, that way they would not use the license that prints somebody else's name).