ElkArte Community

Project Support => General ElkArte discussions => Topic started by: emanuele on May 10, 2013, 02:02:15 pm

Title: How to properly (re-)license a theme
Post by: emanuele on May 10, 2013, 02:02:15 pm
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

ETA: I don't remember if the correct one is "re" of "sub" license, well, whatever is the correct one. :P
Title: Re: How to properly (re-)license a theme
Post by: TE on May 10, 2013, 05:28:38 pm
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
Title: Re: How to properly (re-)license a theme
Post by: TestMonkey on May 10, 2013, 05:44:59 pm
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
 */

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

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

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

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

Quote
ETA: 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.
Title: Re: How to properly (re-)license a theme
Post by: TestMonkey on May 10, 2013, 05:46:05 pm

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
Title: Re: How to properly (re-)license a theme
Post by: emanuele on May 10, 2013, 06:59:20 pm
In general: It's fine. My personal take is that it's overkill, too, though. :)
That's why I asked! :P
Title: Re: How to properly (re-)license a theme
Post by: Joshua Dickerson on May 11, 2013, 08:18:44 pm
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.
Title: Re: How to properly (re-)license a theme
Post by: Arantor on May 11, 2013, 08:22:26 pm
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.
Title: Re: How to properly (re-)license a theme
Post by: Joshua Dickerson on May 11, 2013, 08:25:44 pm
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.
Title: Re: How to properly (re-)license a theme
Post by: Arantor on May 11, 2013, 08:49:28 pm
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.
Title: Re: How to properly (re-)license a theme
Post by: Joshua Dickerson on May 11, 2013, 08:52:26 pm
Yep, don't see a way for it to work there.
Title: Re: How to properly (re-)license a theme
Post by: TestMonkey on May 12, 2013, 07:08:04 am
You probably meant something else, but just to be sure.

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.
Title: Re: How to properly (re-)license a theme
Post by: Joshua Dickerson on May 13, 2013, 06:22:39 am
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."
Title: Re: How to properly (re-)license a theme
Post by: TestMonkey on May 13, 2013, 11:23:34 am

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.
Title: Re: How to properly (re-)license a theme
Post by: Joshua Dickerson on May 13, 2013, 07:39:24 pm
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.
Title: Re: How to properly (re-)license a theme
Post by: Arantor on May 13, 2013, 08:19:20 pm
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.

Quote
TBH, debating over this is pointless.

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

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

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.
Title: Re: How to properly (re-)license a theme
Post by: Joshua Dickerson on May 13, 2013, 09:00:59 pm
Probably the best link:
http://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
Quote
But be careful when removing the notices of other developers. Since free software licenses require licensees to preserve notices, wrongfully removing one is a violation of the license from that contributor and may be copyright infringement. If it’s absolutely clear that every remnant of a developer’s contribution has been removed, then it is probably OK to remove the associated copyright notice; otherwise, it’s best to keep it around. However, a requirement to “preserve” or “reproduce” a developer’s copyright notice does not necessarily require that the notice be kept in exactly the same place it started; it’s usually acceptable to move notices from individual source files to a central attribution file, for example.

I am not saying this because I want to remove attribution or anything like that. I am saying it because eventually you get to the point that Emanuele is at where you have 4 or 5 copyright notices for no reason. It is annoying scrolling past all of them when all I need is to put that in a file when I distribute it.

Obviously none of us are lawyers so we're only going on our interpretations. However, I am supplying a lot of links and quotes to support what I am saying. That link that I just supplied explains it out pretty well.

Here goes one to support what you're saying, but I think so long as the copyright is put in with the distribution, it still works. http://opensource.org/faq#preserve-copyright-notices
Quote
Can I strip out the copyrights on Open Source code and put in my own?
Definitely not! This isn't even about Open Source, really: in general, you should not remove a valid copyright notice, no matter what license it specifies. Copyright notices are legal notices; they are also a source of information about the provenance of source code, and if that information is stripped out, recipients of downstream copies have no easy way to rediscover it.
Title: Re: How to properly (re-)license a theme
Post by: Joshua Dickerson on May 13, 2013, 09:06:39 pm
What everyone says about file scope as opposed to package scope is that file scope makes it easier to separate the file from the package. When you do so, you don't need to add in the license information. That could prove to be hard to make people do if they want to individualize the files. So, like I said, if I were distributing a single file - like a class that I expect to be distributed separately - I would add the license information at the top. If I am distributing a whole package - like a theme - I would include a LICENSE file in the root. I would do the same if I were distributing binary files. Not only is it necessary at that point, but it is easier than a hybrid approach of license in the index.php of a smiley directory and then a LICENSE file as well... no point.
Title: Re: How to properly (re-)license a theme
Post by: TE on May 13, 2013, 09:12:00 pm
Allowed or not, it's an act of fairness to leave it in the file  :)
Title: Re: How to properly (re-)license a theme
Post by: Joshua Dickerson on May 13, 2013, 09:25:37 pm
I would say if it doesn't get in the way there's no harm in leaving it. If it becomes 100 lines or each file has 100KB of copyright notice, that's ridiculous and I'm going to centralize it. The last one Norv posted was good for me. I wouldn't mind that one. I would prefer @package and @sub-package tags to be in there so it gets grouped but one or two lines for @copyright is completely fine. Not sure if phpDoc will work with it, but maybe even add them as a comma delimited list. I would also add a LICENSE file in the root of the theme to be sure my copyright stays there.
Title: Re: How to properly (re-)license a theme
Post by: TestMonkey on May 14, 2013, 03:21:06 am
Probably the best link:
http://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
Quote
But be careful when removing the notices of other developers. Since free software licenses require licensees to preserve notices, wrongfully removing one is a violation of the license from that contributor and may be copyright infringement. If it’s absolutely clear that every remnant of a developer’s contribution has been removed, then it is probably OK to remove the associated copyright notice; otherwise, it’s best to keep it around. However, a requirement to “preserve” or “reproduce” a developer’s copyright notice does not necessarily require that the notice be kept in exactly the same place it started; it’s usually acceptable to move notices from individual source files to a central attribution file, for example.

I am not saying this because I want to remove attribution or anything like that. I am saying it because eventually you get to the point that Emanuele is at where you have 4 or 5 copyright notices for no reason. It is annoying scrolling past all of them when all I need is to put that in a file when I distribute it.

The range of possible adjustments still depend on many factors, including on the license. For example, read Mozilla 1.1. license. It requires you to note in the files not only your name, but also that you have modified it. You can't remove even those notes, per the license explicitly.
It's a bad idea (of license requirement), I give you that. But it's true, and binding. (not that anyone has tried it, but meh). Mozilla has reconsidered the wording for version 2.0.

With open development in particular, files are already available very easily individually.

Don't start off with "oh we're not lawyers" please. You have the right to respect the license copyright holders have given you. It's not rocket science, and you don't need lawyers to tell you that if the license says "you don't remove" then it means you don't remove.
If an author comes up with a huge block they declare copyright block, talk to them. They might have thought it necessary for some reason, and will listen to an argument.

There are licenses (i.e. AL 2.0) which have come up with the idea of notice files. But: AL 2.0 requires you to keep notice files if they exist. It doesn't say you can remove notices of copyright holders from files to add them to notice files. Nope.


Back to the point. Some attempt at simplification is a reasonable idea IMO, but with care.
And, it doesn't apply to BSD notices in files.
It is by the way, established practice in FOSS, too, that BSD notices are not to be removed from files. Legally, *and* ethically.

I understand there is potential of a practical issue. I agree with it, even, to an extent. Although this is too early for any valid practical issue.

But I will say this: I am amazed by the apparent "need" to break a license like BSD 3-clause. It's such a simple license. Almost all it requires is proper attribution. For the rest you can do whatever the heck you please.

I would say if it doesn't get in the way there's no harm in leaving it. If it becomes 100 lines or each file has 100KB of copyright notice, that's ridiculous and I'm going to centralize it. The last one Norv posted was good for me. I wouldn't mind that one. I would prefer @package and @sub-package tags to be in there so it gets grouped but one or two lines for @copyright is completely fine.

Ok, just to note please: don't confuse the actual copyright (and license) notices with the rest of the blocks, the rest is optional. Compare the examples above. I have not "removed" any copyright/license notice.
(not even one which is invalid, but lets not get into that atm *cough* :) )

I'd suggest you work with open source projects for a while. Take your time to understand what developers actually do and why. If I may be frank, off-hand scenarios don't cut it.
Title: Re: How to properly (re-)license a theme
Post by: Joshua Dickerson on May 14, 2013, 05:07:18 am
Mozilla 1.1 is not the same as BSD. It is a lot more explicit in its notices. I figured it would be obvious that we're talking about BSD, MIT, and similar licenses that aren't explicit in where/how notices must be displayed.

Browsing the source in a repo is not even close to the same as distributing the package. The copyright/license would be in the root directory and displayed prominently. If that didn't count, then viewing images individually wouldn't count. That's a straw argument there.

It is certainly respecting the license. It is respecting the copyright holders. I am not making up interpretations of the license. These are interpretations by lawyers and the writers of the licenses. I didn't say it should be done on Elkarte. The entire discussions comes from Emanuele's copyright issue. That number of (c) lines can grow quickly. If, for instance, every contributor added their own copyright line (which they'd have the right to do). Or, let's say we started with SMF, then I forked Elkarte, then someone forked a theme for my Elkarte fork, then someone made a color variant of that, then someone decided they wanted to distribute a diff of your color variant to work with their mod. Now you have 6 or 7 copyright notices. That can be confusing on what is copyrighted. So the authors decide that they should add what is copyrighted by whom at the top of the file or above the functions that they created. Now you have 3 lines for each copyright explaining it. I would do away with all of that in my theme and just have a centralized copyright file. Then it can also be found in the output. If I were to create a fork of something, I'd do it early to get people to follow suit.

I thought the link from the SFLC proved that it was legal. I don't see what would be unethical about it so long as it is still there. If all you care about is that you get attribution at the top of every file you modify, use a license that requires that. BSD isn't that license. I don't know their reasoning behind the copyright notice, but I am assuming it has to do with an antiquated approach to copyright of requiring the display of the (c) notice. That's also likely due to other international copyright laws.

BTW, I am not confusing the doc blocks for a copyright notice, but @copyright isn't a copyright notice either. It is there to show the copyright in the documentation... that's all it does. If proclaiming your copyright is necessary in any countries still (which I doubt), I doubt the @copyright block at the top of Elkarte would meet their copyright notice requirements. It doesn't meet US requirements.
Title: Re: How to properly (re-)license a theme
Post by: Arantor on May 14, 2013, 05:16:09 am
Quote
It doesn't meet US requirements.

In what way?
Title: Re: How to properly (re-)license a theme
Post by: Joshua Dickerson on May 14, 2013, 06:36:36 am
No year. There are some official publications if you search for "copyright notice" but the wikipedia article is much easier to link to - http://en.wikipedia.org/wiki/Copyright_notice#Technical_requirements
Title: Re: How to properly (re-)license a theme
Post by: TestMonkey on May 14, 2013, 08:06:00 am
False.
You'll find millions of lines of code for which if you'd go that way, you'd remove everything.

The license has stated what are its requirements. You need to respect them, those notices do not have to obey to any antiquated - and I believe, unapplicable to software license requirements - stuff. They're valid requirements as they are. The license told you black on white.

Browsing the source in a repo is not even close to the same as distributing the package. The copyright/license would be in the root directory and displayed prominently. If that didn't count, then viewing images individually wouldn't count. That's a straw argument there.

No. It's important. People take files individually. Also repos may have more than one license. We have already several subdirectories with their own licensing. We have individual files, with different licenses and/or different notices.

For a theme, it's unlikely to ever be the same. But for medium/big projects, it absolutely is.

Quote
then someone decided they wanted to distribute a diff of your color variant to work with their mod. Now you have 6 or 7 copyright notices.
You just made my point above: yes, they can distribute even separately. That's why it's important to have notices in the files themselves, at least for core files. Otherwise files end up with unlicensed. (though for diffs that will always happen. But at least for files, it shouldn't.)

People have the right to do that. And I do not agree with stripping down notices if they put them in.

Quote
It is certainly respecting the license. It is respecting the copyright holders. I am not making up interpretations of the license. These are interpretations by lawyers and the writers of the licenses.

I am well aware. They are not applicable the way you think they are. And they are not applicable to normal BSD notices.
I am well aware of BSD licensing being respected one-by-one, every single copyright notice. With by the way, the help of lawyers. I am well aware of serious issues starting up in communities when someone didn't think enough and made a patch to remove BSD copyright notices of the authors.
*cough* and I wasn't thinking at some corporation we might know, even. :P

Quote
I didn't say it should be done on Elkarte. The entire discussions comes from Emanuele's copyright issue. That number of (c) lines can grow quickly. If, for instance, every contributor added their own copyright line (which they'd have the right to do).

Yes, they do have the right to. I don't see the "problem" you need to "fix". Just talk to them if you have a better suggestion for their work.

On the other hand, think in practical terms. Just going down imagination and making up huge scenarios you'd "fix" is not leading anywhere.
Practically. For a small project, it is highly unlikely you will really have cases. (i.e. a theme)
For a medium project, development policies on licensing/copyright have their own guidelines with which they just don't accept patches/integrations/whatever with licensing that doesn't follow the project guidelines. (i.e. Elk)
Read the readme I left in the SMF repo. It's a few phrases.

For big projects, it gets messy again.

Quote
That can be confusing on what is copyrighted.
You (almost) never know anyway what exactly is copyrighted by who. Don't imagine the notices tell you exactly the copyright holders. I can write @copyright bluemonkey and you still should respect it.

By the way, a central file for them makes that "issue" worse.

Quote
So the authors decide that they should add what is copyrighted by whom at the top of the file or above the functions that they created. Now you have 3 lines for each copyright explaining it.
They have the right to. You have the right to tell them why it'd be a better idea to do differently. You don't "just get away" with their statements.

And yes, it has even happened, but not for small, but for (very) big projects. Lawyers have kept all appropriate BSD copyright notices lines from the authors intact.
And yes, there are cases when you can adjust them. And yes, there are cases where they're not applicable at all.
It depends.
Title: Re: How to properly (re-)license a theme
Post by: TestMonkey on May 14, 2013, 08:11:03 am
Quote
I would do away with all of that in my theme and just have a centralized copyright file. Then it can also be found in the output. If I were to create a fork of something, I'd do it early to get people to follow suit.

Licensees should not "do away" at their whim.
If you don't like the conditions under which you got code, write it yourself.

Here's the thing: some cases are appropriate (and adjustments) and some are not. Sorry, I do not believe you have experience to make the difference.
I'm reading in your posts how easy you'd be "doing away" with "it". Licensing, specially open licensing, is not a matter of opinion of a mere licensee.

Please don't take it personally. But I will state it clearly. I do not appreciate that you'd be "doing away" with any means you can find. That you seem intently and insistently looking for ways to evade the simplest conditions of an open license.

Here's a proposal: you write hundreds of hours of code, and make it available under an open license. Allow people to use it, adapt it, and reshare it, if only they keep a number of conditions. Then come and let us know how it'd be, when you find your code unlicensed or broken licensed.
No, don't tell us now. Tell us after.
Title: Re: How to properly (re-)license a theme
Post by: Arantor on May 18, 2013, 11:04:37 pm
Here's a question for you.

Let's say that Elk starts out with an SMF file (which is @copyright to SMF at the present time - let's not get bogged down with the details, just bear with me)

If you rewrite 10% of the file, it's still largely SMF contributions, sure.

What if you rewrite 50% of the file?

What if you rewrite 99% of the file? Should it still claim @copyright SMF on it?

(I ask because I'm preparing to clean up Wedge's licensing docblocks and I'm trying to take on board everything that's been said everywhere to appropriately credit etc. but also to acknowledge that there are other bits of code that aren't ours and aren't SMF's but still integrated in there, e.g. other BSD modules)
Title: Re: How to properly (re-)license a theme
Post by: Joshua Dickerson on May 18, 2013, 11:44:41 pm
If it is derived from another copyrighted work, you should keep it in there. Proving percentages of original work is extremely hard. Proving that it came from the original copyright is pretty easy for something like what you're doing... just check the commit history.
Title: Re: How to properly (re-)license a theme
Post by: TestMonkey on May 18, 2013, 11:52:27 pm
(I ask because I'm preparing to clean up Wedge's licensing docblocks and I'm trying to take on board everything that's been said everywhere to appropriately credit etc. but also to acknowledge that there are other bits of code that aren't ours and aren't SMF's but still integrated in there, e.g. other BSD modules)

When it's not longer a derivative, you can very well no longer call it a derivative. A derivative under copyright law.

Now when is that, well, that's a question easy to answer in many concrete cases, a bit disputable in some, and hard to answer in general. It's not really a matter of percentage (though you can use it as indicator).
What I'd suggest: try to compare and see if there is copyrightable code (remaining, of course). In rare cases, I've seen 10-12 lines of code considered copyrightable, but under that, unlikely.
A few quick notes:
Copyrightable code is not exactly an unchanged block. You could change all lines but only in small parts (i.e. rename vars, replace some calls, fix a computation) and the code is still essentially the same. In this case, the changes are not copyrightable, while the original still is (and is present).
For copyrightable assessment, what matters IMHO a lot (and a criterion I use, personally): if a part cannot really be done in any other way, due to constraints (could be a standard algorythm, but also could be internal constraints of the code structure or style), then it probably isn't copyrightable.
The structure of the code matters too. I'm not sure how to explain properly. Instead, may I suggest something like the following, personally I found it very useful to understand copyright for software:
http://www.ifosslr.org/ifosslr/article/view/30/64
Less, but eventually https://en.wikipedia.org/wiki/Abstraction-Filtration-Comparison_test
I have a collection of links somewhere, not at hand atm, but I could come back on it if useful.

Best would be to discuss on examples IMHO.
Title: Re: How to properly (re-)license a theme
Post by: Arantor on May 19, 2013, 12:01:03 am
@groundup: So even if you later completely rewrite it from scratch, you still have to keep the copyright?

For example, I'm thinking about our ManageBans.php file, where the bulk of similarities are things like brackets that happen to be in the same place. There's also a fraction of a common generic list setup (in old SMF style) but that's almost more coincidental than anything else.

See, by that logic, I could *totally* rewrite a file from scratch but still have to give copyright to someone who had absolutely nothing to do the file... is that right?

In that particular case, we are essentially saying that there is a generic list concerning bans, so there are going to be common elements in the generic list setup for the obvious reason (same related purpose) and that can't really be done another way, short of rewriting the generic list, which will probably happen.

So yeah, that's essentially my question: when is a derivative no longer a derivative? I don't have many other examples, but I'm sure that more will come along in time ;)
Title: Re: How to properly (re-)license a theme
Post by: TestMonkey on May 19, 2013, 12:42:17 am
For example, I'm thinking about our ManageBans.php file, where the bulk of similarities are things like brackets that happen to be in the same place. There's also a fraction of a common generic list setup (in old SMF style) but that's almost more coincidental than anything else.

See, by that logic, I could *totally* rewrite a file from scratch but still have to give copyright to someone who had absolutely nothing to do the file... is that right?

In that particular case, we are essentially saying that there is a generic list concerning bans, so there are going to be common elements in the generic list setup for the obvious reason (same related purpose) and that can't really be done another way, short of rewriting the generic list, which will probably happen.

Ah, sure. I think Elk's ManageBans is by far no longer derivative of 2.0 ManageBans. (lets say "no longer", for exactly the purpose of this discussion, regardless of everything else in the fun here.).

I had in mind other scenarios, such as a simpler one: original code starts a list to display in a template, and one adds to it a lot of elements. Elements are simple and don't contain relevant aspects (relevant copyright-wise). In this case, we have a single file, and elements are likely not even copyrightable, even if it's a lot of lines of code.[1] Even less, would they change the original copyright status on the file.

On the other hand. When I use a library, with some functions it puts at my disposal, I'll use them as they are meant to be used, and so do others. Each use is original code, from the perspective of the question. (all other things being equal). For the code we're interested in copyright status of, meaning the client of the library, it's their own copyright alone.

Note: the end result of the use of the library, might be derivative, but not as code modification, so it doesn't affect copyright. It might affect license.

---
[1] Now if we want to have fun, we could imagine the added elements contain raw text which is an original poetry, but that's another story lol.
Title: Re: How to properly (re-)license a theme
Post by: Joshua Dickerson on May 19, 2013, 07:53:58 am
Arantor, you could remove the copyright after changing a single LOC. It all depends on one thing: chance of winning litigation. We're not talking about ethics here because that is a feeling of being "right". We're talking about copyright as in law. If you don't think you'll be challenged or if you are challenged, you will win or if you lose you can deal with the consequences, you can go right ahead and remove it. That is how life/law works.

Now, if you are talking about what is "right" ethically: if it feels wrong, it is wrong; if it feels right, get a second or third opinion just to make sure. I would err on the side of getting those opinions.

Unless your ban system is completely different (unlikely) and the management of it is completely different (possible) than it is going to be a derivative of the original. I don't see how ManageBans in Elkarte isn't a derivative. Once again, it is all interpretation.
Title: Re: How to properly (re-)license a theme
Post by: TestMonkey on May 19, 2013, 08:32:27 am
Unless your ban system is completely different (unlikely) and the management of it is completely different (possible) than it is going to be a derivative of the original. I don't see how ManageBans in Elkarte isn't a derivative. Once again, it is all interpretation.

No, when you modify/rewrite files at a point it'll cease to be a derivative. Where that point is, you need to know. If you don't, consider it still is. By the way, Josh, I'm talking about ManageBans compared to 2.0, not to 2.1. (Ema rewrote the almost same thing in two PRs). So if you compared, make sure you compare that way.
Title: Re: How to properly (re-)license a theme
Post by: Joshua Dickerson on May 19, 2013, 08:48:29 am
when you modify/rewrite files at a point it'll cease to be a derivative
It is all up to interpretation. First, the interpretation of the new developer, then of the old, then of the court.
Title: Re: How to properly (re-)license a theme
Post by: Arantor on May 19, 2013, 03:58:32 pm
Why do you assume I wouldn't completely rewrite something? You should know me by now, if I'm not satisfied with something, I will rewrite it until I am. And so, it is completely different, complete rewrite. Different DB tables, different checking mechanics, different interface, no concept of 'ban items vs ban triggers'.

For example, http://wedge.org/pub/feats/7746/changes-to-banning/msg284139/#msg284139

There's no 'expiring of bans', you don't post-ban through the ban interface, hard banned there = BANNED. Soft banned... that's something else entirely. But it's still through that one interface. If you want to issue a short term ban (or post ban or similar), that's through the warning system (which I also completely rewrote from scratch)
Title: Re: How to properly (re-)license a theme
Post by: Joshua Dickerson on May 19, 2013, 08:49:38 pm
Not that you wouldn't rewrite it, but that there is a very finite number of ways to "ban" someone via an IP address. Then you have to define "ban" as restricting access to a web resource with known parameters such as IP address and login username. Is your ban system a derivative of SMF's? It might have a different skin on it, but if you didn't change core concepts, it will be hard to argue otherwise.

I realize I am also talking about patents here and might even be stepping over in to patents instead of copyright, but the fact is that software lives in both worlds. It is art and it is science. This goes for all designs - which software is. Mechanical drawings on how to build the Model T can be patented and copyrighted. You automatically get copyright and it is a much narrower field, but then comes patents. In a patent you can claim (that's the base of them) the concept of restricting access to a resource based on an IP address (make a separate claim for username, and another for email, and then another for any known parameter... this is how you get them passed and still make them super broad). Now you have two ways of protecting your work: narrow (copyright) and broad (patent). Even copyrights aren't that narrow. If you translate the work to another language, it is still copyrighted under the original. If you go and change every word in it but the sentences means the same, it is copyrighted. Look at how that applies to software - port it, same work; change whitespace, architecture, etc but the end result is still the same - derivative.

That was a tangent that does not really have anything to do with SMF/Wedge/Elkarte, but does have to do with business if you're wondering about IP (intellectual property).
Title: Re: How to properly (re-)license a theme
Post by: Arantor on May 19, 2013, 09:26:42 pm
Quote
Is your ban system a derivative of SMF's? It might have a different skin on it, but if you didn't change core concepts, it will be hard to argue otherwise.

Since you apparently are incapable of reading subtlety or being bothered to look at links illustrating my point... I changed core concepts as I already stated. It is somewhere between being a derivative (since some of the code that integrates it into the rest of the system, e.g. is_not_banned() is derived) and being a complete rewrite (because the admin panel, database tables, queries, structure, logic are all different)

It has different database tables (one table, not two), different UI entirely (as documented in my link), supports IPv6 in ways SMF can't, doesn't support some of the strange constructions that SMF does... doesn't do expiring bans, doesn't do post bans, doesn't do login bans (most of that is covered by the warning system). There are also different structures of bans (hard bans and soft bans), not to mention that reserved words are managed by the ban system (and more powerfully too)

Which is why it's a perfect example of the question. How different does it have to be before it is no longer a derived system?
Title: Re: How to properly (re-)license a theme
Post by: TestMonkey on May 19, 2013, 10:18:18 pm
On the tangent. First note.
Sometimes, as far as I am aware, open source projects and open source lawyers consider BSD has an implicit patent grant. However, some developers prefer licenses which make explicit both a patent grant and a protection from patent claims. (like some stupid claims of those "businesses" groundup speaks about above :P).

Personally, I consider the importance of explicit protection from patent claims, in open source licenses, is a bit over-hyped nowadays. Others mileage may vary. (and does lol.). In any case, there are no open source licenses which reserve patent rights. They:
- either specify nothing (older, classic licenses, i.e. BSD)
- either explicitly grant patent rights to everyone, just like licensing rights; and moreover, they terminate the license to the software for anyone who would initiate a patent claim on the covered software. (i.e. MPL, Apache License)

---
That said.

In a patent you can claim (that's the base of them) the concept of restricting access to a resource based on an IP address (make a separate claim for username, and another for email, and then another for any known parameter... this is how you get them passed and still make them super broad). Now you have two ways of protecting your work: narrow (copyright) and broad (patent).

Huh. This paragraph speaks of "protecting" through patents as if it would be some "good" thing. It is NOT. Patents for software are insanity. You can never be sure that someone did not and will not "protect" through a patent a concept.
What you're saying would mean: you just talk about a complex idea, pick it up and implement it, and your users get asked for royalties two years after, or you hear you should stop your project, 'cuz some "business" woke up they had (or filed yesterday!) a patent, on, huh, "concept of restricting by IP address".
You've got to be joking. Granted, the example is very poor (in all honesty, it's ridiculous) - none of those so-called "claims" would ever be accepted to be filed as patent in any shape or form.
But that's not my point: it's insane to only consider such thing as patents for software. The result of taking it seriously would be: lets threaten or prevent distribution of all development of ban systems in the open source world, will we? Or lets ask royalties from users of open source projects, cuz we haz patent on "the concept of restricting access by IP".

Patents for software would kill open source. Straight on.

It's annoying to me that patents for software are even talked about. US should just drop the thing.
I am not interested in any so-called "protection through patents". I am interested in protection FROM patents, thank you.
(or rather, meh, I mostly ignore it.)

Copyright is explicitly not for ideas, but for implementation of the idea. That allows you to rewrite something you don't want to use for whatever reasons. You did, all fine. Patents affect, in theory, *exactly that*. Your freedom to even write a damn implementation entirely from scratch.
LOL, Josh. On "restricting access on IP address". You will allow me to also just laugh. There's no such thing, and it's insane IMO that anything of the kind is even talked about.


As I said above though, and speaking for myself, patents are annoying talk in open source software but safe enough to ignore. IMO. I cannot take seriously ideas like "claims over the concept on restricting by IPs" :P. Sorry. I'll just ignore such talk in practice.
Well, except for graphics/audio/compression algorythms and such, a sub-field where I know parents are real, filed and acknowledged, and interfering with free development of tools or drivers. But at least those are well known publicly - think mpeg and such -, and complex enough.
Title: Re: How to properly (re-)license a theme
Post by: Joshua Dickerson on May 19, 2013, 10:22:25 pm
I understand you're naturally a dick, but I don't really care if your system is completely different or not. I couldn't possibly care less about the features or changes you've made. The question is rhetorical. There is no answer because, like I said, it all depends on who is interpreting it. If you're asking if it is different, that is different than asking at what point any software is different. If you're wrong, you'll find out in court. If you're right, you might never find out and always have the possibility of being sued or be sure of it after you've been vindicated in court.

Although we want it to be black and white, law isn't.
Title: Re: How to properly (re-)license a theme
Post by: Joshua Dickerson on May 19, 2013, 10:34:00 pm
Norv, I am not a fan of *most* software patents. Though, if you just built the human brain in software, I think you've got ground to stand on. Most patents in general are BS today - at least in the US. I had a class on IP once and the IP attorney that gave it pretty much told us that the USPTO was once proud of protecting free trade through limiting claims. Now they are proud of protecting free trade through unlimited claims.

You laugh at "restricting access on IP address." I have no idea why... there are patents on all kinds of stupid stuff that costs businesses billions each year. I wouldn't even doubt that is patented by someone like Cisco or IBM a long time ago.

It is really hard with copyrights to decide when you've crossed the implementation and in to the idea. When you derive your entire work from another's work, and then change a piece of it, it is tricky to determine when it is a derivative and when it is a new piece of work. You don't really know until you have a ruling by an arbitrator or judge.
Title: Re: How to properly (re-)license a theme
Post by: TestMonkey on June 03, 2013, 03:10:07 am
when you modify/rewrite files at a point it'll cease to be a derivative
It is all up to interpretation. First, the interpretation of the new developer, then of the old, then of the court.

The first statement is mostly empty of content, IMO, sorry. However, on the second statement, allow me a quick correction. In the measure it would be disputed/disputable, then:
it would be first up to the interpretation of the old developer, then of the new developer, then of the development community (if any), then whatever else.