Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
Question
If you have what you think is a great idea, how do you make your idea open source and ensure that it stays that way? How do you prevent your ideas from getting stolen and patented by someone else?
Background
I recently had an idea about a programming project that I think could be revolutionary. Being a young programmer I realize that I am going to need a lot of help to make this idea come to fruition. I also realize that there are some people who might try to steal the idea and copyright it. I don't know the steps I need to take to make sure that the idea stays open source and how to protect myself from getting the idea stolen. I don't mind if a company decides to make money off of the idea but I do want to prevent one person or company having complete control over it. I have done some searching on the web but haven't found a resource yet that answers my question so I ask you for your help. Any help is greatly appreciated.
Clarification
I'm not looking to make money from
the idea.
I didn't understand the difference
between copyright & patent but now
understand I should have asked the
question using patent instead of
copyright. (question changed)
My goal is to prevent one person or
company from locking up the idea. I
would love to have many people and
companies catch onto the vision of
the idea and run with it. (I can't
imagine what today would be like if
only one company had the rights to
produce engines, electricity, cell
phones, computers... I think you get
the idea :D
I've been down this road myself, and trust me: you can end up wasting a phenomenal amount of time, energy and money trying to protect your idea. Software patents are incredibly expensive and nearly valueless, unless you want to get in the business of suing people all the time. In any event, ideas (especially the "revolutionary" kind) are cheap; there are far more good ideas floating around than there are capable, effective programmers who can bring these ideas into reality.
If your idea is good and you prove yourself capable of executing it, you'll do fine. You're better off putting your effort into that.
As a young programmer, the greatest danger is not that someone will steal your idea. It's that no one will care about your idea. Your biggest goal ought to be to get your ideas and code -- and especially your name -- out there to get people's attention. (Not in an obnoxious way; by doing something worthy of respect.)
One of the ideas behind open source is to make it more attractive for people to work with your existing project than to "steal" it and go off on their own with a fork. Forks are a pain in the ass because you either have to keep merging in changes from the original code, or you ignore the original project and lose out on the work being done there. So it's to everyone's advantage to stay together. You want to keep it that way, as the owner of the project.
Ideally, your technology becomes popular, and as the owner/founder of the project you acquire a reputation, and a deserved position as the Big Expert on it, which will become quite valuable to you. Good luck.
I'm sure you have a great idea, but believe me when I say that a great idea is only a very small beginning. "Stealing" the idea means someone else has to invest the time and effort to take it to market. You still have to put that time and effort in too. If the system allowed everyone to claim ideas and prevent other people from implementing those ideas, we'd be in worse trouble than we're already in.
With the case of copyrights, you have to actually write something (a book, code, etc.) and you automatically own the copyright. The trick is to be able to prove when you wrote it. One easy way is to print it all out and mail it to yourself in a sealed envelope. Don't open it when you get it back. The postmark is a decent proof.
With the case of patents, you can't actually patent an idea without a design. You still have to put a lot of effort into figuring out how it's going to work.
Your best bet, if you really want to keep it a secret, is to not tell anyone. Then, stock up on ramen noodles, pizza, and diet soda, lock yourself in a room for 6 months, and build it. The chance that someone else can "steal" your idea if you do that is relatively slim. You'll be faster than them (the benefit of being the "little" guy) and you're more motivated to get it done first (the benefit of the ramen noodles).
If someone else is already developing it, and you're looking to stop them because "you had the idea first", well, tough luck. With these things it's almost always first-to-market that wins.
There are two issues to address here. Patent and copyright. Ideas, and concepts can be patented before they are implemented. Copyright only applies to the actual implemented work/code.
Firstly, if you just want to prevent the idea from being patented by someone else, all you have to do is put your self in a position where you can prove "prior art", this would usual done by publishing the idea. Once an idea is published in the public domain no one else can patent it because you can demonstrate that you had the idea first. Obviously, this doesn't prevent anyone else from implementing it before you do, it just means that the idea is in the public domain so you will always be free to implement it if you decide to in the future.
If however you want to retain control of the idea yourself that is much harder. You must be the one to patent it. This very much depends on where in the world you are, but is often a long an expensive process. Depending on the jurisdiction you are in it also depends on what effect publishing first will have on your patent application. Some jurisdictions have limited windows of time between publication and patent application. If this is what you want to do you will need to talk to a patent attorney who will be able to advise you. If the idea genuinely is revolutionary, take care discussing it with anyone else before you have made the decision to either file the patent application or published to prevent others from patenting. Patent attorneys should be happy to sign some form of joint non-disclosure agreement (NDA) as part of their contract before discussing the idea.
Secondly, copyright is much easier. Copyright applies only to the actual code, not the idea. Once you have implemented the code for your idea you should publish it with a copyright and license notice. The copyright should specify yourself (or your team) as the owner(s) of the work. The license should tell other people how you are going to allow them to use your copyrighted work - when you speak of open source licenses you are probably thinking of a specific kind of license that permits free usage and modification of your copyrighted code (The two aren't necessarily the same, you can make your code open source, but still restrict its usage in your license - Microsoft have done this with lots of their code). It doesn't grant anyone else ownership. You still own the code, but depending on what you put in your license will depend how free others are to utilise the code themselves. What's important is that the copyright and license only apply to your code, not your idea. If you didn't patent the idea, anyone else is totally free to re-implement your idea themselves in their own code regardless of your copyright and license restrictions.
[Edit: I'm not a lawyer - If in doubt seek professional legal advice]
You can't really copyright an idea, only patent it - which (usually) has a much more rigorous acceptance criteria. However, if you preemptively publish your project with whatever code you do have written, under a license like GPL or MIT License, you are restricting others from taking outright the result of your work - that codebase and related assets, specifically, are copyrighted. This will also ensure that no one else can patent it, since a patent must be original (no prior art).
If you just want to make sure that no-one can patent / copyright it before you, simply write up the idea and 'publish' it. This creates prior art, and would prevent another party from patenting the idea after your publication date. You've got a better case down the line if you publish in a known / respected journal, but this can obviously be quite difficult if your idea isn't sufficiently academic or formalised. However as long as it's out on the web etc. and could be shown to have existed from when you claim then it should in theory suffice.
Bear in mind that this doesn't stop someone else from implementing your idea, they would just not be able to get any legal protection (i.e. a Patent) on it. Of course this does put your idea out in the open, so someone could come along and implement their own version before you.
The only way not to loose the idea is not to execute it. You can feel warm about having a good idea for as long as you wish before executing it. Ze Frank had one The Show about it.
Open source does not mean that you give away copyrights. Open Source is just a licensing method for others to use your copyrighted code. So add a copyright notice to your code and protect it. The fact that it's copyrighted doesn't mean you can't share it. You're just allowing others to use your code, according to the license you add to your code.
You should ask anyone with whom you discuss the idea to sign a Non-Disclosure Agreement, and possibly some form of Product Submission Agreement. You may find, however, that many companies, particularly those who undertake their own research, are not keen to sign this type of agreement.
If you have serious plans to make money from this, you need to talk to an IP lawyer. If you go down the Non-Disclosure Agreement route you'll need professional help in creating the NDA document. If you go down the patent route, you'll need professional help (+ money) to prepare the patent application. And so on.
(IANAL ... and you won't find legal advice here.)
Good ideas are often overrated.
Skype isn't the first voice-over-ip service and there were dozens with that idea before Skype.
But because Skype did the execution better than everybody before them they reaped the profits.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I have a program I wrote and I have been encouraged by folks to release it into public.
What would be the best way to go about it? Just dump it on a public site and hope for the best?
How much criticism will come (on the standards, decisions made etc...) and how best to prepare for that. I have been the sole developer for this app for about two years.
And how much difference does the license (GPL, MIT etc...) practically make?
Any experiences?
A license is a good idea, even if you don't care what people do with the code - most of the time people will happily take code "as is" and if it doesn't do what they want they will just throw it away - but you never know when some idiot might try to sue you because they burned their mouth drinking a hot coffee while reading your code. You may also wish to restrict usage (derivative works etc) where someone else makes profit out of your hard work. Fron the other side of the fence, people who might take and use your product/code like to know where they stand with regard to use/copying/distribution. By asking that your name stays on the code, you can also ensure that you get vcredit for the work, and that any improvements/suggestions that happen in the wild can make their way back to you.
If you just want to give away the code wihtout much ongoing development, then a great place is CodeProject - you can release the application and write a small article describing it, and then it's up to you to decide if/when you will post updates.
If you want other people to collaborate then there are plenty of open-source websites that will support this approach.
As for criticism, you are likely to get a few mails from people who need tech support, or who want to suggest extra features. Most people are very polite though. If you wrote the program for yourself, there is a good chance that when it gets into the wild you will discover all the bits that have to be used in a particular way to work well, and all the additional options that you don't care about but which the product needs to make it applicable to a wider audience - you can get sucked into a lot of support work if you're not careful. Ultimately don't be afraid to say "no" to someone if they ask for something you don't want to support - it's your program and your time after all.
The main thing is to have fun :-)
Using a well-known, well-tested open-source license will make it easier for your users to know where they stand with regard to your code. The worst thing you can do is release your code without a license. No license means no use, since in most jurisdictions software is automatically copyrighted with no right of use or reuse.
If you don't want the project to wither away from lack of interest, you'll need to get it in front of developers. Releasing it at a large open source project site (such as SourceForge, GitHub, or Google Code) will help you get that visibility, and will provide a lot of infrastructure for managing your project. The more you do, the better the chances that others will find it, try it, and use it.
CodeProject is a good suggestion- but it really depends on the platform. Typically users of each major development platform flock to other sites for their Open Source extensions or apps. For example, lots of developers on the Microsoft stack look for things in the Visual Studio Gallery or on CodePlex. SourgeForge obviously has its own religious following as well. I would suggest promoting your new app on a site where you would go to find something like it. The Google page rank of whatever public site you use to host it will also impact how many people find it and ultimately how much criticism (constructive or otherwise) you get on the project. Licensing is always a good plan. It has been my experience that each major open source collaboration site tends to learn towards a specific licensing mechanism, so I would just do what seems to be the most popular if you don't have any specific requirements.
We have been trying now for a while to assist the management (of a customer) with the implementation of a a new system that is custom developed by ourselves, to their requirements. Their old system is text based (DOS) and their employees have been using it for years. The new system is Windows GUI and have many advanced features which will make their lives easier and their organisation more efficient. The problem is that the staff do not want to adapt to the new GUI environment and they are now resorting to be unfriendly and as unhelpful as possible, often placing serious obstacles in our way. The management is adamant that implementation must proceed. The system runs trouble free. We have been consistently friendly and helpful with all parties.
Any advise would be greatly appreciated! Have you encountered something like this before and did you manage to turn it round?
Note:This question is intended to help Programmers etc. with implementation difficulties by sharing experiences and factual solutions that worked. It is not intended to be subjective and indeed Programming techniques may help to solve the problem.
Use the tool
Somebody needs to really understand how the existing tool works. Not just well enough to walk through it; but well enough to do it for real. Why not take 2 weeks and go and do their job with them? That will both improve your understanding of the tool, and may foster a better working relationship with them. And while you're there, perhaps buy the drinks once or twice - it sounds corny, but anything that lowers the hostility, and lets you communicate.
User experience
Getting a good developer (or better: designer) who understanding user-experience is probably key. You can't just completely change their tooling and expect their productivity to remain the same.
Keyboard use:
Think of tools like Visual Studio, AutoCAD, etc - in most cases you don't need the mouse, and "die hard" types wouldn't notice if you took their mouse away. Try to respect this; provide shortcuts / chords (ideally the same as the existing system).
Terminology:
Keep it the same. Don't invent new terms for things.
Talk to them?
This may or may not be possible, but getting a few key users "on board" early can be pivotal; especially if you genuinely empower them to help with the user experience.
Find the faults
In the existing system. Take away their existing pain points and they may forgive you a lot.
Unfortunately it sounds like a case of needing to close the barn doors after the horses have bolted. You really need to get grass roots buy-in on the need for an improved system before beginning the project and maintain that relationship during the development.
By having champions of the system at the "coal face" level in the business would a) make sure you meet not only the management requirements but also the users goals which is all important in a successful system and b) the users get a system to which they have been a development party not just had a system thrust on them.
Getting people to moan about the short comings of an existing system is easy. Describing possible new systems before its create in way which allows the users to comment enables them to feel some control and gives you vital feedback. Be absolutely sure to identifier those killer gripes about the old system and make sure those are addressed in the new system.
Of course this all a bit late for you. The way forward is to create a review forum with the most vocal opponents and put them in a room with you and management. Get them to defend their reasons for not wanting the new system. If you can't show how your new system is better then perhaps it isn't. If you can see how the new system might be slightly improved (the movement may only need to be small) then do that, it may go a long way to get back the feeling of involvement you missed out on before.
I would sit together with the staff or a couple of the more loud mouthed opposers, go through what they find lacking with the system and suggest some of these changes to be incorporated in a future release(s). That way they will pay more attention to your the system and also feel more a part of the process instead of just being handed something like some peon. In addition it would also help avoid any misunderstandings about the system.
Get one / more of the user to be your champion by involving them in the development process. Make sure to choose the right ones. Hopefully one that you can reason with. When launching, do a launch event. Make it a big deal. Not necessarily applied to an application, but I've seen it worked in my previous work environments. If this is too late (you went ahead without any involvement from the actual users before), well... there is always things called staff turnover, lol. Out with the old and in with the new. Make the new users your buddy :).
You have to show some kind of benefit for making the change. A demo / mockup can be useful for this. Choose a manager to demo it to and wait. Let it become his idea. Then it might move forward. Being to pushy can cause a negative knee-jerk reaction which might block further consideration of the idea.
It is sad that software often gets replaced by a management decision without any user involvement and then people wonder why the system is rejected.
I've witnessed this first hand. A guy I once worked was told to develop a new version of an application "in secret". At the end of 6 months development it was shown to the users. It didn't meet their requirements and they were angry they hadn't been involved. Needless to say the software didn't make it into production and the developer left shortly after (I felt sorry for him as he had wasted 6 months effort and actually did a real good job considering the circumstances).
The chances are that the software is inferior to the previous application- perhaps data entry is actually slower (you will be biased as you wrote it- everyone likes to think their software is better).
Re-engage with the users, do some analysis and work out what is bad about the old system. If the new system can address the grips the users have with the old system you might be able to turn this around.
Edit- who was involved in engaged with your developers? Presumably the managers at the client, who probably never use the system? This is another big mistake people tend to make- managers driving requirements.
If the old system is perfect, then it never needed to be replaced in the first place!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I've got a framework for PHP that I've developed for about 3 weeks total, but it's quite ready to be released ... if I choose to do so. In this economy I cannot just take what I have done and release it for free and feel just (because I need the money it could garner), and yet I am torn by my appreciation for open source projects. I want to eat and I want to share as open source. I'm sure some understand my conundrum right off the bat.
As an example of the pros and cons of my project, here's a very quick comparison against CodeIgniter. My framework is 10x faster at the base speed (blank CI versus the basic demo of mine) and gets upto 20-30x faster elsewhere. Yet, my framework lacks many things that CI has like advanced routing (with regex, or named parameters) and ORM. If I was to compare it to a similar framework in another language, I'd call my work the Sinatra, or Ramaze, of PHP.
I need some extra income. This is a flat-out fact, and yet I don't want it to be a strictly commercial project.
I like open source, and I want to contribute my own work. Yes, I know frameworks for PHP are a dime a dozen, but I think I might have something here. So, I don't want to let my work go entirely.
So I remain torn. Licensing can help, but only when people are honest. I don't believe in putting "DRM" into my software. Yet, I don't have enough features to say, "If you donate/pay you'll get X other features!" and make a benefit to this.
How do I (can I) sell this? How do I promote it and release it as open-source for free uses? How do I license my work adequately for these purposes?
What is your general policy or tips for projects like this? Especially when you want a cut of the profit someone would get using your project commercially. What licenses, restrictions, etc, do you think would work in this model?
I appreciate any answers which might help me to figure out what to do.
Edit:
To clarify on what I'm thinking, let me add this: this is my pet project. It's something that I made because I felt its lack in the market of PHP frameworks, and have been maintaining it for my own works. But, unlike most my work, I would really like to make this public. I want people to see it, try it, use it, and work with it.
However, I've put in enough off-hours time into this for it to be just given away. I appreciate the open source model, but I don't see how I can just donate some 80+ hours of work for free for a speculative increase in my "reputation" within the software world. PHP frameworks are a dime a dozen and I think I've made a good one, but I'm sure there are just as many others who've done the same. Mine may be better, but it's got an equal or greater chance of being average to poor.
I'd love to release my pet project to the world under an open source license. But, I'd rather someone not take my work and make software that nets some $30k in profits, and not give me a small slice of it. I'm not being greedy--I wouldn't care if it were only $100 for a profit that large.
I am simply trying to figure out how, when, or if I even should, monetize the work that I've done for myself.
I feel that if you actually believe you have started something big, release it to the open source world. If it get's adopted and becomes a standard for many, this in itself will open many more profit making opportunities for you as the creator/inventor. The biggest potential for you to make big money (in my opinion) is to be a major player/founder of a big initiative.
To be absolutely frank, you probably have an overinflated idea of how good your framework is and how ready it is to be released (in any form).
Firstly, you said it took you three weeks to develop. Well if you can do it in three weeks, so can a bunch of other people and that's a fact.
Secondly, release of a commercial product would require having a license (count on a lawyer for this one), writing documentation, building a Website to promote the product, having some means of payment, getting a suitable legal structure to sell software, insurances (generally speaking you'd need some sort of professional indemnity--open source is generally provided without indemnity; commercial software is different), bookkeeping, accounting and so on.
Third, it's PHP so source code protection will be an issue. My advice would be to treat this as a social rather than technical problem, meaning if someone is going to steal your software, there's not a whole lot you can do. More to the point, don't hurt (or even inconvenience) your legitimate users for fear of pirates and thieves.
Lastly, one of the advantages of open source is that you can get community effort in development. You lose that as soon as you go commercial. Even if you go dual license, you can't take someone's GPLed (for example) code contribution and release it under a commercial license.
You may need money but selling software is generally a terrible way of doing it. A longer term view would be to have you build a profile and a name for yourself by people adopting your framework and the best way to make that happen is for it to be open source. Linux may be free but I can guarantee you Linus Torvalds earns a healthy income from his efforts.
If the framework is indeed good, and sees a minimum adoption after it is released, you might be able to land some PHP consulting work.
For me the main problem with new software is credibility - it might be the best software yet, but if no one is using it and if reviews are nowhere to be found, I don't want to be a guinea pig. Making money from commercial software can be very hard if you don't find customers early on...
You could try the QT model: Dual-license you framework with a free copyleft license (you'll have to check which one is appropriate) and a paid-for commercial license.
You better choose dual licence.
Its similer to MySQL.
The best way may be to ask for donations. I would definitely donate if I liked your framework.
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 7 years ago.
Improve this question
I work at a company where the rule basically is (as I understand it) that you cannot use any code unless (a) you write the code yourself or (b) there is some explicit indemnification clause guarding your use of any other code (like open source code). I am finding this making my coding difficult.
For example, coding samples in books are pretty much use "as-is". Microsoft SDK Code Samples are use "as-is". Blog posts about coding are use "as-is". There are several sites out there with code samples (including SO) that are use at your own risk. No warranties implied or indemnification against intellectual property lawsuits, blah, blah, etc.
Basically, I'm confined to using Asp.Net and the .Net Framework and nothing else and to bar my eyes from accidentally picking something up that I haven't created (ok...that may be my anal interpretation of the rule ;-).
I find this difficult because a big part of learning to code I think is reading other code. Reading blogs that have code, reading books that have code, looking at coding samples, using code from SDK samples etc. Also, I would think it is safe to use code that people have shown to be a good solution or pattern for something and freely put up for others to use. I'm not about to think that I can code everything myself. I definitely have to stand on the coding shoulders of others to reach certain heights.
It could be that I don't understand licensing very well either. From the companie's perspective (I suppose) they don't want to incur any risk of beind sued for IP infringement.
My thought is that you have to weigh risks. Taking a coding snippet from a book is low risk. Incorporating code from an open source library could be high-risk. I say make decisions based on how much risk you are willing to take.
Has anybody had experience working in a situation like this or similar to this? Is this a rare thing or is it common in some sectors? Are there others in the same position like me out there?
Any insight or guidance would be appreciated! Thanks!
Edit:
Thanks for the responses! To clear up some things: I'm not advocating stealing code. I'm talking about code that has some kind of public license that allows it to be used in its defined legal way. The key is there is no indemnification in public licenses in using the code. That means it you use it at your own legal risk (and other risk). If someone sues an open source project that you used code from, you could be roped into the lawsuit as well because you are using the code even though it had a public license.
In 2005, Microsoft was using indemnification to compete against open source venders by promising it's partners that Microsoft would protect them against IP lawsuits. http://www.microsoft.com/presspass/press/2005/jun05/06-22PartnerIndemnificationPR.mspx
So, even if the risk of being sued for IP infringement may be extremely low, it is a non-zero probability. Thus, I can't use any of it. Even if it has a public license of some sort. :-(
The "risk of beind sued for IP infringement" isn't really the right way to think about it. This isn't a "risk" thing.
Either
You have a license and can use the source. There's no risk. You have the license. There can't be a lawsuit.
Or
You don't have a license and you're in violation. Effectively, you will be sued. There's no risk here, either. You're in violation of someone's copyrights (or worse).
Companies are averse to Open Source for a variety of strange reasons. Risk of lawsuit is not one of them.
Things I've heard.
What if it has a virus?
What if it doesn't work as advertised?
What if it "crashes" something? Who do we sue?
None of these are "risk" items. They're "due diligence" items. And mostly, they're easy to address: pick products with enough users that someone else vets the code before you; QA open source as if one of your own people typed it in. Except for one.
This leads us to the real reason. [Hint: It's not "risk of lawsuit".]
There's no one to sue when you didn't perform due diligence on open source.
Most shops don't have real solid configuration management or QA policies (the kind that would stand up in court as best practices). Until they have these things in place, they don't dare think about introducing open source for which you really need solid QA and configuration management.
I think what your company is really worried about is you directly copying large segments of code for which there may be licensing issues, presenting a legal problem to the company if they are caught using it. However, you may read blogs or other non-licensed code and discover a solution which works for the particular problem you are working on. In that case, you would be better off rewriting the code (that is, look at the solution and reproduce it) as opposed to just copying the code and making modifications to it. At my company, that is what they generally recommend for using non-proprietary code.
As well, for small amounts of code (e.g. a standard implementation of a cache) where everyone implements this the same way, every time, your company is unlikely to be afraid of using outside code, as long as you are sure to test it carefully.
By "indemnification", I assume they mean assurance that the code is free of copyright or patent or maybe trade secret encumbrance that they don't know about up front, or that somebody's willing to compensate them if something like that turns up. I've never been in a company that worried about this, nor have I heard of one before.
It's not clear what you actually want here, other than sympathy (and I do have sympathy for people trapped in corporate foolishness). It sounds like the policy is quite rigid, if you're worried about sample code in books. This is a bad policy, and will hinder you, but I don't know what you can do about it. Unlike Joel's blog post on getting things done as a grunt, it sounds like you can't just start doing thing intelligently without being in clear violation of corporate policy.
Not knowing your situation, my suggestion would be to look for another job. This one will definitely stifle your professional growth, and a company with that policy is unlikely to be reasonable about it.
(It would be nice if you could assure them there was no danger, but that's not true. People have lied about copyrights, although open source projects tend not to, and only a fool would claim definitely that a large chunk of code did not infringe on any patents in the US; even if it was written a year before software patents were first awarded, that would be merely good grounds for a court fight, rather than avoiding a court fight. GPLed software is actually better than BSD software, since it requires some patent licensing downstream, but it can't deal with third-party patents. Of course, if they're that worried about being sued, writing in-house software is no solution. That can infringe on patents.)
You could rename the variables and how would they find out? Do they check every line of code ? Universities tell you that all the time, not to copy code without referencing. Why don't you try coding something and useing parts of code you find in the Internet?
Generally you will use more from communities like stack overflow or blogs than from open source projects.
Finally since the code has no warranties, its at your own risk.. well the is the same case if you came up with the code by yourself: its at your own risk.
Hope that helps... and good luck.
It could be that I don't understand licensing very well either. From the companie's perspective (I suppose) they don't want to incur any risk of beind sued for IP infringement.
My thought is that you have to weigh risks. Taking a coding snippet from a book is low risk. Incorporating code from an open source library could be high-risk. I say make decisions based on how much risk you are willing to take.
I'm not sure if I understood correctly. If you are saying that license infringement is fine when you don't get caught, I will have to disagree with you.
You can learn by reading code without breaking laws or getting fired. Just don't copy the code to your company's code base if the license doesn't allow it.
If you're not aware of the "clean room" concept, then there's always that approach. Have a friend look at some open source code and get them to tell you how they think it works. Diagram it out, and then code it yourself.
If it worked for IBM, right?
Keep in mind that not all Open Source is GPL. Your company can copy as much BSD-licensed code as they like. BSD-licensed code has made it into OS X (that's probably my biggest understatement of today) and to a lesser extent Windows NT.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
A (non-technical) friend of mine has asked me how to make a website. I get this question all the time. After a few questions I found out that she has an idea that could turn into a commercial site. I described three options to her:
a) Get a book/enroll in a class/follow some online tutorials and learn how to do it. She's pretty smart and her personality seems like a good match for this sort of thing so I'm sure she could learn but she doesn't have a lot of time spare. Maybe if she started with one of those WYSIWYG editors at first? I stressed that this would take a longer than a couple of weekends of playing around.
b) Hire someone to build it. Ranges from ultra cheap to ultra expensive, crappy to good and everything in between. I didn't mention sites like Rentacoder because she hasn't worked on a project like this before and doesn't know what to ask for. At this stage she'd likely ask for a Youtube-MySpace-Google for a few hundred bucks because she doesn't yet understand just how much is involved.
c) Find someone technical and partner up with them. I explained that this can either work really well or be a disaster because she'd have to give up some of her ownership of the idea.
How do you respond in these situations?
Depending on the nature of the required website (ie whether she needs shopping carts etc) I often recommend first creating a blog, although it's often not the best format, it can be used to quite good effect at times. I've seen a number of small retailers for example, using a blog to advertise their wares.
It depends on the person and their motivation. Your friend sounds like she should take option b) or c). She's probably not so much interested in the technical aspects of making a web site as she is in seeing her idea come to life, or maybe running her own company based on the idea.
Well in general there are several steps:
Determine the subject of the website.
Determine the target audience.
Decide on a general layout and look and feel.
Decide which techniques to use.
Design the overall structure of the site.
Collect content and images.
Implement the site.
Most of the times, these steps are carried out by more than a single person. Because they all require their own specialization.
I think that the only realistic options are B and C. Non-techies will almost never come to grips with real web site development. With all due respect to those who have advocated technologies such as ASP.NET or PHP - it won't work. In fact, you are likely to be fielding questions for weeks on end as to why things don't work. You'll have to bear these questions until the person, having failed, gives up.
If they have the resources, then I would strongly recommend the "hire an expert" route.
In either realistic case, they must get a legal agreement in place. If she does hire an expert, be sure that the agreement expressly stipulates that this is a "work for hire". If your friend doesn't demand a work-for-hire clause then she will have no legal means to stop the developer from using the exact same code she just paid for in creating a competing site (at least in the U.S.). Just to emphasize: they would have no legal means to prevent the developer from starting their own competing site without a work-for-hire clause - the courts won't even hear the suit.
Now, if it is really just a brochure site or something similar, and they still want your advice, then it depends on whether they use a Mac or something else.
If they are a Mac user, I tell them to try booting up iWeb and using it to feed a .me account. Just plug in some pictures and some text, upload to your .me account and you are done.
If they are a Windows user, I direct them to Register.com or a similar online Web Site template-based site builder.
For your sake, don't volunteer to help unless you are really sure you have the time to essentially build the whole thing for them! You can ruin friendships this way: friends and family, having no clue what really goes into the construction of a site, almost invariably assume that it is "trivial" for you. If you delay or fail to get things done quickly enough, they'll almost always assume that you are blowing them off and they'll resent you for it (can you tell I've been there?).
It depends on how confident she is that this thing will succeed or, alternatively, how unwilling she is to share ownership. I'd definitely not recommend (a) for something that has commercial value. Beyond the time-to-market factor, initial impressions are something that is very hard to overcome. If she has the cash and is possessive of ownership, then (b) could work well. It's a bigger financial risk, though.
I'd probably go with (c), but then again I'm on the other side of the equation. There are lots of ways of structuring a partnership that would help her maintain ownership, though probably not complete ownership since no one wants to work for nothing. Some combination of b/c is probably best - some less pay in exchange for a small stake in the business. I'd definitely see a lawyer before doing (c) and maybe even before doing (b) just to make sure any agreement she has with the developer precludes them taking the code and running.
There are really two questions here: should she learn how to write a website and, if so, how.
If she has a commercial idea and she only wants to learn how to write websites to market it, I would suggest that she does not bother. Outsource instead.
If you have someone who to trust then only 3rd option is realistic. first one takes years to give out good result and with second one you never know what you get.
Buy her a book for her birthday on ASP.NET or PHP.
A bit of topic but here it goes...
We have ONE web designer at our company(we are about 10 programmers), we usually make some jokes like: "You do not work, you just sit there making drawings all day long" (just for the record, she is very competent and does her job pretty well).
So one time she stares at my monitor for about 2 minutes while i am working on a web application, and at some point she says: "Sooo that's what you do? Formulas and stuff?".
From that day on we all say "I do formulas and Stuff" when asked for what we do at work, as for most people, saying that and saying you develop web applications is the exact same thing.
Developing a web site is not as trivial as places like GeoCities or Google Pages would make it appear.
Here is a list of things you need to know about or consider when publishing a site.
If she owns a Mac or doesn't mind to acquire one, I would suggest her to have a look at iWeb. Otherwise, starting a blog on a platform such as blogger would be a nice first step for a non-technical person.
I always give the same answer, HTML. I say what it does and then tell them to get a book. If they get what it is about they will follow their own course of action.
Unless you're a web designer, 'how do I make a website' is a similar question to 'how do I make a television'. You don't, you buy one. So this question is probably 'How do I procure a website?'.
This breaks down into:
Working out what you want:
What user features do you want
What do you want the UI to look like?
What admin features do you need?
Do you already have a graphic design/logo/color scheme, etc.
Finding someone to make it for you
How do you find them? Referrals? Local web dev companys? Friends?
Do you care which technology they use?
Are you going to project manage it?
How do you know they're doing a good job?
Are you clear on issues like scaling, support, maintenance?
Ideally, find a single company who is comfortable helping you work through all the issues. Less ideally but also good, find a consultant or company that will help you with the top level stuff and assist with production of technical specs that you can then take to a development company to produce.
(Edited for formatting)