Skip to content
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

Open
kritzikratzi opened this issue Apr 16, 2014 · 12 comments
Open

License too restrictive #5

kritzikratzi opened this issue Apr 16, 2014 · 12 comments
Assignees

Comments

@kritzikratzi
Copy link

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.

@kritzikratzi kritzikratzi changed the title License to restrictive License too restrictive Apr 16, 2014
@benfry
Copy link
Contributor

benfry commented Apr 16, 2014

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
http://www.oreillynet.com/pub/a/oreilly/ask_tim/2001/codepolicy.html
Though on closer read, the caveats make that more restrictive... I think it should be something on the lines of 1) use it how you want 2) maintain attribution for where it came from 3) you don't get the copyright for this code by using it.

What do you think @prisonerjohn @REAS @shiffman?

@kritzikratzi
Copy link
Author

ah, it seems to differ within the template:
the project uses gpl
https://github.com/processing/processing-library-template/blob/master/license.txt

the example file uses lgpl
https://github.com/processing/processing-library-template/blob/master/src/template/library/HelloLibrary.java

just checked, similar situation for android-template and tools-template.

@prisonerjohn
Copy link
Member

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.

@prisonerjohn prisonerjohn self-assigned this Apr 17, 2014
@daveho
Copy link

daveho commented Aug 18, 2015

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.

@benfry
Copy link
Contributor

benfry commented Aug 18, 2015

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.

@prisonerjohn
Copy link
Member

Right, if Apache is the way to go, I'm happy to switch it in for all the templates.

@benfry
Copy link
Contributor

benfry commented Aug 18, 2015

If it sounds good to you, let's do it.

@kritzikratzi
Copy link
Author

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).

@kritzikratzi
Copy link
Author

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 :)

@prisonerjohn
Copy link
Member

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.

@kritzikratzi
Copy link
Author

in that case apache should be a solid choice.
just thought i'd mention it...

@daveho
Copy link

daveho commented Aug 19, 2015

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.

simontorres pushed a commit to simontorres/processing-library-template that referenced this issue May 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants