-
Notifications
You must be signed in to change notification settings - Fork 447
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
License too restrictive #5
Comments
It's currently LGPL (not GPL), though I guess I'd be fine with it being something even less restrictive since it's a "template" and not base code like core or app. Something like the way that examples are treated at O'Reilly might What do you think @prisonerjohn @REAS @shiffman? |
ah, it seems to differ within the template: the example file uses lgpl just checked, similar situation for android-template and tools-template. |
I inherited the licenses from Andreas when I took over the templates and never really paid attention to them. I'm OK with something less restrictive than GPL, and think something that covers @benfry's 3 points would be great. Once we agree on something, I'll switch over the template licenses. |
Here's a possible resolution for the license issue: would it be possible to add some language that indicates that the template's license does not "contaminate" the library that is produced as a result of using the template? This might involve making a GPL exception for any files that are included in the resulting library artifact. Just a thought. |
Maybe Apache? http://opensource.org/licenses/Apache-2.0 I think that covers the points I made in my last comment. We're not trying to make a political statement with the templates—I think the inconsistencies are just because they're copy & pasted from various places. |
Right, if Apache is the way to go, I'm happy to switch it in for all the templates. |
If it sounds good to you, let's do it. |
the fsf has a page to help decide the library type. as i read it, apache should be a solid choice. should it be possible to relicense the template? (imho yes!) if someone uses this as a starting point they might want to use an entirely different license like the gplv2. afaik it's not allowed to remove license headers, unless explicitly permitted. (something along the lines of "It is permitted to relicense this template under an arbitrary software license", making it effectively public domain). |
ok. i asked a lawyer. IF relicensing should be possible he thinks it should be fine with apache+the explicit permission to relicense, but he also said "i'm not an expert on the apache license. it's definitely possible with the CC0 license" . don't mean to cause confusion. it's the licensing itself that's confusing :) |
I'd rather not allow relicensing of the template, as it may go against two of our goals (maintain attribution and you don't get the copyright by using it). As this license only applies to the template and build script and not to the actual Library that it is used for, I'll keep it simple and just use Apache, which sounds just fine for our needs. |
in that case apache should be a solid choice. |
FWIW, I would be happy with the Apache license. One request: it would be nice to have some explicit guidance on what effect the template's license has on the choice of license for the library (I'm guessing that any license compatible with Apache 2 is fine), and how to properly attribute the Apache-licensed components from the template in the distributed library. I have a Processing library in the works that I would like to make available in the near future, and I'm using the template, so this information would be helpful. BTW, Processing is amazing, and I greatly appreciate the efforts of all of the contributors. |
hi!
this is a formality, but i think it would be very cool if the libraries template came with a much more liberal license than the gpl (*). people who want could still narrow it down to the (l)gpl, but i just started working on a library (a wrapper around the edsdk to allow access to canon slrs) that i want to release under the wtfpl.
i understand that this is not really a problem because you probably won't sew me over swapping the license, but it'd be nice to have the libraries template as broadly available as possible.
(*) mit, apache, bsd and wtfpl come to mind. (the last is my favorite because of it's clarity)
best, hansi.
The text was updated successfully, but these errors were encountered: