What should every developer know about legal matters?

When in doubt, contact a lawyer.

The name of a good IP lawyer.

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 ? )

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'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

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!

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.

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.

The law is not like code. It is not a well cast set of steps and rules that can be unambiguously understood.

1. Don't work in a country that has more lawyers than developers.
2. An extremely large percentage of all (U.S.) software patents are bogus, but you can't pay or wait for them to be invalidated.
3. 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.

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.

Twelve Legal Considerations for Software Development

1. 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).

2. 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.

3. 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.

4. 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.

5. 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.

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.

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. I am not a lawyer, and this is not legal advice.

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