Writing Open Source Software? Make Sure You Know Your Copyright Rights

http://blog.smartbear.com/software-quality/bid/275129/writing-open-source-software-make-sure-you-know-your-copyright-rights

by wagtail • 13 years ago

49 17 13 years ago

blog.smartbear.com

ds9• 13 years ago

Parts of the article are very misleading. There are ambiguous statements, outright errors and general incoherence.

"...shun copyright licensing altogether. When they do that, they put all their collaborators at risk and themselves face potential liability claims"

You're exposed to claims if you use someone else's code without permission. But if you simply fail to specify a licence for your own code you do not incur any risk.

"Since that convention [Berne] was put into place, all software development involve copying and derivatives, Phipps said; all programming without a license potentially infringes on copyright"

Complete rubbish. Because there is a Berne Convention, you have to copy code instead of writing something new??? Of course not.

Independent creation is a complete defense against any copyright claim (tho not against patent claims). Again, copying others' work without permission may infringe, but one's rights in one's own code do not depend on specifying any particular licence (as long as you don't sign away rights to someone else).

"That's why [if you want to start a new project] you need to apply for an open source license" (brackets in original, paraphrasing Phipps of OSI again)

More nonsense. As soon as you write some code, you own the copyright, and if you don't specify otherwise you retain all rights provided by statute. If you want it to be an open-source or "Free" (in the Stallman sense) project, you do need to specify a licence that allows others to contribute without risk of you suing them - but you don't have to "apply for" a licence. The latter phrase implies asking someone to grant you something, there is no such requirement. You're free to apply any licence of your choice to your own code, an existing one or make up a new one.

The part on "work for hire" is not as bad but still ambiguous on some points. Generally your employer can't claim rights in anything you do outside of your day job unless it is using code or ideas from the day job, or unless you signed away your rights in a contract. Using the employer's time or facilities would put your rights at risk.

I haven't read the rest but it is poorly written. There are better sources of info out there.

ethomson• 13 years ago

Disclaimer: IANAL

> You're exposed to claims if you use someone else's code

The article doesn't say that the author of the software is at risk if he/she shuns licensing. It say that their collaborators are at risk. Which is true. Because as you point out, "as soon as you write some code, you own the copyright."

If you were to write some code and not place it under a legitimate open source license - "shun copyright licensing altogether" as the article states - then you have placed collaborators at risk. If I were to modify that code, redistribute it, etc, then I've taken on liability and you could sue me for infringing your copyright.

jeffdavis2• 13 years ago

The context of the article is collaborative open source development. People who collaborate copy code freely back and forth, so it's important to have a license.

Nursie5• 13 years ago

Yeah this - “That's why [if you want to start a new project] you need to apply for an open source license.” - is just weird.

Maybe it's a misquote and for wasn't originally in there.

Also don't really like this - "If you want public domain, use the MIT license"

If you want public domain then use public domain, it's just that you need to know what that means. Perhaps you do know what that means and that's exactly what you want.

What I would take from the article (about the only thing really) is that it's important to think about this stuff, and to think carefully before giving rights away.

darkarmani• 13 years ago

> You're exposed to claims if you use someone else's code without permission. But if you simply fail to specify a licence for your own code you do not incur any risk.

I think they were thinking that if you open sourced your code, you were accepting patches and bug fixes. If your licensing didn't automatically extend to those patches, the patch owner would retain all rights to that section of your code.

niggler• 13 years ago

Relevant: http://www.codinghorror.com/blog/2007/04/pick-a-license-any-...

Nursie5• 13 years ago

Amusing but the description of the GPL is a bit off

"The archetypal bearded, sandal-clad free software license. Your code can never be used in any proprietary program, ever! Take that, capitalism!"

GPL absolutely can be used in closed source, it just can't be distributed as closed source (see the much rumoured, heavily customised Google-internal-linux as an example). The AGPL is more like the statement above.

falcolas• 13 years ago

Sadly, the definition of "distribution" is so vague that many lawyers won't allow you to "distribute" your code to a box you don't own outright, in an effort to reduce their liability.

I've been in a few companies where this was a problem, since we were working in part for the government, which required us to run our code in nodes which were owned by a separate contractor. The lawyers interpreted that as distribution, and we had to replace the GPL'd portions of code we were using.

jeffdavis2• 13 years ago

Some projects are easier and safer to work with than others. The PostgreSQL project doesn't require assignment, and the license is BSD (without advertising clause, of course) so there isn't much to argue about.

But in any case, you do need to know whether you have copyright ownership of the code or a suitable license before you use it in a contribution.

j_s• 13 years ago

With an awareness of the ideology the source, this is helpful: http://www.gnu.org/licenses/license-recommendations.html

udp• 13 years ago

So if I accept pull requests without asking people to sign a CLA, what kind of ramifications could this have for my project in the future?

Also, if the license says "Copyright <author> et al." (as many license headers do), does the copyright actually belong to the contributors as well as the author? How is this determined?

Nursie5• 13 years ago

(IANAL)

Git isn't my primary source control solution -- edit: corrected in view of useful information below --

If you accept pull requests and pull data into your repo from other folks without a asking them to assign copyright or sign a very open CLA then that means the copyright is now joint.

The ramifications of this tend to be that you cannot re-license the code without their permission, unless the original license says you can.

Example - your project is GPL, you accept submissions from a bunch of other people. You decide you want to release a closed-source binary-only commercially-supported extra-special version with plugins and hotsauce. You can't unless you get permission from everyone that's contributed to the project, because the rights you have to their submissions are governed by the GPL. With copyright assignment, you as the now sole copyright holder could do this.

Ramifications will vary by license and by what you want to do.

tholmes• 13 years ago

You have the right idea about pull but you're mixing up pull and pull request. Pull is a git verb that means to get code from another location. A pull request is asking someone else to get my changes.

So for an example, if you found a bug in some open source software you used you could make a change in the code that fixed it and then file a pull request with the original author of the software. This asks them to incorporate your changes.

zobzu• 13 years ago

thats why the licenses recommend to put the license on top of EVERY SINGLE FILE. Failing to do so, is, well, not a good idea.

The pull request will then either contain a join copyright (then only THIS file has a joint copyright), either no change to copyright (explicitly assigning the copyright to you alone)

that's if the copyright goes to <your name, email>, not "et al", obviously

merijnv• 13 years ago

The writer of a patch is the copyright holder of that patch, as a result you cannot legally distribute your code with the patch applied unless you have a valid license from the patch writer (Because part of the code is copyrighted by the patch writer, who has exclusive rights to distribution and reproduction).

If the patch is submitted under the BSD/GPL/MIT license or similar, you are fine. All of those explicitly grant anyone that complies with those licenses to redistribute the patch code (and thus the patched project), with the usual restriction that your license is compatible and that said copyright notice and author names must be reproduced in the resulting entity. Normally you'd maintain an AUTHORS/CONTRIBUTORS files listing everyone's name in addition to the license files. There's no real hard and fast rule for this, though. Keeping the names in the contributed files would also work, for example.

The situation is somewhat murky if the patch writer specifies no license. In this case you are technically not allowed to redistribute the patched code. If the codebase is on github and licensed under some open source license you could (try to) argue in court that that implies the patch is submitted under the same license as the original code, but whether that defense works is up to the judge.

Writing Open Source Software? Make Sure You Know Your Copyright Rights

Related Stories