Law is one hell of a programming language, you as a developer will always have trouble understanding it and the lawmakers will always have trouble understanding development processes.
I wanted to ask you about OSS licenses and their usage in proprietary software and vice-versa. We have very many great OSS licenses, like GPL, LGPL, BSD, MIT, MPL, ASL, etc. But what is that area they cover in development terms and what are you allowed to do with this software?
Let’s start with one of the most popular licenses – the GPL family. Basically, you can use it for your own good, but the source always has to be open and any changes you make, must be made public, IF you release your software to public (in any other form than source). Also any derivative work has to be licensed under GPL. LGPL is less restrictive and you can use this code in your proprietary software as a library.
BSD and MIT on the other had does not restrict you almost anything, you only have to say that you based your work on some other guys code and not to bother releasing the source.
So the question is – how far can you go? For example, nobody has set a borderline for LGPL, to when the work is considered derivative.
Let’s look at the issues:
- Context of linking – in developers terms you can say that you are using a has_a relation mostly, but it depends on the language and it depends on the direction. Say you want your proprietary software to use a cairo graphics rendering – so it might be a has_a relation. But then you want cairo to render on your proprietary surface :). Opposite direction, completely different context. Even better one – ATI or Nvidia video drivers in Linux (proprietary modules in open-source system). You can also take a LGPL licensed PHP class and extend it with your code. Does it count as a derivative work or it’s still “using a library”? It’s not a has_a relation, it’s inheritance.
- Inheritance – people have talked about this, but there is no strong opinion. Some say it’s derivative work, some say it’s not, and that it depends on the language/environment.
- Dynamic linking – you are not changing the code in any way, you are just plugging it into your software, or the other way around (think again about the ATI and Nvidia kernel modules in linux)
- Static linking – almost the same, but you are enclosing the OSS license covered binary blob into your proprietary software. Does it count as a derivative work?
- Environment – in the world of scripting languages (like PHP), everything stays in non binary form, so you can still say that you are using a library, not making a derivative work. In native software, you can link things together – statically or dynamically. But, in the terms of kernel development, everything ends up in the RAM as a chunk of bits and bytes, working together in harmony. OSS has been compiled into machine code as well as proprietary code, and the crazy CPU is just jumping between instructions like hell, without any division of which part of the blob is GPLed and which one is not. Of course, the division stays on the file system, and I’m not going to exaggerate the context here…
Where is the boundary between OSS code and proprietary? Is it defined by directory structure or division in different files? How do you define the border between derivative work in software terms? Is it a mutual agreement between developers on some shady bulletin board? I could even say that any software running on Linux is a derivative work, because you are using kernel functions.
So I wanted to make things clear, and I haven’t done it yet, and this is where I would like to ask your to participate, to build this table of do’s and dont’s:
| Context | GPL | LGPL | BSD | MIT |
|---|---|---|---|---|
| Dynamically link open-source into proprietary | No? | Yes | Yes | Yes |
| Dynamically link proprietary into open-source | Yes? | Yes? | Yes | Yes |
| Statically link open-source into proprietary | No? | No? | Yes | Yes |
| Statically link proprietary into open-source | No? | No? | Yes | Yes |
| Copy the open-source code into proprietary one without releasing proprietary code to public | No | No | Yes? | Yes? |
| Change the open-source code without releasing changes to public | No | No | Yes? | Yes? |
| Inherit proprietary from open-source without releasing proprietary code to public | No | No | Yes? | Yes? |
| Simply re-sell the open-source code or binaries | No | No | Yes? | Yes? |
| Deliver legal information (original license, information about original software and authors) with derivative work | Yes | Yes | Yes? | No? |
I would like to hear your opinions, real life experience with these issues, and I would be more than happy if you could help me to finish this table. Also if anyone is interested, I can add some more OSS licenses to this table and some more issues if anyone of you comes up with something important.
Just to add some more reading. Here is a link that inspired me: Comparison of OSS licenses