Skip to main content ↑ ↓
How to properly (re-)license a theme Started by emanuele · · Read 39462 times 0 Members and 2 Guests are viewing this topic. previous topic - next topic

How to properly (re-)license a theme

In all the theme file, the headers looks like:
Code: [Select]
/**
 * @name      ElkArte Forum
 * @copyright ElkArte Forum contributors
 * @license   BSD http://opensource.org/licenses/BSD-3-Clause
 *
 * This software is a derived product, based on:
 *
 * Simple Machines Forum (SMF)
 * copyright:	2011 Simple Machines (http://www.simplemachines.org)
 * license:  	BSD, See included LICENSE.TXT for terms and conditions.
 *
 * @version 1.0 Alpha
 */

Guessing, I'd say that the "correct practice" would be to do something like that:
Code: [Select]
/**
 * @name      Minimalist Theme
 * @author    emanuele <emanuele45@gmail.com>
 * @copyright emanuele <emanuele45@gmail.com>
 * @license   BSD http://opensource.org/licenses/BSD-3-Clause
 * @version 0.1 Alpha
 *
 * This software is a derived product, based on:
 *
 * @name      ElkArte Forum
 * @copyright ElkArte Forum contributors
 * @license   BSD http://opensource.org/licenses/BSD-3-Clause
 *
 * Simple Machines Forum (SMF)
 * copyright:	2011 Simple Machines (http://www.simplemachines.org)
 * license:  	BSD, See included LICENSE.TXT for terms and conditions.
 *
 */

Does it sound correct?
I added the author param just because it makes more sense to me to have it in this kind of derived works.
Also I moved the @version above in order to make it clear that it's the version of the theme and not of Elk or SMF.

Questions
  • The css files don't have a license at the beginning...I think this should be considered a bug, am I wrong?
  • Should the version of ElkArte be kept in order to avoid confusion in case of future (possible) re-licensing?
    In that respect, should the SMF notice have some kind of reference to the version we forked? (Yeah, I know this is a more general question potentially worth a different topic...)

ETA: I don't remember if the correct one is "re" of "sub" license, well, whatever is the correct one. :P
Bugs creator.
Features destroyer.
Template killer.

Re: How to properly (re-)license a theme

Reply #1 –

yay, and to make it even more complicated... My theme "elastique" is based of "Minimalist Theme"  ;)
At some point we will probably reach 1000 lines code and 5000 lines copyright  ;D  ;D
Thorsten "TE" Eurich
------------------------

Re: How to properly (re-)license a theme

Reply #2 –

In general: It's fine. My personal take is that it's overkill, too, though. :)

Code: [Select]
/**
 * @name      Minimalist Theme
 * @author    emanuele <emanuele45@gmail.com>
 * @copyright emanuele <emanuele45@gmail.com>
 * @license   BSD http://opensource.org/licenses/BSD-3-Clause
 * @version 0.1 Alpha
 *
 * This software includes code covered by:
 *
 * @copyright ElkArte Forum contributors
 * @copyright	2011 Simple Machines (http://www.simplemachines.org)
 * @license   BSD http://opensource.org/licenses/BSD-3-Clause
 */

Or:
Code: [Select]
/**
 * @name      Minimalist Theme
 * @author    emanuele <emanuele45@gmail.com>
 * @copyright emanuele <emanuele45@gmail.com>
 * @version 0.1 Alpha
 *
 * This software includes code covered by:
 * @copyright ElkArte Forum contributors
 * @copyright	2011 Simple Machines (http://www.simplemachines.org)
 * 
 * @license   BSD http://opensource.org/licenses/BSD-3-Clause
 */

Quote from: emanuele – 1. The css files don't have a license at the beginning...I think this should be considered a bug, am I wrong?

I wouldn't consider it a problem. The license of the entire theme should be the license included in the package. If individual files don't mention any, it's that one.

Some developers insist on licensing css and js. It makes sense if you consider that they're client-side, so they actually get downloaded in the user's browser (so the recipient gets them directly). But personally, I never bothered. And it's a slight network traffic added.
Perhaps if you make a node.js application. But for a few scripts, mmm.

If there are strong feelings about this, we can invent a one-liner for css/js. :)

Quote2. Should the version of ElkArte be kept in order to avoid confusion in case of future (possible) re-licensing?

No, it's not necessary, even if Elk may relicense in the future. I look at it pragmatically: templates are code actually modified. No one can use "the Elk code" from them. They'll grab an ElkArte distribution of the original theme.
So what is the real problem it would solve? There's no confusion (IMO), since what the recipient does is always the same: they receive a particular archive, with a particular licensing of its own. The terms of the archive are the theme author's terms. (not Elk's, Elk's are being respected, but they're not the terms of the final work)

QuoteIn that respect, should the SMF notice have some kind of reference to the version we forked? (Yeah, I know this is a more general question potentially worth a different topic...)

*headscratch*. Not strictly necessary for licensing purposes IMO, but good to be somewhere... More for public awareness, for information, so to speak.
I wouldn't bother for each file header... I think a suggestion is simply to add (if we don't have yet) a note, or a version, either in the general license file, or in the readme. Dunno.

QuoteETA: I don't remember if the correct one is "re" of "sub" license, well, whatever is the correct one. :P
Not that it (should) matter much. Personally I use relicensing too. The meaning here is: the license of a derivative.
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: How to properly (re-)license a theme

Reply #3 –


Quote from: TE – yay, and to make it even more complicated... My theme "elastique" is based of "Minimalist Theme"  ;)
At some point we will probably reach 1000 lines code and 5000 lines copyright  ;D  ;D

LOL
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: How to properly (re-)license a theme

Reply #4 –

Quote from: TestMonkey – In general: It's fine. My personal take is that it's overkill, too, though. :)
That's why I asked! :P
Bugs creator.
Features destroyer.
Template killer.

Re: How to properly (re-)license a theme

Reply #5 –

Agree with Norv - just combine some lines.

You don't need to have the whole copyright/license block on every script either. Nowhere does the BSD 3-clause say that.

Remove whatever you want, so long as the license is in the package.

Re: How to properly (re-)license a theme

Reply #6 –

Part of the reason for the need to separately licence theme JS/CSS files is because what we've seen with WordPress: where the PHP files and templates are GPL because WP forces them to be (because it itself is GPL) but the theme resources are not themselves GPL.

Re: How to properly (re-)license a theme

Reply #7 –

Stupid WP/GPL. Release them under multiple licenses.

If it is just a single file, I might be inclined to include the license/copyright at the top of the file. If it is a lot of files (like a theme), I would put a license document in that directory or somewhere in the distribution. If need be, I would list out the files.

Re: How to properly (re-)license a theme

Reply #8 –

Except that isn't always a solution, in particular if it's a premium theme where the PHP has to be GPL but the assets are explicitly meant not to be GPL.

Re: How to properly (re-)license a theme

Reply #9 –

Yep, don't see a way for it to work there.

Re: How to properly (re-)license a theme

Reply #10 –

You probably meant something else, but just to be sure.

Quote from: groundup – Remove whatever you want, so long as the license is in the package.
No, you don't remove anything. You can add your own or not. (*I* always recommend adding explicit licensing to PHP files, specially with open development, because files can be used alone. Nowhere did anyone say that it's a "must".)
But in any case, you don't remove existing notices.
Last Edit: May 12, 2013, 03:35:05 am by TestMonkey
The best moment for testing your PR is right after you merge it. Can't miss with that one.
 

Re: How to properly (re-)license a theme

Reply #11 –

No, I completely and fully meant remove the notices at the top. You don't need to have them so long as they are in the distributed package. You can debate all day on that, but if you do some searching, seems everyone is in agreement. You can put them there to remind people that file is licensed as such but it only serves as a reminder. The distributed package must contain the notice, as it says in the license itself: "Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer."

Re: How to properly (re-)license a theme

Reply #12 –


Quote from: groundup – No, I completely and fully meant remove the notices at the top. You don't need to have them so long as they are in the distributed package. You can debate all day on that, but if you do some searching, seems everyone is in agreement. You can put them there to remind people that file is licensed as such but it only serves as a reminder. The distributed package must contain the notice, as it says in the license itself: "Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer."

NO.

You retain copyright notices of copyright holders. You don't remove them.
No one is any agreement on such thing. I don't think you found that anywhere. You are a licensee, you don't remove notices at your whim. Never.

Only for your own project, you may add or not. You don't touch others notices 'cuz poof you think so.
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: How to properly (re-)license a theme

Reply #13 –

Copyright notices are not necessary. They are not necessary to protect your work or you. I don't think any country requires that.

The BSD license states that it has to be in the distribution. It doesn't state that every file must contain it. If it did, it would instantly be worthless when you try to apply it to binary files.

TBH, debating over this is pointless. I don't see it happening for Elkarte. I was trying to explain it for Emanuele. If I chose to distribute something, I would remove those notices at the top of every file and put the license and copyright info in one file.

GNU licenses should have them "If you have copied code from other programs covered by the same license, copy their copyright notices too. Put all the copyright notices together, right near the top of each file." http://www.gnu.org/licenses/gpl-howto.html

http://tieguy.org/blog/2012/03/17/on-the-importance-of-per-file-license-information/ <-- recommends per-file but points out it isn't necessary
http://stackoverflow.com/questions/3051651/open-source-licence-header-on-each-source-file-or-a-single-copying-or-both

There are more but it isn't hard with a simple search.

Re: How to properly (re-)license a theme

Reply #14 –

They may not be necessary but if they are put in the file by its author, you have absolutely no right to just remove them again.

The BSD licence does not state that it has to be in the distribution. The wording is fairly suggestive about it applying to wherever the copyright is stated (i.e. references to 'the above copyright notice') and the wording could easily be read as to mean 'wherever the copyright currently is, it must remain' which is certainly the spirit of it if not the letter of it.

QuoteTBH, debating over this is pointless.

It's only pointless if you're not willing or able to understand why these things are important.

QuoteIf I chose to distribute something, I would remove those notices at the top of every file and put the license and copyright info in one file.

That's against both the spirit and the letter of most licence terms.

The bottom line: you only have the right to do this under your own files. Files you didn't originally create, but inherited in whatever fashion, you do have to keep the original copyright attribution.

The examples you give are fine for creating your own files where the total copyright is yours. Except for something like Elkarte, the total copyright is not yours unless you write an entire file from scratch, then it is yours to do with as you see fit.