I've written a Graphics Design program, with less functionality than Photoshop, but more than MS Paint. I've targeted the application towards teenagers and kids, mainly for educational usages for subject fields such as Graphic Design, Photography and Digital Art. I've started writing it for my final project in school, and feeling quite happy with the work I have done, and having noticed a lack of related software programs for various operating systems, I would like to release it to the general public. It's currently in Alpha testing :)

JRE System Library - It doesn't look like I'm allowed to include with my software...

Java Advanced Imaging API. It looks like I will no longer be using this. Having done some more testing with my application, I have found bugs with this api, following operations with the Tiff format, the primary reason for its use. I'm incredibly sorry for confusions this may cause.

JFontChooser. According to this Stack Overflow Post, it is Open Source, however, I am unable to exactly find which license it really uses in the documentation, nor its download link (However, I have reasons to believe it uses the MIT license). It uses the MIT license, it says at the download location, and the license file in the package is an exact match of the MIT license.

Jython. The OSI claims that this fits the Open Source Definition, and the license itself says that it is very permissive. It should be noted that I am re-evaluating its usefulness within my application, and that I am considering its removal.

Additional Files:

I have multiple image files as "sample" files that users can build upon that I hope to include within my project. These files are images that I have found online on various sites. Many of them are licensed under a Creative Commons ShareAlike license (CC-BY-SA). I'm unsure of whether the ShareAlike clause will be an issue, but I can always remove them and substitute them with pictures of my own (I will likely do that in fact).

Aside from the general development guidelines and files that I created for my use during the development of the project, there's nothing else that isn't mine.

What I would like:

A copyleft clause -> This would allow me to sort of control re-licensing the project under different terms, thus providing different rights.

I would like to see if I can discourage forking and derivatives for my project, more so from the general developer community. As I noted above, I wrote the application for my final (or cumulative) project for school. Since I'm 15, I'm still learning the nips and bits of Java, and it is still a learning experience for me.

I've also tried making a friendly environment from within my application, to submit feature requests, bugs and ideas. I'm planning on doing this from where I will be hosting the project as well (likely on my own website). I will also likely be hosting the source code, as well as the compiled application from there.

I don't mind using a license that people haven't heard of, as long as it is open, and it fulfills what I would like it to do.

I might be interested in dual-licensing here: According to this answer, I would likely license a restrictive license like I've noted above, but then a permissive license when used for educational uses. I would likely use the Apache or MIT license.

I really also want to note that if someone can convince me to license my application in a different way, I am open to these sorts of suggestions.

I want my application to be open, but if I do receive a lot of backlash, I can always just place my program under a copyright, then dictate my own terms, and provided special rights for educational use. But then that's just a pain. I want my program to be Open. This is a learning experience in all directions for me - learning java, learning what makes open projects.

"Discourage forking and derivatives" and "Open Source" are mutually exclusive. Allowing forks is the main motivation behind open source.
– PhilippJul 24 '15 at 19:13

@Philipp I don't want to disallow it, but discourage it, I want to collaborate with developers so that I can further learn the language as well. I quite simply couldn't care if one goes out to fork it, but I want to encourage communication and collaboration in that sense within this.
– Zizouz212♦Jul 24 '15 at 19:17

Downvoted: "I would like to see if I can discourage forking and derivatives for my project,". A license tells downstream recipients of your what they can and cannot do. The license is primarily a legal document that shall help a court to decide whether somebody have breached your license in case of a dispute. A license should not contain ambiguous clauses that permit, but discourage, specific actions, as such clauses would have no legal effect. Requesting an ambiguous clause in a license recommendation question makes no sense and makes the recommendation question lower in quality.
– Free RadicalJul 25 '15 at 2:13

2 Answers
2

Because you are linking against incompatible libraries, the only license you can use of those is the LGPL: The only licensing information I can find for JFontChooser is in the sources jar, which has an All Rights Reserved heading. This means you may not re-distribute this product at all, and the user should provide their own copy.

What this license doesn't do, is restrict forking. The right to (unrestrictedly) fork is one most essential part of free and open source software, and you won't find a free and/or open source license that provides for this. This makes me wonder that if you don't want people to fork, why do you want it to be open source? It's rather contradictory.

Another license with roughly the same conditions is the Mozilla Public License, which is file-level, so slightly more permissive.

For dual-licensing under less restrictive licenses, you could use any old permissive license; the MIT seems to be the most popular choice.

The additional files can be individually licensed under their own license they are not part of the software, or essential to its functioning. Do make sure you fulfill the license requirements of each individual file.

EDIT:

Seeing that JFontChooser is MIT, you now have the following licenses for components:

JRE: Assuming that you link against OpenJDK (and this is generally a very safe assumption, unless you are doing something very peculiar with an alternative implementation), GPL2 + classpath exception

Commons IO: Apache 2.0: GPL3+ compatible.

Java Advanced Imaging API: Not sure. GPL + classpath exception or Oracle Binary Code License. The former is GPL3+ compatible, the later isn't.

Jython: Python Software Foundation License 2.0. GPL compatible.

Annoyingly, GPL2 and GPL3 aren't compatible, but with the classpath exception, you're not bound to the GPL2.

So that leaves you, from restrictive to permissive:
"GPL 3 or later", GPL3, LGPL or MPL

"The only licensing information I can find for JFontChooser is in the sources jar, which has an All Rights Reserved heading. This means you may not re-distribute this product at all, and the user should provide their own copy." If you provide instructions about how the user may provide their own copy, and somebody is really litigious about it, they may sue you for aiding and abetting copyright crime. The chances of this happening are slim, but cannot be ruled out.
– Free RadicalJul 24 '15 at 19:02

Actually, I have found the license after digging further: It's the MIT license. It looks like they didn't apply it correctly though...
– Zizouz212♦Jul 24 '15 at 19:05

@FreeRadical For the all rights reserved case, you only have to say they need to provide the software themselves. How they do that is none of your business. Since they distribute through Maven, you may assume it is intended to be downloaded and used though.
– MartijnJul 24 '15 at 19:16

Now I noticed something, there is the Oracle binary license agreement, and the gpl with classpath exception seems to be for the OpenJDK. Is there something else about this?
– Zizouz212♦Jul 24 '15 at 22:55

"JRE System Library. It doesn't look like I'm allowed to include with my software..." OK, so we need not consider this.

"Java Advanced Imaging API. It looks like I will no longer be using this." OK, so we need not consider this.

"Apache Commons IO Library. The libraries are licensed under the Apache 2.0 license." It is a permissive license with a linking exception.

"JFontChooser. It uses the MIT license." Permissive.

"Jython." Custom permissive license

To summarize, the software you're going to include is either permissive, or has a linking exception. In practice, this means that you can choose whatever licensing you like for your code, including ARR.

Non-code:

I have multiple image files as "sample" files that users can build upon that I hope to include within my project. These files are images that I have found online on various sites. Many of them are licensed under a Creative Commons ShareAlike license (CC-BY-SA). I'm unsure of whether the ShareAlike clause will be an issue,

You can safely include these. The ShareAlike is not a problem. Each license only apply to the independent work (the image) itself, it does not require license compatibility with other images (or with code). This is because these does not depend on each other, so no derivative work is created.

What I would like:

A copyleft clause. This would allow me to sort of control re-licensing the project under different terms, thus providing different rights.

Nope. As explained in the this answer, this is not what a copyleft clause does. And as pointed out in this answer, if you try to put this in a copyleft license, the license will not qualify as free or open.

So re-licensing the project under different terms, thus providing different rights is out of the question, I am afraid. All copyleft let you do, is to say that downstream recipients must license their derivative works under an identical license, it does no let you impose terms that discriminates.

I would like to see if I can discourage forking and derivatives for my project, more so from the general developer community.

There is no FLOSS license with anything like that. Also, words like "discourage" is very confusing if they appear in a legal document such as a license, as they have no legal effect. If you try to put such provisions in a custom license you write for yourself, your license will look amateurish and have less of a a chance of being taken serious (by courts and by developers).

I might be interested in dual-licensing here: According to this answer, I would likely license a restrictive license like I've noted above, but then a permissive license when used for educational uses. I would likely use the Apache or MIT license.

Huh? The answer you link to correctly say that there is no way this would work.
Quote:

So this would not be an effective way to control distribution.

There is absolutely no point in using multiple licensing if at least one of the licenses in the combo is permissive. Permissive licenses means that anybody permitted to do whatever they want with your code - e.g. make derivatives closed source - that is why they are called "permissive".

Combining a permissive license with a copyleft license will negate any legal effect imposed by the copyleft license.

So what sort of licensing should you choose? Well, a free and open license is ruled out, given your requirements.

So let see what you can do by taking a new look at your requirements, but this time dropping the copyleft/free requirement:

I would likely license a restrictive license like I've noted above,

I take this to mean that you want to discourage forking and derivatives for the project.

IMHO, there is no point in "discouraging" people if you can't do anything about if they refuse to listen to you, because the people who're going to do it anyway are not the nice people who enjoy cooperating. No, if you do this, the only people that will fork your project are nasty people who are inconsiderate about the feeling of others (and probably about other things too). If you're serious about this, slap a big red "All Rights Reserved." on it. That will at least give you access to legal remedies if they're not discouraged.