Licensing

This article's tone or style may not reflect the encyclopedic tone used throughout the wiki. See Wikipedia's article on tone for suggestions.

"Reading legal mush can turn your brain to guacamole!" - Amiga ROM Kernel Reference Manual: Includes & Autodocs, 2nd edition

Introduction

When the idea for a brilliant new piece of software strikes, Licensing Issues are usually the last thing you want to think about. But Licensing Issues can bite you afterwards, in a way that really hurts. So it might be best to spend a moment of consideration. This text actually does not apply only to OS development, but to software in general.

Probably the scariest thing about software licenses are the endless paragraphs of legalese; we try to keep this text as crisp and short as possible.

Popular Licenses

Here's the most popular ones, with a very short version of the licence (to help you all):

GNU General Public License (GPL):

Users have a right to receive source code, and are free to use, modify, and redistribute as long as sources remain available and everything stays under GPL. Object files linked to GPL'ed code fall under GPL too.

GNU Lesser General Public License (LGPL):

Users have a right to receive source code, and are free to use, modify, and redistribute as long as sources remain available and everything stays under LGPL or (optionally) GPL. Object files linked to LGPL'ed code are unaffected by the LGPL, but users must be able to link themselves (i.e., distribute your non-(L)GPL'ed object files separately, not linked to the LGPL'ed code).

Berkeley Software Distribution (BSD) License:

Users are free to use, modify, and redistribute, with or without source code, as long as the copyright notice within the BSD license remains. Note that there are two versions, slightly different in meaning.

The Creative Commons (CC) License Suite:

This differs from the others in that there are several variants of the license, each of which has its own specific stipulations. Developers can choose whether or not to restrict distribution, derivative use, commercial use, or any or none of those; the only requirement all six versions have in common is that the author get attribution for the original code. This is an increasingly popular alternative to the GPL, as it is considerably simpler but also considered less 'sticky'.

Simple Public Domain:

Copyright is waived, and no restrictions are placed on use, modification, or redistribution. In some countries public domain is not possible, even if the publisher does not live in such a country. Normally it will still grant full rights to the user (except possibly cases in which it is not possible, like for moral rights), because the intention is clear. Nevertheless one should still have a fallback clause permitting full rights to the user. The easiest way to handle using public domain is the CC0.

Proprietary Licenses:

Licensed users are free to use; perhaps (depending on contract) they may modify for own use, but may not redistribute.

No License Information:

Defaults to "all rights reserved", which usually surprises both authors and users...

Being Employed as Software Developer

When you are under employment contract, the code you write during office hours is usually owned by those paying your salary, unless your contract explicitly says otherwise.

In some countries^[which?], a working contract could encompass all the work you do in a certain field of knowledge, as long as the contract is valid, and sometimes even beyond that. That means that, if you are hired to write code at day, the code you write after office hours at home might also be legal property of your employer, the reasoning being that, since your employer paid you for working (and gaining experience) in a certain field, that experience is paid for, and you are obliged to put that experience back into the company that paid you for it. Another line of reasoning could be that you are not allowed, in your spare time, to build a product that could become a competitor to your company's products.

This might sound strange to you, outrageous even. But you really should have a talk with your superior. At best, your superior will see that you really are a dedicated software engineer, happy about having such an enthusiastic individual under contract, and tell you to go ahead with your spare-time project. At worst, you will be told that you cannot work on that project - before you have churned out 10k lines of source code and been sued by your employer.

This is not a joke, or something to be taken lightly. You could lose your job, and a fortune in money on top of that, should your employer play it rough and sue you for breach of contract. The Free Software Foundation requires you to present papers signed by your superiors before accepting your code submissions, and they don't do so because they enjoy bureaucracy.

What this means is, unless you are certain of your legal position, consider the code you work with during office hours to be foreign source, even if you wrote it yourself. Whatever licensing information is given in the source file does apply to you, and if no licensing information is given, that means "all rights reserved", even if you are the author, because chances are you are not the copyright holder.

Merging Source Code

You are looking whether you could salvage some existing source code to insert into your own code base.

• Without License Statement - As said above, if you are employed as software developer and you do not have written proof to the contrary, you are not allowed to take code from your employer's code base, and paste it into your own project. You'll get fired and sued. Don't do it.

You might be surprised to hear that tutorials, or code snippets posted to some forum, are copyrighted by their author unless explicitly labeled otherwise. Legally speaking, that means you must not copy them into your code either. However, this is usually as surprising to the writers as it is to the readers, and you might contact them for an individual license (see below).

• Proprietary License Statement - It is virtually never OK to copy & paste sources that are under proprietary licenses (subject to the actual license). Usually, you won't even have access to the sources.
• Public Domain - Public Domain is the blood type O negative of the software community: It is always OK to copy PD sources.
• BSD License - The BSD license requires you to preserve the copyright notice and the list of conditions that constitute the BSD license. The specific part of source code thus remains under the BSD license, whatever the license of the code it is integrated into. As long as you respect that you are free to use BSD sources in any BSD'ed or (L)GPL'ed project without further notice.
  • (L)GPL'ed projects should be aware that the piece of BSD'ed source may legally be "extracted" later on by proprietary or PD projects without infringing on the (L)GPL.
  • A PD project could do similar, but that means the project is no longer PD as a whole, but PD with a BSD part - which should be pointed out in a prominent place both in source and documentation (if any).
  • I am not at all sure about the legal implications of including BSD sources into proprietary software, as you have to keep the "list of conditions" intact, which would include the permission for redistribution. I've heard conflicting opinions on this. - MartinBaute
• LGPL - If your own project is under LGPL or GPL, you may copy LGPL'ed sources without further notice, as the LGPL explicitly allows to "promote" sources from LGPL to GPL.

Also see the paragraph on (L)GPL versions below.

• GPL - You cannot take GPL'ed source code and use it anywhere else but in a likewise GPL'ed project.

Note that, while LGPL'ed code may be "promoted" to GPL, it is not allowed to do it the other way round (GPL -> LGPL).

Also see the paragraph on (L)GPL versions below.

Separate Translation Unit / Object Code

You have a separate translation unit (i.e., a file or collection of files that corresponds to an individual object file, module, etc., or a binary object file for linking), and you want to integrate it in your project. (Usually by means of including a header file at compile time and linking the binary object when compiling your executable / library.)

• Without License Statement - If there is no license statement, you are not licensed to use or redistribute. Keep away.
• Proprietary License Statement - Subject to the terms of the actual license.
• Public Domain - No strings attached, go ahead.
• BSD License - You have to keep the copyright notice and the list of conditions from the BSD License intact. If you ship binaries only, in the documentation; otherwise, in the source.

According to my note above, I'd advise keeping the BSD licensed unit identifiable apart (as described below for LGPL'ed stuff), to avoid any misunderstandings as to the BSD License applying to the whole of your project, including the right to redistribute. -- MartinBaute

• LGPL - You can use LGPL'ed sources, but projects not (L)GPL'ed themselves must keep them in a separate translation unit.

If you distribute binaries only, you must provide an unlinked version of your object code, so that people could link in a different version of the LGPL'ed part. That's an explicit requirement of the LGPL!

Also see the paragraph on (L)GPL versions below.

• GPL - You can only use GPL'ed sources in a project that is itself under GPL.

Also see the paragraph on (L)GPL versions below.

Reference / Education

The question here is whether code written using X as tutorial material is "a work derived from X" (GPL terminology), and/or "theft of intellectual property" (company lawyer terminology). This heavily depends on what code is involved, just how much of the code you've written is actually based on what you have read before, and who you ask.

• Without License Statement - Assume the worst (lawsuit if anybody finds out).
• Proprietary License Statement - Subject to the actual license.
• Public Domain - Just go ahead, be inspired and reap huge profits; the author won't mind.
• BSD License - The BSD License applies to the code itself, "with or without modification", but does not speak about getting inspired by it. You should be safe to use BSD licensed code to educate yourself.
• (L)GPL - Both the LGPL and the GPL require that any "work derived from the product" must be placed under the very same license.

Hardcore evangelists claim that being inspired by (L)GPL'ed code constitutes a "work derived from the product". Personally, I consider this as much nonsensical as claiming that paying you by day makes a company own what you code by night. It seems as if no such case has yet been brought to court, but the opinion exists, so be careful.

(L)GPL versions

There is a twist to the GPL and LGPL, as they are versioned. A copyright holder is free to specify a specific version of the (L)GPL that sources shall be licensed under, or a specific version "or any later version", or not specifying any version at all.

Take care of this when copying (L)GPL'ed code. If no version is specified, you can assume that the copyright holder didn't care, and add a version specification with or without the "or any later version" part.

But if a copyright holder specified a version, you may neither add the "or any later version" if it isn't there or remove an existing one without written consent of the copyright holder.

Individual Licensing

We only talked about generic licenses in this document. If the licensing for a specific piece of code gives you problems, you can always attempt to contact the copyright holder and ask for an individual license.

For example, if you are putting together a PD library, and all you need for completion is a specific function available under BSD License only, ask the copyright holder whether you may include this one function into your project without having to bother with the BSD copyright notice / list of conditions.

Changing License

As copyright holder of a project, you are absolutely free to change the licensing of your project. Prepare for some flaming from your peers, though, as this is usually quite a surprise for them.

Yes, you are free to release v2.0 of a previously GPL'ed project as proprietary software, just as you are free to release a previously proprietary software under GPL. In the former case, your peers are likewise free to take version v1.9 and continue the project under GPL, as you are not allowed to retroactively change licensing.

The Contributor Trap

There is a twist to this which is equally surprising as forum postings being "all rights reserved" or your employer telling you "all your bases are belongs to us": The contributor trap.

Let's say you have read all the above, and suddenly decided that placing your project under the GPL wasn't that good an idea: You want to change the license. Now, if you worked on your project alone, nothing keeps you.

But, if many other people contributed to your project, you might be in deep trouble, as - legally speaking, and probably morally speaking too - you might no longer be the sole copyright holder, and a license can only changed if all copyright holders agree.

Let me repeat this: If you want to change the license of your project

• from GPL to anything else;
• from LGPL to anything else but GPL;
• from BSD to anything else;
• from some X to some Y I haven't thought about;

you might not be allowed to do so even when it's your own project.

For this reason many projects add "or any later version" to a GPL declaration, because this way it is not longer necessary that all copyright holders of the project consent to the change to a new GPL version. It is also possible to drop the older version of GPL for later versions of the software.

See Also

External Links

• choosealicense.com — a site that helps you to choose an open source license