Closed. This question is off-topic. It is not currently accepting answers.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Today I had a bad surprise learning about some implications of the GPL license, mainly that I couldn't use it as freely as I thought.
Now I know.
What else should I know, and more widely, what should every developer know about legal things like that?
You can separate employees, freelancers, open source projects contributors (etc.) or give a more broad answer.
Twelve Legal Considerations for Software Development
Software is copyrighted if it is made available to the general public. It is no longer necessary to put a copyright notice on the application or in the source code. The owner of the copyright is the author(s) or company paying the author(s).
The copyright of software can be assigned by the owner of the copyright, or it can be retained by the owner and the software can be licensed to the user or users by the owner.
Libraries used in development probably have restrictions in their use and distribution. GPL does not make a library public domain, nor does the fact that the library comes with a development platform. You should read and understand the license before you distribute your application. Some libraries require royalty payments, although this has become less common in recent years.
Software patent lawsuits are crap shoots. You should not, of course, knowingly violate a software patent. However, there is a small but real chance some company will sue you for violating their patent. This may happen even if you develop your software independently, you never heard of the patent, and the patent covers a technique that is intuitively obvious and almost completely unrelated to your software. There is not a lot you can do to avoid this, given the current USPTO policies, other than buy insurance. The good news is that patent trolls generally sue large companies with lots of money.
If you use an employee or freelancer to develop software, you should make it clear, in writing, who owns the copyright to the application, including the source code. Some freelancers and contract development companies consider the source code their own property, leaving the company dependent on the original developer(s). This is legal if it's in the development agreement.
If you have an employee who develops software "off the clock," you should make it clear who owns that software, and what kind of software the employee should be able to write and distribute outside of the company.
If you are an employee or freelancer developing software, you should make it clear who will own the copyright to your application, before you begin development. Also, you should know or clarify who owns software you write on your own time. Some companies have clauses in employment agreements claiming ownership to any software written by a developer during the period of employment, whether at home or at work. Many companies have non-compete clauses in employment agreements that restrict the software an employee can produce for distribution outside the company. Sometimes these restrictions are pretty broad.
A trademark is a name or symbol, not the software itself. If you distribute software, you should (a) make sure your application name and "mark" or design of the name is not "confusingly similar" with other applications, and (b) register your trademark. Date of first use is important in resolving conflicts, so you should document when the application is first used in commerce.
When you name an application, check for registered trademarks, but also check Google. An application with first use of the name may be able to take your name and trademark after your application is successful, even if they have not registered the trademark and you have.
When you use or sign a contract or agreement, make sure both parties understand it. In an employment agreement, mentioning any potentially sensitive areas up front can prevent a lot of problems later. In a development agreement, if both parties know who owns the source code, or who is responsible for upgrades, or who is responsible for maintenance, etc., going into the development project, then there is much less likelihood of a lawsuit after the application has been completed. In a distribution agreement, make sure the distributor understands the responsibilities and term of the agreement.
Every non-trivial application has bugs (or "design considerations" :-)). Any user agreement or distribution agreement should make it clear that you are not responsible for bug-free software, and you cannot be expected to fix all bugs. Make it clear that changes, fixes, and upgrades are made at the option (or best efforts) of the developer, and make it clear who pays for fixes and upgrades.
Even after you consult a lawyer about software development and distribution agreements, you should read agreements from other software companies and see what their lawyers came up with.
I am not a lawyer, and this is not legal advice.
When in doubt, contact a lawyer.
I'm no lawyer but over time I have gathered a few rules of thumb from legal people that you can use to save time:
GPL license is 'copy-left' or 'viral'. It means that any code that you write that depends on a GPL component must also be released under GPL. A good rule of thumb is that if you need a GPL component to compile your software, your software must be released under a GPL license.
You are not obliged to make your source available if you're not distributing your software. For example, if you run the software for internal purposes or on a web server you do not need to release the source. That is why Google doesn't need to release their software that use GPL libraries. It was a key contention point in GPL v3.
LGPL (Library or Lesser GPL) only requires you to GPL your own source code if you incorporate the LGPL-ed library in such a way that it becomes irreplaceable. Your own software do not need to be GPL if you only 'use' the library. Including header files and linking against a .dll/.so of the library is one of the ways you can 'use' LGPL-ed code without any obligations, except for the proper copyright notice.
BSD License (the Apache License is very similar) allows you to create commercial extensions of that use the open source component. That is why Apple chose FreeBSD over Linux as the kernel for OSX.
MPL is very commercial friendly because Netscape thought that they might make some money out of Mozilla at the time the license was written.
It often helps to contact the maintainer of the Open Source project. They are in the best position to advice you about the original intention of the license as well as their own views on open source. Sometimes maintainers are willing to release software under multiple licenses to help you out. Often they are not. Depends on the person who owns the copyright.
The KDE project has a handy matrix
I think Legal Guide to Web & Software Development by Stephen Fishman Attorney is what you're looking for.
Review
An amazing book! Answers nearly
every legal question you can imagine
and some you would have never thought
of. -- John Dvorak, PC Magazine
Covers every imaginable detail
important to such a rapidly growing
and intangible medium. -- Entrepreneur
This book passes my own personal test
for legal guides --with higher marks
than any other legal guide. -- Jeff
Duntemann, Editor, PC Techniques
Magazine
Product Description
Protect your rights, and your hard work!
The laws covering website and software
development are complex and confusing,
but if you don't untangle them, it
could cost you thousands of dollars in
attorneys' fees and lawsuits.
Fortunately, Legal Guide to Web &
Software Development decodes this
complex area of the law, thoroughly
and in reader-friendly English. It
also provides contracts, agreements
and legal forms on CD-ROM, with
step-by-step instructions for filling
them out, so you can protect your
software and website without paying a
lawyer's ransom.
Use Legal Guide to Web & Software
Development to learn:
what kind of legal protection you need
the strengths and limitations of each type of protection
how to avoid infringement
which provisions you need when drafting an agreement
how to obtain permission to use other people's materials
You'll find complete, step-by-step
instructions to draft:
employment agreements
contractor and consultant agreements
development agreements
license agreements
The 5th edition of Legal Guide to Web
& Software Development is completely
updated to provide the latest case law
and statutory revisions.
Some other suggestions :
Working for Yourself: Law & Taxes for Independent Contractors, Freelancers & Consultants (Same author).
Consultant & Independent Contractor Agreements (Same author).
Software Licensing Handbook by Jeffrey I. Gordon.
Practical Guide to Software Licensing for Licensees & Licensors by H. Ward Classen.
The Tech Contracts Pocket Guide: Software and Services Agreements for Salespeople, Contract Managers, Business Developers, and Lawyers by David Tollen.
If a freelancer or contractor: make sure you have good liability insurance and know what's covered under it.
For instance, mine doesn't cover liability for mistakes made in code that might expose credit card numbers. So I don't touch that stuff any more!
For employees : we should be able to give a first round of advice to your clients -- like can they/we use the component we want, in their application ?
For freelancers : we must be able to give strong advice to your clients ; and choose which components we can use for the applications we develop for them.
You course, your word is not as good as the advices a lawyer can get you ; but you can already help for a first round ; for instance, to say "we definitly can't use this because it would mean..."
In the end, the lawyer will know much about corner cases -- but if you can help a bit...
For OSS contributors : knowing some differences between free licences can matter if you care what people can do with your code (redistribute ? modify ? use it in commercial application ? use it in proprietary application ? )
One answer has asserted that the law is not like code. I disagree.
In the early days, IBM paid programmers by the instruction. (Someone I knew said he worked with a programmer who got rich this way. Apparently the guy didn't know how to use the machine's index register; he wrote a memory-zero routine that manually stored zero in each memory address.)
There was also a time (long ago) when lawyers were paid by the word. This helped to popularise practices such as addressing people as "the most highly esteemed such-and-such" and other verbosities.
I just read an answer on SO that said VB.NET 2008 still allows line numbers. You can still run pure DOS on a modern PC. And there is much truth to the joke that all COBOL programs are decended from a common ancestor by incremental changes. Backwards-compatibility, and "historical reasons", are rife in our field.
This is comparable to the realm of law. There are laws which make small (or big) changes to other laws. You've got a kind of dependency-hell. There are some ridiculous historical laws (in Hobart, Tasmania, it's illegal for a man to wear a woman's dress after sunset - because once upon a time, convicts would dress up as women and mug people) that nobody would dream of enforcing, just as there are some historical features in software that nobody uses anymore.
Laws often have unintended consequeuences (bugs!), get used in creative ways (hacks!), contain loopholes (security vulnerabilities!), some of which are intentional (backdoors!), get modified (patches!) or overturned (uninstallation!).
Yes, laws (unlike code) are subject to interpretation. But I think this is rather like code maintenance. It helps to adjust laws to new social norms.
To answer the question directly: every developer should know that law is rather like a ridiculously enormous software project that has been in development for hundreds of years. (Actually, each country has its own project, and they solve problems in different ways.) In theory, after reading a licence you will know what you can and can't do with your code. But if a competent programmer can't spot all the bugs in his code just by reading it, then what chance does a non-lawyer have of analysing the corner cases and grey areas of a legal document?
Like with software source code, you can usually get the gist of a legal document by reading it, but if you need to know something specific, ask a professional.
NOLO (I don't work for them) publishes a good set of legal how to books for the layman.
http://www.nolo.com/products/a-legal-guide-to-web-&-software-development-SFT.html
I would answer this in the same way that I would answer "what should every lawyer know about programming?" That is to say, know that there's no way you can possibly know the in-depth field well enough to do more than the simplest of things. Get an expert.
You should know the basic rights and obligations of the license you are going to use. It's not that hard, and even if there are plenty of them, you need to read carefully only those you are going to use or touch. Just read them, in most cases they are quite clear.
Anything else you could need, well, that depends. Patenting ? Trademarks ? If you need these things, chances are that you are in a company and have a legal department to do this for you.
I would always assume that the developers of a project want any software using their work to be released under the exact same licence. Read their FAQs and legal pages for more information and don't hesitate to contact the developers/maintainers if you are still unsure.
If you want help understanding the details of a licence agreement, talk to a lawyer.
Don't work in a country that has more lawyers than developers.
An extremely large percentage of all (U.S.) software patents are bogus, but you can't pay or wait for them to be invalidated.
If you want to use/develop open source software, use an existing license and don't modify it. Don't go near the borders of what the license is supposed to mean.
The name of a good IP lawyer.
6.If you have an employee who develops software "off the clock," you should make it clear who owns > that software, and what kind of software the employee should be able to write and distribute
outside of the company.
freedom of speech right as stated in most constitutions (esp. if devs make free s/w off-the-clock) can make such terms fail miserably in courts
The law is not like code. It is not a well cast set of steps and rules that can be unambiguously understood.
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 would like to open source my complete application and I don't mind at all people using my code where-ever as long as they keep the copyright notice of the work. I also need food on the table, which license allows me to have some money if say a commercial site/company wants to use the code?
Does it really matter which license I choose? I can just have a "paypal donate" button and choose a liberal license?
any help.
You could follow the MySQL model and dual license your code under the GPL and a commercial license. See here for their license terms
This way anyone who complies with the GPL license gets your code for free. Anyone with a commercial app that isn't GPL compliant has to pay you a fee for the use of your code.
Is your code really that good / worthwhile to go to all the effort? My advice would be that unless you have a truly awesome & polished product, pick a liberal license and add a paypal donation button on the website. If your code is popular you'll get extra kudos, and there are still possibilities for making money in the long term.
This may be a reflection of my own personal projects more than anything, but even so - I'd caution against getting all excited about selling your code until you know there's a market for it.
The license is only part of the process. First you need to think of a business model. What is the value that a potential customer is willing to pay for. You can offer services, training, consulting, additional plug-ins/modules/features etc.
Depending on this analysis you then can look which license fits the best into your business model. That might be a dual license, might be only one. If your business model works better with your software being distributed widely, a more liberal license works probably better, and so on.
Hope this helps a little!
Glen is right: if you use GPL, a commercial company can use your code but they have to open their changes to your code, which they may not be willing to do: so instead they'll contact you and pay for a commercial license.
Yes, it does matter which license you choose. If you don't specify a licence then by defaults all your rights are reserved, and no one will use your code (except dishonest people who don't care about licenses anyways). So if you want your code to gain visibility it's important to use an open-source or free license.
You could also go for a commercial license only. This makes sure no one can use your code (legally) without paying you, but you also run the risk that no one will bother.
No liberal open source license can prevent commercial use of your product, without payment. If you really want payment, you should dual license your code, with a restrictive open source licence such as GPL and a commercial license that removes those restrictions on the payment of a fee.
One option is to make the software freely available, and provide a consulting/support service for your software. Businesses may want your expertise in configuring or extending the software, or providing support when things go wrong.
This of course depends on what sort of software it is.
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 8 years ago.
Improve this question
Contributing to open source can have many forms: working with issue trackers, patches, further development, documenting, funding, etc. Assuming your company uses open source projects, what is the single most important reason why you're not contributing back to the community?
Developers cost us money. Open source does not cost us money. Hence, if we start giving developers time to work on open source software then open source loses its competitive advantage and we may as well give MS a call since at least we can define how much money they cost us upfront.
We do, we're founded on Open Source - but I guess we're special ;)
Anyway, this is not like a true answer to your question, but rather an answer to the "questions" in the other answers I guess. There are many ways to contribute to Open Source. Sure you can contribute code, but the other thing you can contribute is money by donating. Jeff Atwood (one of the founders of SO) did this a couple of months ago to a wiki system system I know.
When I worked for my previous startup we gave WatiN $300. This is a contribution, and probably a both a better (and at least cheaper) contribution then having one of our coders trying to figure out the code model and coding standard etc behind WatiN and then fix some bug and supply a patch.
But the THIRD way to "contribute" to your favorite Open Source project is more subtle, but often the definitive best way you can contribute which is by giving it attention like I just did with WatiN through that link.
I am willing to be $100 on that someone reading this answer will check out the link to WatiN, read about the project and download it and start using it in their own test suites. And they should since WatiN is a great Open Source project and Jeroen the guy behind it is truly helpful!
That is also contributing. Helping your favorite Open Source project get some attention by telling others how great it is!
We do contribute back to open source in the one situation where it would be pure insanity not to. When we fix bugs, we always ensure that they are pushed upstream.
As I say, it would be really insane to not do that, and have the alternative of maintaining a fork.
Our management doesn't understand open source. I'm not sure that our boss understands that we are using OSS for development.
In the last time, our boss wanted to release some stuff as open source, but the package should be bundled with a support-contract, so I don't believe he really knows what Open-Source means.
So in one sentence: we don't give back to open source because our management doesn't understand the concept behind open source.
Update: Now we have an OS-product, but our management do not understand it until today. Actually we did it, because some of our customers talked about open-source (and really meant for free).
We contribute back patches and bugfixes.
We don't generally start new projects, though. We don't really have the overhead to support such a project. Unfortunately, you can't just post a tarball on a website and expect strangers to add features to your code. It takes work to build a community.
Developer time/team resources, and the "appropriateness" of contributing code back.
Meaning that, if we make modifications to an OSS project, sometimes the changes aren't necessarily appropriate to contribute back to the project. This may be because of IP rights, but actually, the most common reason is that we simply don't anticipate that other people would require such specific modifications to the software in the way that we've made it. So generally speaking, such patches don't make sense to send back to the team developing the OSS project.
In other cases, these changes could be sent as a patch to the OSS project developers, but this would require cleaning up/reformatting the code, separating out private company data from the patch, etc. Usually, if we're using OSS software in the beginning, we don't care about such things, because most OSS software is somewhat dirty in terms of code quality anyways (ie, no test cases, coding standards, documentation, etc.). Therefore, the time required to clean up our dirty fixes to already dirty code is usually more time than we want to spend for the altruism factor here.
That said, I have worked at companies that did contribute back to OSS projects when necessary, and those that did not made monetary contributions to some OSS projects or distributions.
In my opinion the biggest problem is that most companies are doing development for projects. If a project develops something that is worthwhile to be published as open source the commitment for maintenance can only be given till the project is finished. After that no more resources are available for further developments, support of the community, bug fixes etc. This usually means a slow death for the open source "product".
Also, some companies are very eager to look at the PR for things they publish, and this usually means to go through all the processes for publications. This is something which in general overwhelms engineers and programmers.
Getting it through legal. Seriously, even as a huge contributer to open source software, as a large company the bureaucracy is a killer. (Hope Legal don't read this:)
The company I work for produces software that is proprietary and our software is highly specialized and is our major competitive advantage over all the other companies in our industry. Can't imagine why Open Source isn't something we encourage.
What about a company that doesn't have developers? Maybe they're not a software group, and are using OSS to save money, a la a web-based group that uses LAMP, but never modifies any of the components?
In our case, we produce extremely customized software for the specific circumstances of a state office. Because of that, our software has no utility for anyone else. Being a state office, we aren't at liberty to "donate" time or money, either.
In theory, we could open-source some of our documentation, but again a lack of demand would make it nothing more than an empty gesture.
Business logic.
If I start building a project where I use the source code for a FLOSS project rather than just a library then I need to develop with an awareness of two factors: the changes to the code to make it do what I want and those aspects that I would be allowed to release to the world.
Generally it's not that difficult to do this, but if deadlines are tight then I'm not going to 'waste' time stripping out our proprietary extensions.
Programmers cost us money, but contributing to open source doesn't generate a cent of revenue.
We do contribute and are very proud of it !
http://hg.nuxeo.org/opensocial is all about our contribution to Nuxeo from Leroy Merlin.
Ok, i doesn't generate a cent of revenue, but it doesn't really costs more. And when people will contribute to our code (patches, bug fixes, extension), this will be code that will cost us nothing.
Moreover, our contribution is now included in the core feature of Nuxeo, so now we will benefit of a vendor certified integration of our code.
I am not sure contributing with money is the best way to help OpenSource software. When Jeff Atwood gave some $5000 to an OpenSource project the lead of the project was grateful... but if I recall correctly he was not too sure about what to do with it.
Developers who contribute to OpenSource projects are not paid to do so. They do it because they like it, want to prove something to themselves, etc... but money is never the cause since they know that they won't probably earn a dime. At best, they might attract attention which may then generate revenues (think new employer, more traffic to their blog, etc...)
Now, I don't say that one should not contribute, but I think that monetary contributions are not as efficient as one might think, companies have a tendency to think that their model (capitalist) naturally extend to everything around them :/
In my opinion, an OpenSource project benefit more from patches/bug reports than from direct monetary contribution, exceptions being hosting the website / repository of the project or financing meetings for the top contributors so that they can discuss face to face when the need arise, but though this cost money, this is not directly giving money.
Even though we do give back to open source as code patches, and releasing open source software I can understand why other companies don't. Because "it doesn't make any profit" :)
I have a copyright section in the contract I give to my clients stating that I retain copyright on any works produced during my work for them as an independent contractor. This is most definitely not intended to place arbitrary restrictions on my clients, but rather to maintain my ability to decide on how the software I create is licensed and distributed. Almost every project I work on results in at least one part of it being released as open source. Every project I work on makes use of third-party software released in the same fashion, so returning the favour is something I would like to continue doing.
Unfortunately, the contract is not so clear when it comes to defining the rights of the client in the use of said software. I mention that the code will be licensed to them, but do not mention specifics about exclusivity, ability to produce derivatives etc.
As such, a client has raised concerns about the copyright section of my contract, and has suggested that I reword it such that all copyrights are transferred entirely to the client on final payment for the project. This will almost certainly reduce my ability to distribute the software I have created; I would much prefer to find a more mutually beneficial agreement where both our concerns are appeased.
Are there any tried and true approaches to licensing software in this kind of situation? To summarise:
I want to maintain the ability to license (parts of) the software under my own terms, independently of my relationship with the client;
with some guarantee to the client that no trade-secrets or critical business logic will be shared;
giving them the ability to re-use my code in their future projects;
but not necessarily letting them sell it (I'm not sure about this, though...what happens if they sell their business and the software along with it?)
I realise that everyone's feedback is going to be prefixed with "IANAL", however I appreciate any thoughts you might have on the matter.
Create a license that grants the client the right to use and modify the software, but restricts distribution outside the organization the software is licensed to.
That should cover your needs, since you state in your contract with the client that you retain control over the copyright of the software, and they license it from you under a license chosen when the contract is signed.
As long as you also sign a NDA when you sign the contract, their secrets will be covered by that.
Edit: Oh yeah, almost forgot: IANAL
Try breaking the project into components with their own licenses. This way business logic has their copyright and generic components have your copyright and open source license.
After considering the two answers given, I decided that a combination of the two approaches would yield the best results.
With that in mind I have defined two types of deliverables; generic and client-specific. The client receives exclusive ownership of the client-specific deliverables upon final payment, and I maintain ownership of all generic deliverables. The client is granted a "perpetual, irrevocable, limited, non-exclusive, non-transferable, worldwide license, without the right to grant sub-licenses (except to affiliates and subsidiaries)".
This change satisfies the requirements of both myself and the client.
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 8 years ago.
Improve this question
We have a series of closed source applications and libraries, for which we think it would make sense opening up the source code.
What has been blocking us, so far, is the effort needed to clean up the code base and documenting the source before opening up.
We want to open up the source only if we have a reasonable chance of the projects being successful -- i.e. having contributors. We are convinced that the code would be interesting to a large base of developers.
Which factors, excluding the "interestingness" and "usefulness" of the project, determine the success of an open source project?
Examples:
Cleanliness of code
Availability of source code comments
Fully or partially documented APIs
Choice of license (GPL vs. LGPL vs. BSD, etc...)
Choice of public repository
Investment in a public website
There are a several things which dominate the successfulness of code. All of these must be achieved for the slightest chance of adoption.
Market - There must be a market for your open source project. If your project is a orange juicer in space, I doubt that you'll be very successful. You must make sure your project gets a large adoption amongst users and developers. It is twice as likely to succeed if you can get other corporations to adopt it as well.
Documentation - As you touched on earlier documentation is key. Amongst this documentation is commented code, architectural decisions, and API notes. Even if your documentation contains bugs, or bugs about your software it is ok. Remember, transparency is key.
Freedom - You must allow your code to be "free" - by this I mean free as in speech, not as in beer. If you have a feeling your market is being a library for other corporations a BSD license is optimal. If your piece of software is going to run on desktops then GPL is your choice.
Transparency - You must write software in a transparent environment. Once you go open source there is no hidden secrets. You must explain everything you do, and what you are doing. This will piss off developers like no other
Developer Community - A strong developer community is required. This must be existing. Only about 5% of users contribute back to the project. If someone notices there haven't been any releases for a year they wont think "Wow, this piece of software is done," they will think "developers must of dumped it." Keep your developers working on it, even if it means they are costing you money.
Communications - You must make sure you community is able to communicate. They must be able to file bugs, discuss workarounds, and publish patches. Without feedback, it is pointless to opensource the project
Availability - Making your code easy to get is necessary, even if it means pissing off lawyers. You have to make sure your project is easy to download, and utilize. You don't want the user to have to jump through 18 nag screens and sign a contract in order to do this. You have to make things simple, and clean
I think that the single most important factor is the number of users that are using your project.
Otherwise its just a really well written, usefull and well documented bunch of stuff that sits on a server not doing very much...
To acquire contributors, you first need users, then you need some incompleteness. You need to trigger the "This is cool, but I really wish it had this or was different in this way." If you are missing an obvious feature, it's extremely likely a user will become a contributor to add it.
The most important thing is that the program be good. If its not good, nobody will use it. You cannot hope that the chicken-and-egg will reverse and that people will take it for granted until it becomes good.
Of course, "good" merely means "better than any other practical option for a significant number of people," it doesn't mean that its strictly the best, only that it has some features that make it, for many people, better than other options. Sometimes the program has no equivalent anywhere else, in which case there's almost no requirement in this regard.
When a program is good, people will use it. Obviously, it has to have a market among users--a good program that does something nobody wants isn't really good no matter how well its designed. One could make a point about marketing, but truly good products, up to a point, have a tendency to market themselves. Its much harder to promote something that isn't good, so clearly one's first priority should be the product itself, not promoting the product.
The real question then is--how do you make it good? And the answer to that is a dedicated, skilled development team. One person can rarely create a good product on their own; even if they're far better than the other developers, multiple perspectives has an incredibly useful effect on the project. This is why having corporate sponsors is so useful--it puts other developers' (from the corporation) minds on the problem to give their own opinion. This is especially useful in the case that developing the program requires significant expertise that isn't commonly available in the community.
Of course, I'm saying this all from experience. I'm one of the main developers on x264 (currently the most active one), one of the most popular video encoders. We have two main developers, various minor developers in the community that contribute patches, and corporate sponsorship from Joost (Gabriel Bouvigne, who maintains ratecontrol algorithms), from Avail Media (who I work for sometimes on contract and who are currently hiring coders on contract to add MBAFF interlacing support), and from a few others that pop up from time to time.
One good developer doesn't make a project--many good developers do. And the end result of this is a program that encodes video faster and at a far better quality than most commercial competitors, hardware or software, even those with utterly enormous development budgets.
In looking at these issues you might be interested in checking out the online version of a course on open source at UC Berkeley, called Open Source Development and Distribution of Digital Information: Technical, Economic, Social, and Legal Perspectives. It’s co-taught by Mitch Kapur (Lotus founder) and Paula Samuelson, a law school professor. I have a long commute and put the audio of the course on my iPod last year – they talk a lot about what works, what doesn’t and why, from a very broad (though obviously academic) perspective.
Books have been written on the subject. In fact, you can find a free book here: producing open source software
Really, I think the answer is 'how you run the project'.
All of your examples matter, yes, but the key things are how the interaction between developers is managed, how patches etc are handled/accepted, who's 'in charge' and how they handle that responsibility, and so on and so forth.
Compare and contrast (the history isn't hard to track down!) the management of the development of Class::DBI and DBIx::Class in Perl.
I was just reading tonight an excellent post on the usability aspect of successful vs unsuccessful open source projects.
Excerpt:
A lot of bandwidth has been wasted arguing over the lack of usability in open-source software/free software (henceforth “OSS”). The debate continues at this moment on blogs, forums, and Slashdot comment threads. Some people say that bad usability is endemic to the entire OSS world, while others say that OSS usability is great but that the real problem is the closed-minded users who expect every program to clone Microsoft. Some people contend that UI problems are temporary growing pains, while others say that the OSS development model systematically produces bad UI. Some people even argue that the GPL indirectly rewards software that’s difficult to use! (For the record, I disagree.)
http://humanized.com/weblog/2007/10/05/make_oss_humane/
Just open-source it. Most probably, nobody will start contributing yet. But at least you can write on the press-releases that your product is GPL or whatever.
The first step is that people start using it...
And maybe then, after users get comfortable, they will start contributing.
Everyone's answers have been good so far, but there's one thing missing and that's good oversight. Nothing kills an open source project faster than not having some sort of project management. Not to tell people what to do so much as to just add some structure and tasking for the developers you are hoping to attract.
Disorganized projects fall apart fast. It's not a bird you just let go and watch it fly away.