6

The Academic Free License 3.0 explicitly allows distributing copies of the work "under any license of your choice that does not contradict the terms and conditions, including Licensor's reserved rights and remedies, in this Academic Free License" (emphasis mine).

Out of the many common licenses around, which of them fulfil this criterion? In an interview, Lawrence Rosen (the author of the AFL) replies to this question: "Apache License, GPL licenses, MPL, EPL, etc., etc. The AFL license is very permissive." However, the FSF classifies AFL as GPL-Incompatible. (This document says it is GPL-compatible, but it's dated 2002 and AFL-3.0 is 2005, so it probably refers to AFL-2.0 or earlier.)

If I am to believe both Mr. Rosen and the FSF, I could say that AFL and GPL are incompatible (I cannot distribute a program combining code under both licenses), but I can "change" the license of the AFL code to GPL and then distribute everything under GPL. Is that so? If not, I repeat the first question: what are other licenses that do not contradict AFL-3.0?

1
  • 1
    I can suggest a process you can go through to arrive at the answer, but not a definitive answer. There are too many "other licenses" (last sentence). I wouldn't want to be penalised for it.
    – lellis
    Commented Jan 24, 2019 at 6:25

2 Answers 2

2

Take a peek at David Wheeler's FLOSS License Slide. It doesn't answer your question, but discusses the area in depth and gives pointers to more details.

The FSF keeps a list of licenses, but they are only interested in whether the license is free (in the FSF sense) or not. Likewise, the Open Source Initiative maintains a list of licenses and discusses them. Again not exactly what you are looking for.

This is one of the problems with the proliferation of licenses. A nice discussion is David Wheeler's Make Your Open Source Software GPL-Compatible. Or Else..

Software licensing is an extremely complex area of the law, much worse if you have to factor in differences in jurisdictions (and when talking software distributed via the Internet, it can't be restricted to just one of them).

-3

Legally speaking, the whole concept of "compatibility of licenses" has no standing.

Mixing up code with different licenses is outright illegal - infringement of copyright law. The same way you can not change the license for work of someone else - only the copyright holder themself can do that.

So in your case the answer is - no surprise - AFL v. 3.0.

Elaboration:

A) The question should be "How can I code and use external libraries/files without infringing any ones copyright?"

Every line of code is proprietary and protected by law and the author of that code has all the rights to it. Regardless of the license it is distributed under (or even without any license), the owner still maintains all the rights to it and only licenses it out to others.

Therefore it is absolutely illegal to mix up code (in the same file) with different licenses because you would change one of the licenses in the process - right that only the actual copyright holder has - not you.

In some rare occasion, if you somehow manage to keep all differently licensed code separated (let's say for example in different files), then you can use that code, regardless of the license - as long as you fulfil all the requirements for those licenses. In such case you can even use GPL code at the side of your own closed source, as long as you distribute the source of said GPL code. You are not forced to license your code under GPL as long as it's separate from the GPL code. If you do modify that GPL code, only then your work goes under the GPL (the modifications, not the other code that is separate from it). Or AFL, in your case.

Legally speaking, it doesn't even matter whether you link statically or dynamically, because you write human code, not machine code, and what happens in the compiler is out of your control.

But in any case, you are obligated to inform both your fellow developers and end users what code has what license and that they would not mix up any differently licensed code in the same file.

So while what I have just explained to you would be perfectly legal, there are people who might sue you regardless and that's one of the reasons you should try to avoid mixing differently licensed code - especially with public licenses.

B) Another reason why you should try to avoid mixing up differently licensed code in the same project is that there are some people who do not understand how copyright law works and they think that when you use any other code aside code licensed under GPL, then somehow magically they have the right to change said license into GPL - which is actually illegal.

C) The reason why OSI promotes the idea that you could use permissively licensed code aside with restrictive code and not the other way around is not legal but practical one. Because for the most part, it's simply not practical to use restrictive code in permissive project - because of the limitations and obligations restrictive licenses burden both the developers and the end users.

But because the threat of someone mixing up the code and changing the licenses (a.k.a infringing someone's copyright) can potentially make you liable for such activities - I would advise against mixing permissively licensed (MIT, BSD, Apache, etc.) code with restrictively licensed (GPL, APL, MPL, etc.) code.

So in conclusion:

My advice would be that using restrictively licensed code (GPL, APL, MPL, etc.) would be legally safest for you.

But you still need to make sure that:

You are going to structure your project in a way, that all the license terms are being met.

All differently licensed code has to be kept separate and make sure everyone understands why they are separate.

You need to make sure no-one else would mix up differently licensed code.

Good luck!

1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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