Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have received a request of buying the source code of a website I have developed and I wondered if anybody have been in the same situation and if there is anything I should specially be aware of. Anybody got some advise on how I should handle this situation?
First - a caveat - I'm not a lawer. Not at all. But I care alot about intellectual property and not getting sued, so I try to learn about it a bit.
In no particular order:
Double check your employment rules - when you took the job currently paying you money, what is your arrangment? Did you have to sign any statements giving your company control over all the code you produced? Even if it was a personal, unpaid project - corporate ownership can get you if you signed a strict intellectual property agreement.
Used open source? - there are a few main open source licenses, read through and check them to see the terms for sale of a product with dependancies on open source.
What deliverables does buyer expect? - Built code? source code? Also - what can you do to protect your code (obfuscation).
Do they expect support? - be careful, in my experience with corporate customers, a helpful, free of charge "sure, just call me if you have a quick question" can quickly become time consuming. If you are willing to throw in a free couple hours, be very clear that you will give up to X hours of support for free. And be clear about what your billing rate is after. If you really don't want to support it, make the cost of your time very high.
What sort of support do they want? - answers & configuration help? Bug fixes?
What sort of installation instructions are expected?
What do they own when they buy this? - a single installation for a single server? a site-wide license to install it wherever they wish? or --- worst case -- do they own this lock, stock and barrel such that you may no longer develop it and continue to use it yourself?
Get these answers cleared up, in writing, with signatures.
It's a good idea to have someone external read it to check for ambiguity.
It's an even better idea to draw up the agreement and have a lawyer read it - your lawyer, not the buyer's lawyer.
Avoid any nod/wink/handshake deals. Personal trust is great, but people change if the situation becomes stressful. Or people come and go within companies - the buyer today may be a different person tomorrow.
The first thing you need to consider is:
What license are you providing the code under?
If you don't stipulate a license, they're pretty much free to do with it what they want. Is that what you want? It's hard to answer the question without knowing the specifics of the situation: why are you selling the source code?
If this is a customer and so it's they can do their own custom modifications that you were otherwise being paid to do, the price should reflect that "lost work". Also, you will want to limit their ability to redistribute or resell that source code.
If someone just likes your site and wants the code, be very wary because there's every chance they'll just take it and set up their own. This may or may not be an issue for you. But again consider the issues of resale, redistribution, usage rights and ownership.
Depending on what the code is for, you may also want to consider what it is used for, what it can be used for and how that will affect you professionally or otherwise. It's possibly you may want to restrict the code from being used for certain things (eg adult or poker sites) or you want to require attribution.
Also for all of these things, you need to consider what terms transfer in the event of redistribution (ie how "viral" your license is).
There are lots of open source licenses out there (GPL, Apache, MIT, BSD, MPL, LGPL, etc). I'd suggest you take one as a basis and modify it to suit your tastes. You're far less likely to get in trouble that way than you are with coming up with your own terms.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I just installed trac for this project I'm working on, since it's turned out to be a bit bigger than I anticipated. I've added a bunch of tickets with my clients requests which come in the form of emails, phone calls, and meetings. I've also added some stuff I know needs to be done/fixed but they haven't specifically requested. Should I grant them access to trac so they can submit the tickets themselves so I don't have to keep translating (words into tickets) for them? They're very non-technical, so I'm not sure how well it would work; they might open tickets and not provide enough detail, or get confused by all the different fields.
If your answer is "no", should I at least let them view the tickets, so they can see what I'm working on, what's been done, hasn't been done?
My experience (rather small, though) shows that allowing non-technical people to create tickets directly just won't work. You'll finish up editing those tickets yourself and constantly asking for details anyway. If I were you, I'd choose email for feedback and problem reporting.
However, it is a good idea to share existing tickets, read-only. Some people -- even non-technical ones -- are able to learn out of this how to create right tickets. Others would be happy to follow their particular problem while it's being solved.
So much of software development is managing clients and their expectations. Giving them write access to your bug database may suggest to them that they are now directing and in control of the project more than they actually are. Add to that the inevitable questions that will follow ("How do I do X/Y/Z?") and it's a massive headache waiting to happen.
I would consider read-only access but only if the client was technical enough and experienced enough with software development to understand how these tools are used. Otherwise I would stick with much lower-tech but much simpler todos-in-a-text-file, which I find myself using more often than not.
#Brendan Long trust me, it can get much worse when you give people a false perception about how much fine-grained control they have on a project.
At my company, we're struggling to get good problem descriptions in tickets from a technical audience (system administrators, technical consultants etc), and more often than not it takes inquiries from our professional helpdesk before an issue is layed out clear enough for a developer to work on.
Thus, from many years of experience, I would clearly advise against letting all your customers open tickets (unless you can narrow them down to a technical audience) because it will not save you any work compared to e-mails.
Read access is a good idea (because people will still feel much more involved) - you just have to make sure that you do not have too many tickets (usually low prio bugs or requests) that remain in the same state for a long time because this will start to frustrate the person who submitted it (better to close such a ticket in a timely manner if you can't or do not want to work on it, this kind of honesty if usually more appreciated than letting a ticket open for years ,-).
I used to communicate with a client via email and phone, and at some point I realized it was just too hard to keep track of things. I set up an account on Unfuddle (similar to Fogbugz but free), with just accounts for the two of us and it was immensely helpful.
When we first started, I did a lot of editing on new tickets, but it was still much better than keeping track of emails, and she figured out how to create tickets in the form I needed pretty quickly (I assume because now she can see how I keep track of what she's saying).
Anyway, if you're just using email now, it's not like it can get worse ;)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Background: On a new project I've found myself 3 levels removed from my actual source of information. I report to my PM, who reports to our contractor, who reports to the actual client. Getting answers to questions has become something of a problem and I'm curious to know what people recommend.
Needs: I'm trying to find a technology or disciplined strategy that will assist me in ensuring that the questions I'm asking are getting answered:
Correctly without much modification of the original question
Quickly so the original context isn't lost
Completely so that if a question is deferred I don't forget about it.
Does anyone know of a software suite that assists in this matter or do you have any personal discipline strategies that worked for you?
Thank you for the guidance
One strategy might be to cut out the middleman. Go directly to the client and ask what s/he wants.
On a slightly less bold note, request that you, your PM, the contractor, and the client all meet at the same time rather than on relying on an email chain or technology (which will undoubtedly not serve everyone's needs) to relay information. This strategy works particularly well in my experience, as long as you have a manager willing to let you tag along.
Best technology I can suggest is the telephone. You've got to open up direct lines of communication. But I guess you know that and are finding it difficult, someone along the line is not helping. So now you have to tackle that person, find out why not, what their reservations are and how you might allay their fears.
As for software, I recommend that you DO NOT look for a software solution to this sort of problem. Suppose you implement a new trouble-ticketing system for capturing client questions and comments and to feed back your questions and comments to your client. Next time you tackle your management about the issue one of 2 things will happen:
-- The response will be 'But you told us installing system TT would fix this !'
OR
-- There must be something wrong with system TT, we'll divert our energy to fixing the software.
Oh, and do write things down, so email might be even better than the telephone.
Regards
Mark
I'm sorry, but this doesn't sound like a technological issue. Good project managers ensure communication and should allow you to work directly with the client where necessary. This is a communicaiton/management problem.
PRINCE2 (the project management methodology) would define your questions as project issues (essentially an issue is anything which needs attention so a question is no different to a software defect).
Based on this I'd recommend tracking them the same way you track any other issue.
In your defect tracking system (you do have one right?) set up a category / classification / whatever "Question" and log them and assign them to either the client (ideally they should be given direct access) or to the Project Manager (who now has a way of tracking them and recording the answers).
As with all issues you should make sure you put in plenty of information and context to ensure you get a good answer (obligatory Jeff / Joel reference: in this case to Jeff's belief that you only get out of a question what you put into it). This will also obviously help if you're not the person actually asking it, though as many people have said do everything you can to get closer to the client.
The key point to remember is that people are lazy.
If you formulate questions through e-mail clearly and in format your contact likes, most likely he'll forward them to the next chain of command unchanged and so on.
Some quick tips on how to structure such an e-mail:
Numerate all your questions. Essential, otherwise all too often only the latest question will been answered
Be very specific in what the actual question you need input on is
If there is a fixed set of alternatives or if you have a clear recommendation, make sure this is clearly stated
Avoid mixing FYI messages with the questions. Instead, send separate e-mails
Carefully read your e-mail before you send and look for content that may be misunderstood
Good luck
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Perhaps the most obvious way of protecting a company's intellectual property from its own developers seems to be an NDA - Non Disclosure Agreement. Effectiveness of this approach may vary, depending on many factors, and sometimes or somewhere it may not work as expected.
What other approaches, apart from this purely legal one, exist for protecting software code from the people who develop it? Do they exist at all? Does it make sense in practice?
Maybe, for example, Team Edition of Visual Studio already contains some features related to this problem (for example, levels of access to parts of code, depending of role inside a development team or something like that)?
Reference on the topic:
As statistics says, on average, programmers tend to change their job every three - four years.
Try to build a team you can trust.
The first approach is to force programmers to only know interfaces of other components, so that each one can only steal a small part of the whole software. This approach can be borrowed from footwear production. One transnational corporation, to prevent stealing by employees, arranged its factories so that each factory produced only left or only right shoes. You could do the same with your code: some programmers only write lines with odd numbers, and the others--those with even numbers; provided that they can't see the work of each other! That's sometimes referred to as "pair programming".
Some organizations force employees to sign a non-compete agreement. That's the kind of agreement that prevents programmers to work for competitors. This technique is best combined with job postings like "Looking for senior programmer with 5 years of experience in the similar field".
To prevent your programmers from stealing, you can do harm to them as soon as they finish the software. The method proved itself as the most efficient, and has been used for centuries. For example, Russian Tzar Ivan The Terrible burned eyes of the architect that designed a beautiful church at the Red Square, so the one designed remains the most beautiful ever. You can do something like this to your architect. I heard, latest Visual Studio contains some features...
Nowadays, however, it's more humanistic to hire already blind and already dumb people that lost their hands, so that they can't look at your code to memorize it, can't tell anyone about your code and can't type it again. The advantage is that this will help you dealing with labor agency in your country, which watches for balance that your employees are not discriminated.
And yes, this post is a sarcastic joke, which criticizes the idea of any code-stealing-prevention measures. Sorry, couldn't help posting it.
How do you protect a power plant from sabotage by an employee? How do you prevent a boxer from throwing the fight? How do you prevent a brothel from distributing the clap?
Your concern, while valid, is one that can only be properly addressed by personal responsibility and accountability within your team. Any options you employ to secure the code against theft is likely do more harm than good. If you feel a team member is not trustworthy, get rid of them.
If really necessary you can split the application in subapplications.
Each team works in a single application and sees all others as "black boxes". Maybe SOA helps here.
It's highly unlikely that your code is the real intellectual property - that is your company's business knowledge and process.
SVN has the ability to limit different users to different folders, so you could split your code up into seperate libraries, and allow only certain people Read / Write access.
The file for this is under conf\authz
Here is a sample
[aliases]
# joe = /C=XZ/ST=Dessert/L=Snake City/O=Snake Oil, Ltd./OU=Research Institute/CN=Joe Average
[groups]
# harry_and_sally = harry,sally
# harry_sally_and_joe = harry,sally,&joe
[/
# [/foo/bar]
# harry = rw
# &joe = r
# * =
# [repository:/baz/fuz]
# #harry_and_sally = rw
# * = r
Some documentation can be found here
Under 'Per-directory access control'
Either build a team of developers that you can trust, or entirely lock their system down so they can't access the USB ports, the CD drive, or web mail clients. The only thing they could do is work on the code and possibly browse the web. Also only give them access to the code that they are in charge of.
But with all these security measures chances are your developers will hate working with you and quit their job
There's no straightforward way to do this if your code is within the same project (i.e. you want to allow access to some parts of the code and not others). However, if you have seperate projects that require different security levels, it's possible to allow developers to only have code access to certain projects, and then pull builds from a common build server.
Keep in mind that decompiling of frameworks that work against IL like .NET is relatively straightforward, so preventing access to the code files is not necessarily a silver bullet to protect IP.
I know you said aside from the purely legal one, but I'd just like to add that in addition to the legal one you mentioned, there is also the Non-Compete. Basically says that once you leave your job, you won't be able to compete in any way against your former employer. Stealing code is not as appealing if you won't be able to put it to use for a year or two.
You could make them develop a module that would be seperate from the rest of the application. If you had a plugin/module type system going this would suit well. You could release APIs for the developers to develop against and have them integrate with your DLLs and not the source code.
People seem to be very critical of this but there are legitimate reasons for doing this i.e. partnering with a potential competitor if you gave them all your source you would be shooting yourself in the foot.
It might be worthwhile to spend some brain cell activity on the business model you want to follow. If the core value is embodied in the code, the core value can be stolen by stealing the code. If, however, the core value of your business is embodied in a group of employees, some of them engineers, others sales people, yet others customer support people, and when the software is only the net that keeps these peoples business going, then there's no easy way of stealing the value of your business. And if the software does get stolen, the thieves won't be able to make much use of it.
So, in addition to what cherouvim said, build a team that you can not just trust, but a team that is the core value of your business.
Develop your software in modules.
Have one common module that contains objects that pass back and forth, and utility classes that act on those objects.
Have each group build modules on top of that, without much need to know about other modules.
Have one trusted team of developers do the planning of what goes in each module, and have that team also do the integration of all of the modules into the whole.
Also have a lot of trust in whoever runs your version control server. While it's stable, no one developer can do all that much harm; they can't delete everything, for example, and you'll know exactly what they did and when if that ever becomes an issue.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am thinking of implementing a good licensing mechanism that has a good resistance against piracy. The required mechanism should not use an internet connection at each and every time the software is used. I am thinking of a mechanism based on hardware IDs etc. Do you guys have any better suggestions? What are the parameters/algorithms/characteristics that I need to concern to make a hack proof license mechanism?
Ideally you need something that is OS independent.
I would recommend that you embed the license protection within your code or wrap your application within it in such a way that it cannot be run without the copy protection code having run first.
It would be best if your application needs a license key file in order to operate and that this isn't generated locally.
One way of doing this is that your application generates some form of image code based upon the hardware on it's initial run. This is supplied to you and in return you supply the license key which will allow the code to run. Best to base the hardware image around CPU and motherboard as these will change the least often.
Your app. should check against hardware image and license key whenever it is run.
If you want your app. license time limited then it should also keep track of how long it has run and embed it within the license key file.
Don't forget to encrypt the license file.
Also don't forget to make it more difficult to reverse compile your executable by use of a dotfuscator or similar.
Check this question: What copy protection technique do you use?
It also links to other related questions.
First of all, nothing is hackproof, so i wouldn't spend too much time on protecting your software.
The downside of a mechanism based on hardware IDs is when a user buys a new computer or upgrades most of his computer he needs to update the key too.
HWHash is a pretty good HardwareID implementation, but i guess there are more (free) solutions.
At work we use Hardlock and Hasp keys, but these are usbkey solutions which are not very efficient for small applications.
I am thinking of implementing a good licensing mechanism that has a good resistance against piracy. The required mechanism should not use an internet connection at each and every time the software is used.
Then how about a periodic online check of the licence?
When the user logs in the first time, the user verifies the install against his account and a licence file is stored on the users PC. This licence file is encrypted and contains all the data needed to uniquely identify the license. This is all stored on your server.
The licence file expires in set number of days or even months. Logging in after the file expires checks against the account and verifies its legitimacy. You might even consider generating a new licence file at this time.
There should be some smarts that give some leeway in the case that the users internet is down and the licence cannot be registered. Perhaps 7 days.
If the software is reinstalled on a new computer the user has to repeat the verification process.
As the others have stated there is no way to beat a determined pirate, since such a person will hack the code, but this should prevent or slow down casual piracy.
You can check out Microsoft's SLP - I haven't used it, but it definitely looks interesting (yknow, IF you're into MS stuff...)
One important point to note - no licensing mechanism will protect you from piracy, or even substantially reduce it. By definition, the licensing mechanism will be client-side - which is inherently breakable. Take a look at all what happened with DRM...
Your guideline should therefore be usability - the intent should be to use it as a general policy, the good guys will be comfortably limited to what they're supposed to be allowed to do, and the bad guys - well, the bad guys will get around your intent anyway, your best hope is to make it more work.
I'd be very wary of published software protection mechanisms, as they are much more likely to have published hacks. You are probably better off using some of the techniques to get a unique persistent ID and use this to roll your own protection mechanism. I also think that it is a poor idea to simple check the license whenever you run the program, as this leads the hacker to the location of your proection mechanism. IMO, your are better checking the license in a more random fashion, and more than once per session.
FWIW, I use hardware locks (hasp) for my high end desktop software, and device ID based licensing on mobile solutions. If you are selling small quantities of high cost software in a vertical market, IMHO, a good license protection mechanism makes sense, and hardware dongles work well. My experience has been that people will use more licenses than they purchase if this is not in place. For high volume, low cost software, I'd tend to live with the piracy based on increasing the size of the user base and product visibility.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
What steps can one take to mitigate the risk of a one-person team working on a project, especially when that one person is a rather junior programmer?
I ask because I am that junior programmer, and there is no one available/willing to do things like code reviews. Part of the problem, I suppose, is that I am working on web applications in an embedded software company, so most employees' expertise is in a different area.
Recognising this as a problem is more than most "junior programmers" would be able to do :)
Unfortunately most employers don't see the benefits (only the downsides) in multiple people on the same task.
With lack of understanding from your employer on this point, just stick to all the usual rules, such automated testing, documentation, and source control. I know too well that when working alone on a project, it is all too easy to become complacent.
The truth is that the documentation is not just to help others know what your code does. It helps you too. Source control is not just to enable multiple people to work on a project and merge changes, it helps productivity (in the sense that you can easily revert changes), enforces backups, and gives you good tracking of where your time and effort has been spent.
Source control and automated tests are two things that will help in any environment. Those two things alone will mitigate some of the major disasters (lost work, buggy code resulting from constant changes and refactoring).
Beyond that, stick to the basics: K.I.S.S. Keep your code design as simple as possible, keep your classes simple, follow the Single Responsibility Principle and above all, avoid duplication (which will greatly guide your designs). Make use of every resource you have: message boards, other programmers at other companies, friends from school, whatever you have available to you. Even having a mentor you can send e-mail to is helpful.
Best practices aren't much different than for a larger group. Source control, unit testing, follow a style guide for your language, script everything instead of using manual processes, and try to have at least some high level documentation and comments in the tricky parts of code. For specific decisions that are important and hard to change, like how your code interacts with the database, try to find out what approach a well-designed project uses, if necessary by checking on this site.
Unit tests especially are a great way for other people to quickly figure out how your code is supposed to behave, and to check whether their changes have broken anything.
StackOverflow is full of available and willing people to help solve problems and give advice.
Other than that, be prepared to make mistakes and learn from them.
Oh yeah, and get a copy of Code Complete!
As #MattJ mentioned, the fact that you care enough to try to mitigate that risk implies much more seniority than your current job title purports.
I would say that you should do all of the normal things you do to mitigate risk and, where it's not possible to get another resource, just either do it yourself, or skip that step.
It's the best you can do.