Wedge

Not a 'very large' header - it's not exactly much bigger than the current one but we do it once and don't even have to change it every year.

I'd prefer to take the Apache route, actually, because it means we don't have to update files every year or anything, and we can explain the rules much better in a single place.

iPad snap!

Re silly, you did say the argument about Apache ownership was a silly one but I would draw your attention to http://www.apache.org/legal/src-headers.html and particularly "why it was necessary"

I would disagree actually... Almost everyone who has been dev team the last few years started in the Support team. Even Norv.

Here's the thing, Kindred, here's the thing... you're not one of the people being asked to do something. You're one of the people asking someone else to do it.How well that's working out for you is showing so well.You know as well as I do that it won't be like that, because the devs are effectively getting the shaft. You're not a dev, you're a manager.Yes, it is. But the dev team needs to be left alone to do that, and if anything over the last few years has shown, that ain't happening.You mean the same team that's supposed to test patches before deployment but continually fails to actually do so? Pretty much every patch since 1.1.10 / 2.0 RC1.2 went out badly with flaws in the package requiring a soft of hidden recall.Yeah, whatever.And successive generations, spanning years' worth of contributors must all have got it wrong and must all be smoking the same joint? Pull the other one, please. Why it is that it's the *same complaints* time after time after time after time? Every couple of years it's supposed to have 'all changed' but it clearly hasn't.Oh, yes, I was wondering when we'd get to this. The fact that Norv made the change without authorisation suggests a fundamental inability to manage people and permissions, but we'll let that slide for the moment.

The real substance of that change was most interesting, notwithstanding the fact it was one of the main reasons why a number of your developers upped and left and forked your software.

The change that's being referred to, for those playing along at home, is over the copyright notice in the SMF files itself, which until the change referred to Simple Machines. As in the entire package's copyright is owned by SM NPO. This is interesting because the code I gave SMF, I certainly didn't allow SMF to claim copyright on it.I gave SMF a licence to redistribute it, to create derivatives of it, distribute etc. But I did not give the right for it to be claimed under SM copyright, and that is a very important distinction. The code I contributed IS STILL MINE, just as the code Nao contributed is STILL HIS, as are all our posts, all our comments and bug reports. Copyright law establishes that these are ours, and we gave you a licence to distribute/reproduce/derive/sublicence/whatever with them. But not claim ownership of them.

I suppose you could probably make a vague claim based on it being a derivative work, sublicensed back to SM and distributed in that fashion, but it doesn't change the fact that my code is still owned by me and that I'm giving you a licence to use it. IOW, the copyright is of SMF contributors, they are the ones who legally hold the copyright in the code, and they gave SM the licence to create a single package out of it, but they did NOT transfer ownership of it.

By comparison, Wedge's copyright is currently stated as copyright Wedgeward 2010-2013. Thing is, I'm not sure how much original SMF code is really left any more. Derivative work, sure. Sublicensed... well, it was sublicensed to BSD by SMF itself, and we've sublicensed it again. The copyright notice in our files is possibly incorrect at this time, however the reality is that our copyright doesn't cover the original SMF code - we know that, we understand it. Our copyright (and our sublicensing) is born out of the changes we've made to SMF's original code, we're not really claiming ownership of SMF's code, we're claiming ownership of our code that substantively transforms SMF's. I shudder to think how big a diff would be at this stage, but quite possibly it would be larger than SMF's entire code base at this time.[1]

You call it repression, but I'm not sure what happened actually is. I'm not entirely sure that what Norv did was wrong. But the fact that in the aftermath, you lost two developers, very likely a third very soon, leaving you with one of the most incapable people in the role of lead developer.

But if you're happy with that situation, the next saga of driving all the competent people away until you're left with the truly incompetent in positions of authority, I guess there's nothing more to be said.

---

Just one thought for you. In the 2 1/2 years since Wedge formed, you've had a team of how many developers working on SMF? In that time what's happened... now compare the scale of changes in SMF to what's happened in Wedge, when you leave two competent people the run to build it how they see fit, whilst taking into account the needs and desires expressed by the community.

Seems to me that Wedge and Elkarte are going to outlive SMF the way SMF is going and that's really quite sad.

1.	And that chasm is increasing all the time, only this week I've been rewriting the ban system, entirely. It doesn't have the ugly nasty query any more and should scale better.

I prefer to see it as 'We went through all this trouble not to kill the project but it's still dying on its feet anyway', because that's what happened (I was there). Only no-one wants to say it.

How many forks have been started not by general people that want to, but by former product contributors that have been pushed out of the project one way or another? Let's see... Yourasoft, Wedge, ezForum, bloQS/ViennaBBS, Elkarte... the list goes on.

Yes, a positive leaf is one thing, however that's fine if you're going to turn that into positive *action*, and that isn't really happening.

That would be because there are two different front page templates and the one you have is the default.

Huh, I fixed the installer just after we::^ came along, so make sure you're using latest SVN.

OK, time for crazy ass ideas.

The smileys are currently embedded into the main CSS file for the site, as data URLs. It strikes me that we can solve the problem of uploading smileys because of that.

What we could do is store the smileys' actual data in the database, push that to the stylesheet (rebuilding if necessary, don't really know how that would work), and that way we don't have to actually push FTP/SFTP information around and can safely handle everything that way.

What I'd be inclined to do is also set this stuff up when first installing, so everything's there, rather than having data in multiple places. It also means we can streamline this nonsense of 'enable customised smileys' and totally just rely on the DB to do it right the first time.

Thoughts?