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

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

Reply #30 –

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.

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

Reply #31 –

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

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

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

Reply #33 –

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)

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

Reply #34 –

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

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

Reply #35 –

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?

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

Reply #36 –

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.

Quote from: groundup – 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.
Last Edit: May 19, 2013, 04:37:26 pm 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 #37 –

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.

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

Reply #38 –

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.

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

Reply #39 –

Quote from: groundup –
Quote from: TestMonkey – 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.
Last Edit: June 02, 2013, 10:44:24 pm by TestMonkey
The best moment for testing your PR is right after you merge it. Can't miss with that one.