Table of Contents
Guiding questions
Here are some questions that might help us choose a license:
Use cases
What are we hoping that other people might get out of our code?
- The main reason to open-source is to invite and encourage enthusiasts to contribute to the project.
- A distant secondary goal is to share/allow people to see our methods for solving the problems posable in the interface.
- I think I'm equally willing to contribute code to any project with a free and open-source license, regardless of exactly which license it is. From that perspective, when it comes to encouraging enthusiasts to contribute to the project, I think the most effective licensing choice we can make is to use a familiar and recognizable free and open-source license.
- If we want people to adopt our problem-solving methods, maybe we could consider eventually packaging our engine code into a separate library with a more permissive license.
Position on closed-source forks
If an ed-tech company started offering a closed-source fork of dyna3 alongside their other products, how would we feel?
- This is a bit hard to envision, as it seems quite unlikely. On the other hand GeoGebra has gone from basically a fully open-source community project to something that seems/feels much more commercial and closed. I'd be pretty bummed if some company created major new features/improvements that the open-source side would have to reimplement to distribute freely.
- To prevent such a thing, we'd basically need some version of the GPL or maybe the Mozilla Public License, is that right? I.e., what's known as a "copyleft", rather than just a "permissive" license? I think I've read that projects with permissive licenses, all else being equal, tend to get more interest/activity, because people just don't need to worry much about those licenses? Does that seem right/plausible?
- ChooseALicense.com seems to concur with the above musings. Reading it, the leading candidates seem to be either the Mozilla Public License or the Apache License—those seem to be at the boundary contemplated above. And I'm not aware of any reason to use a license other than the half-dozen or so listed in that guide.
-
I agree that a copyleft license is the right tool to prevent this. I'm still leaning toward the Affero GPL, a license that classifies use in network services as distribution, because I think that would require any web app incorporating dyna3 code to be open-sourced.
-
ChooseALicense.com describes the Mozilla Public License 2.0 as a weak copyleft license. Its summary mentions that under this license, "a larger work using the licensed work may be distributed under different terms and without source code for files added in the larger work." This seems to allow exactly the bummer you mentioned:
I'd be pretty bummed if some company created major new features/improvements that the open-source side would have to reimplement to distribute freely.
I'm also not sure whether use in network services counts as distribution under the Mozilla Public License.
-
ChooseALicense.com describes the Apache 2.0 license as permissive, which I agree with based on my skim of the text.
-
I definitely agree that when I want to use a library or reuse code, I'm much more interested in projects with permissive licenses, because there's much less thinking I have to do before grabbing the code. In the far future, if we develop a useful library version of one or more of the dyna3 engines, maybe we'd want to release that under a permissive license to encourage adoption?
@glen @Vectornaut Is it safe to summarize that Vectornaut would prefer switching to the more restrictive Affero GPL but is OK with the current GPL?