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

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

Reply #15 –

Probably the best link:
http://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
QuoteBut 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
QuoteCan 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.

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

Reply #16 –

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.

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

Reply #17 –

Allowed or not, it's an act of fairness to leave it in the file  :)
Thorsten "TE" Eurich
------------------------

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

Reply #18 –

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.

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

Reply #19 –

Quote from: groundup – Probably the best link:
http://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
QuoteBut 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.

Quote from: groundup – 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.
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 #20 –

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.

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

Reply #21 –

Quote It doesn't meet US requirements.

In what way?

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

Reply #23 –

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.

Quote from: groundup – 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.

QuoteIt 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

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

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

QuoteSo 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.
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 #24 –

QuoteI 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.
Last Edit: May 14, 2013, 03:13:55 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 #25 –

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)

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

Reply #26 –

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.

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

Reply #27 –

Quote from: Arantor – (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.
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 #28 –

@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 ;)

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

Reply #29 –

Quote from: Arantor – 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.
Last Edit: May 18, 2013, 06:49:08 pm by TestMonkey
The best moment for testing your PR is right after you merge it. Can't miss with that one.