Wedge

I missed a few but by and large I do remove them as I go, I try to make sure I check at least. Some of the strings you've pulled out lately aren't properly used in SMF either...Bad idea. Quite a few strings are identified programmatically, never directly, such as most of the errors in the Errors language file that have error_ as a prefix, or compound ones like we use in the newer numeric context function. We'd probably end up spending more time hunting down false positives at present.

Because I remember how thoroughly you're doing this these days, going as far as to remove the French versions as well, so I was surprised to find this line today... Made me panic a bit :lol:Yeah, the previous one I found, I added the 'SMF bug' header to it, to mention it's also a SMF problem. But the new one, I checked in SMF and it wasn't there. Hence my question. :)Of course, but we could find them anyway. I'd just like for a tool to allow us to narrow down a list of suspects.

We're human, we miss things, it happens. But it's not something that's hell to fix after, fortunately.In that respect it would help; there are a LOT of language strings, and having a tool to indicate possibles might be useful, but I'd suggest we do it nearer to release, simply because I think we have enough to do without chasing down a list of false positives, since Errors.*.php alone will generate many, as will Who.*.php.

SMF is BSD licensed. Throuought your development process, you have honestly described the process of deriving Wedge from SMF. As long as you follow the licensing agreement, you are honest.

I am guessing you will be more proud of your work if you change the constant name, the variable names, and the session name, regardless of the additional work it might cost you in the future. That pride might be a good enough reason to make those changes.

Be very, very careful with that statement. I could very easily repeat most of what ttForum did, rebranding the software throughout, even released it as a paid package and still be well within the terms of the licence - provided I retained the copyrights in the code.

I'm not disputing that it's not exactly pleasant for us to be taking from SMF without giving something back, but I feel firmly that I gave a lot more to SMF than I've got back from them so far...

Yes, we can postpone $txt to later -- but remember how we postponed changing SMF stuff to Wedge for later...? I'm doing it now because I fear I will forget later, and I'd rather have done it before... :PWe are giving things back.

- Several years of work for the SMF community from the both of us. We gave that without getting anything in return. I think at least half of the SMF team agrees that it's only fair to consider we don't owe SMF anything -- and it's the other way around.

- The changelog. It might seem like nothing, but as I said multiple times, it documents the entire list of SMF bugs that we fixed. It's up to the SMF team to process the changelog, analyze what they need changing, and do it themselves. I made over 400 bug reports at Mantis, including many *after* I was post-banned from SMF. I didn't suddenly stop spotting and fixing bugs in SMF... The only difference, now, is that I can't submit them directly to SMF because they removed my beta tester account. And even then, I'm still making the changelog public and thus the list of SMF bugs is now accessible.

- The ideas. We published our feature list months ago, and we're now discussing publicly as much as we can of our current ideas and implementations (just look at this very topic, since we're totally OT here.) Ideas can't be copyrighted. SMF can steal those ideas, we can't do anything about it -- except to take note that they considered our ideas to be good enough to steal them... We own our implementations of these ideas. But they may not even be the *best* implementations of it. (Although, TBH, I don't think the current SMF developer team is up to the task to make better implementations... :whistle:)

So, yeah, I'm sorry but at this point, I can see a lot of things we're giving back to the SMF community.
If all the SMF team wants is *for us to share our code*, then they should have asked us to become the SMF developer team a year ago. Instead, they showed us the way out, indicating they didn't feel the need for our ideas and work.

It's as simple as that... It would be quite preposterous from the SMF team to expect anything more than what we're currently giving them.Couldn't agree more.

As I just noted elsewhere, not only did they get a helpdesk from me, there is still talk of them taking over SimpleDesk as a project, which would pretty much compel me to become an NPO member, though if they can wait until I release SD 2.0 and make my account vanish, there is no risk of my being drawn into the NPO.

Yep.  It might not be considered friendly, but it is certainly permitted, and someone might try it one of these days.
That's the funny thing about the BSD license. It is not CC-by-SA.

Which was the point I was making. I think we've been more honest about our intentions than someone doing that would be.

And specifically for the record, if we went CC, I suspect it would be BY-SA-NC.

I can *wish* you would use CC-BY-SA-NC, but clearly the choice is yours. I am content to disagree.

Heck, given how we're incompatible with current SMF mods, we could even go GPL just to annoy everyone :lol:

BSD to the "something like the old SMF license" to GPL.  That's something like the SMF/YaBB SE licensing history, in reverse.