3

I would like to publish an open source program, but I am not sure which licence I should use. Here are my criteria:

  1. Copying and modifying the source code must be allowed.

  2. The copyright notice and the license must be included in all copies of the program.

  3. If changes are made and published, there must be a mention that changes were made, and a pointer to the original (for example: URL to the original source code, or copy of the original source code) must be provided.

  4. The license text is short and understandable by a normal software developer.

Are there licenses that meet all these criteria?

2

As far as I know, no license meets these exact criteria. Contrary to the other answer, I recognize that #3 is not a purely technical requirement [1]: If you were to license permissively, and someone took the code and incorporated it into a closed source work, there would be no way to diff/whatever to see if changes changes were made to their copy of your code, unless the license explicitly had your stipulation in it.

I'm also starting with the supposition that you basically understand the difference between copyleft and permissive licenses [2]. Maybe you've even looked at several licenses, and found them wanting. I'm also assuming that when you say requirement #2, you mean it the conventional way: a LICENSE/COPYING file is distributed with copies of the program and source, but not necessarily compiled into the program, nor popped up when installing [3].

Finally: I am not a lawyer. Out of the licenses I know of, here's how they compare to your requirements:

GPL/LGPL/AGPL (and the few other "copyleft" licenses)

These meet requirements 1 and 2.

Requirement 3 is not met, but since the source must remain open to its recipients, an interested party could discern if changes were made through technical means.

Requirement 4 is not met. The "header" that explains that the software is available under that license and the comes with no warranty boilerplate is typically pretty readable, but the entire licenses are much bigger and I'd say you need to know some legalese or be otherwise familiar with the license to really understand all of the details. It's revealing that most [A/L]GPL violations come from people not understanding what compliance requires (no citation off the top of my head, but I believe you can find statements to this effect from the FSF themselves).

Obviously these licenses come with the caveat that a user cannot redistribute modifications/copies of the licenses code without keeping the same license. In the case of the [A]GPL, and possibly other copyleft licenses I'm not aware of, there's also a "viral" effect - the details of exactly what makes those licenses "infect" code that uses the licensed code are too extensive for this answer - if you go this route there's plenty of other places where this is documented in-depth: just be aware that there's enough misunderstanding out there about the details that you should really cross-reference anything you see said on this topic with multiple sources.

MIT/BSD*/ISC/etc (that whole bunch of short "permissive"/"copyfree" licenses)

Meets requirements 1, 2, and 4. Well, #4 is met in so far as any legalese can be readable by the average person: All licenses generally use words and phrases which have very specific meaning based in either written or case/common law, which the layperson is liable to misinterpret the exact nuances of.

But, as a general rule, all of those licenses are pretty clear: do whatever, but all copies (whether source or binary) must also include this copyright+license. The ISC is probably both the most readable, because it omits certain boilerplate that's pretty much part of universally recognized international law (Berne Convention and other treaties which included the same provisions) - I can't say off the top of my head if that omission makes it easier or harder to people to accidentally misread the license, however.

Some have a provision preventing others from using your name/organization/whatever in marketing materials associated with their derivatives. This might be partly in line with what you're trying to do with requirement 3. For example, the 3-clause BSD has "Neither the name of the nor the names of its contributors may be used to endorse...". E.g. Let's say you released some implementation of a new networking protocol with that clause: Microsoft/Google/Apple/whoever could use it, but they couldn't advertise "featuring user1387866's networking code!". (They'd still have to include the copyright notice when distributing their stuff: the point of this clause is to prevent your name from being used in a way that implies you're affiliated with them, endorsed them, or worked with them.)

I suspect, however, that one of the things you might want is that if they screw up your code with their changes before redistributing it, there will be more of a barrier from people associating your name with their broken variant.

So, in the whole, requirement 3 is not met, although you can at least get part of the requirement in easily: since the copyright notice and license must be distributed with every copy, you can include your link-to-the-original inside the copyright notice. For example, instead of just the typical:

Copyright (c) 2016 John Doe <john.doe@example.com>

..you might do:

mysoftwarename
Copyright (c) 2016 John Doe <john.doe@example.com>
https://example.com/mysoftwarename/

Note that, as a not-lawyer, I don't know if some legal interpretation using bovine-feces-quality logic will lead someone to conclude that a given permissive license actually doesn't require that the URL get included. This still doesn't address your desire of having a boolean "this copy was changed from the original" noted.

Other

I've never seen a license meet requirement 3. But some licenses do impose some specific requirements for redistribution, however: For example the Apache Public License v. 2.0 specifically requires that if a NOTICES file is included in the copy you got, you must include the substantial portions thereof in an easily accessible form (except note that that's my layperson rewording: the legalese in the license uses different words and for all I know has some subtle implications).

As a general rule, I don't think even the MPL or APL is short-and-understandable enough to meet requirement 4. Perhaps your definition of short-and-readable is more generous than mine.

Final thoughts

Out of the licenses I have any exposure to, I've never seen a license that meets the exact requirements as stated. Off the top of my head, your best bet is likely to start with one of the very short permissive licenses, and add a clause requiring the inclusion of a URL, and requiring a specific statement, like "This software uses mysoftware name[, with modiciations]", at the beginning of the reproduced copyright notice.

My non-lawyer intuition is that a permissive license with such an addition would be just as broadly compatible with proprietary, permissive, and copyleft code, as your other typical permissive licenses.

Yyou might also find the debial-legal mailing list useful, and especially for if you go the roll-your-own route, I recommend inquiring there as well: I've personally found it useful in considering certain licensing issues, in particular, it's a good place to check if a given uncommon/unusual/rolled-your-own open source license is likely to have pitfalls or impose burdens on libre software users/maintainers/distributions that could impede wider adoption. I suppose there's likely some BSD mailing list out there which could similarly check if your license would impose burdens on proprietary use-cases.

Footnotes

[1] I don't have the reputation to comment, and there's no good way for me to suggest an edit to that answer without essentially scrapping or invalidating a lot of the answer.

[2] It's best to explicitly state that in the question - those answering can better understand what level of depth you're looking for in the answer, and you have to contend with less answers which make erroneous assumptions.

[3] Although you may have seen Windows installers pop up an EULA-like prompt presenting the license, and a lot of GPL software has typically included a copyright notice in their help text or other program outputs: The GPL family of licenses actually includes a provision for user interfaces showing "appropriate legal notices". But many licenses do not specify this explicitly, merely requiring that attribution/copyright information be included with the software in some form.

  • If you were to license permissively, and someone took the code and incorporated it into a closed source work, there would be no way to diff/whatever to see if changes changes were made to their copy of your code, unless the license explicitly had your stipulation in it. - Ummm... Not quite. Every licence that I know of requires attribution of some sort, even if it's not readily accessible. Despite that, it's generally good practice to do so anyway. – Zizouz212 Feb 8 '16 at 2:09
  • @Zizouz212: Yes, attribution is required: But that doesn't tell you if the copy of your code that they took was used in unmodified or modified form, which is what that section was referring to: "if changes were made to their copy of your code". So for example, if I wrote a function that just sleeps for five seconds, ISC licensed it, then a proprietary project used that code, they're required to reproduce copyright+license, but not to reveal if they changed it to sleep for 6 seconds. – mtraceur Feb 8 '16 at 4:11
4

Your third requirement is a technical one, more easily fulfilled by tools like git diff which can help track all changes made to a forked version. Apart from that, broadly speaking, there are two kinds of FOSS licenses and both cover your other three requirements:

  1. Copyleft or freedom licenses: These are GNU GPL, LGPL and Mozilla Public License. Copyleft licenses are aimed at protecting the freedom of the end-user. Whilst all FOSS licenses involve open sourcing the code, copyleft licenses protect your users' freedom by ensuring that any derived or altered work is also applied the same license. In other words, if you release your software under GPL/LGPL, then whoever modifies your work also has to release it under the same license. This ensures that no proprietary firm can just take your software and make it a closed-sourced, freedom-curbing one. Forgetting this liberal ideology for a moment, if you are a solo developer or a small firm who writes software, then this set of licenses is ideal for you.

  2. Permissive or open-source licenses. These are MIT, Apache, BSD, etc. They are also called do anything licenses, because they give the user of your source, essentially and practically all rights to do anything they want with it. The only difference between them is in the written legalese material, and it is a standard practice in the industry to include this material in a LICENSE file, thus taking care of your fourth requirement (this practice is prevelant for copyleft licenses too). Again, forgetting about the ideology thing that drives the open source camp (innovation in software development by open sourcing), the practical matter is that permissive licenses only make sense if you are a large company like Google. If you are a solo developer or small firm, there is always the risk that a mighter contributor can just fork your code and abuse your IP. If you have used a permissive license, you can't do anything. With copyleft or GPL, you will have at least some recourse in that case.

1

I'd reconsider. Go to any random, reasonably active, project at e.g. github and look at the many, many changes that flow into the repository. Just listing the summary of the changes and the author will soon be larger than the source itself. For what use? Better keep it in a public accessible source code control system, then changes are visible and usable (for e.g. finding out which change introduced a bug). This requires a strong "vanilla" version, which everybody uses (at most with minor changes, and synchronizes frequently). The Linux kernel is a case in point, as are the various BSD flavors. There probably are many others. It should be clear that this doesn't come for free.

Another take is the licence for TeX (check out CTAN). You are allowed to get a copy, modify it and release changes, but only as TeX changefiles, i.e., essentially differences to the original. And your modified version can not be called the same as uṕstream. Yes, D.E. Knuth is allowed to get away with this, he stated that TeX is bugfree, and nobody has been able to contradict him (there is a sizeable reward for anybody who finds a bug). No, you probably don't qualify for doing the same.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.