Skip to main content ↑ ↓
Some notes on copyright and licensing Started by AngelinaBelle · · Read 38721 times 0 Members and 1 Guest are viewing this topic. previous topic - next topic

Re: Some notes on copyright and licensing

Reply #15 –

Wow. I'm amazed by this, and I thought I had a chip on my shoulder about SM's antics.

So let's pull this apart.

QuoteThis is how none that I know of, of longer established projects work

Um. Apache httpd? (Remember, the original CLA was essentially the Apache CLA) But I believe the devs have more say than how SMF currently does it.

QuoteSM Corporation: SFLC told us we are the editors, because we sit and make decisions on prioritizing code refactoring, while developers do the work.
Judge: ...okay... and where are some contributors?

This is why they are preparing the contributors file which lists this. Like Apache.

QuoteIf you accept that the team/corporation/members can always interfere, not participate, "make decisions on code refactoring" against developers will, "make decisions on the code and what gets accepted into it" (hint: by pulling authority on developers), meaning from all kinds of team processes aside from the development process, and it's even their job to do so, then and only then you have extra-rights granted: you accept that a group (corporation, team) can always interfere with the development process, they're not submitted to the same guidelines. Not work with you on the common work, but impose things on your work.

And the 'project' dies.

This is the real crux of the matter. It isn't - and never really was - about the licensing matter, let's call it what it is. It is about the ability of the team to interfere in developmental issues. Everything else is a mere bagatelle.

You and I are in complete agreement about the fact that the developers should be the ones calling the shots. It's why Wedge and Elk are moving along at the pace they are because there is no oversight, no development by committee, no interference. We can go in and get the job done.

The problem when you get to a project like SMF (and to a lesser degree by the Apache projects), is that the non developers are there to do things that we don't necessarily want to do. They handle the support, the documentation and so on. They essentially free us up to do the stuff we want to do and what we are best equipped to do: the development.

Quote- you're talking about a closed-doors corporation of non-contributors, a corporation that is not capable to handle such double-edged rights.

Oh, I'm well aware that SM NPO is not fit to hold such rights. I wouldn't lay the same claim over any other organisation, however.

Quote- what is said here is actually a copyright claim over something. There has to be something real, to be an extra-copyright claim, something that cannot be achieved under the development process. And Angel said it: someone has to "make decisions" over development, against their will, from outside the development process and its guidelines. Equals someone to control development.
It's over that bit SM claims copyright, and viceversa: to achieve that, SM management kept claiming copyright.

And they're welcome to it. They do have a sort of need to retain some rights to the assembled work, assuming you don't fancy being the recipient of a lawsuit in the event of one being launched. (If there's no oversight body, anyone starting a lawsuit can and will pursue individuals.)

Plus it is their job to distribute packages of SMF as a whole, and their infrastructure for doing so. They would potentially require rights to do that safely.

I get where you're going, I understand your objections. I'm not convinced, though, that it is as big a deal as implied here.

What is for certain is that the project in its current form is doomed. They still cannot admit there is any kind of a problem pushing people out of the project, and a lot of it stems from the above, but the copyright line is mostly a side issue in reality at least from my perspective.

Re: Some notes on copyright and licensing

Reply #16 –

Quote from: Arantor –
QuoteThis is how none that I know of, of longer established projects work

Um. Apache httpd? (Remember, the original CLA was essentially the Apache CLA) But I believe the devs have more say than how SMF currently does it.

Pay attention to the so-called "comparison" with Apache: developers and contributors have built it, and they set the community-open processes of Apache. The project is free to have its supporters (i.e. most of SMF team) from anywhere and take place anywhere.

Lets see.
http://httpd.apache.org/contributors/
I see 90% code/documentation contributors.

http://httpd.apache.org/support.html
Support is up to anyone.

http://httpd.apache.org/ABOUT_APACHE.html
QuoteThere is a core group of contributors, formed initially of the project founders, and augmented from time to time by other outstanding contributors. There are 'committers', who are granted access to the source code control repositories to help maintain the project or docs, and the core group now managing the project, which is called the Apache HTTP Project Management Committee (PMC, for short).

Compare with "SMF project equals SMF team" closed-doors team structure. Remember translators. Remember that "outside" contributors are considered "it's not team/it's not 'the project'". (meh. This wasn't my take, nor what developers kept after me withdrawing. Not that it matters any longer.)
SMF team has the wrong structure. (apart from many other issues.)

http://www.apache.org/foundation/how-it-works.html
http://www.apache.org/foundation/how-it-works.html#meritocracy
http://www.apache.org/foundation/how-it-works.html#roles

TL;DR: apples and oranges. :)

Suggestion: if people are so happy to still compare with Apache, why don't you move the project to Apache? After all, it has much more experience in handling an open source project (which IMO, SMF still isn't by a long shot but that's another story), than an ad-hoc Corporation built in broken and confusing circumstances in 2010.
Hint: it will interesting to see how they react when you bring something you hold trademarks to, you call "project", but it has no core contributors.
Hint #2: not for the first time...

Quote
Quote- what is said here is actually a copyright claim over something. There has to be something real, to be an extra-copyright claim, something that cannot be achieved under the development process. And Angel said it: someone has to "make decisions" over development, against their will, from outside the development process and its guidelines. Equals someone to control development.
It's over that bit SM claims copyright, and viceversa: to achieve that, SM management kept claiming copyright.

And they're welcome to it. They do have a sort of need to retain some rights to the assembled work, assuming you don't fancy being the recipient of a lawsuit in the event of one being launched. (If there's no oversight body, anyone starting a lawsuit can and will pursue individuals.)

Plus it is their job to distribute packages of SMF as a whole, and their infrastructure for doing so. They would potentially require rights to do that safely.

Red-herring. If Open Source software cannot be distributed without giving some sort of copyright APART from the license, then 99% of the Open Source projects out there, which everyone is using, are doomed and "illegal".

An Open Source lawyer at RedHat will answer this much better than I can:
https://lists.launchpad.net/openstack/msg06544.html
QuoteMoreover, anyone who thinks that open source is unsafe or unreliable
without a system of explicit acceptance by the licensor of inbound
contributions should immediately cease using it altogether, since 99%
or so of it was produced without any such system in place. Any
suggestion otherwise is dismissable, but I think it does some damage
to suggest that there's something unsafe about using an
alternate-universe version of OpenStack where the project did not make
use of a CLA, as it unnecessarily casts doubt on that 99 or so % of
open source software that is developed without such cumbersome
mechanisms, and indeed it casts doubt on the reliability of open
source licensing itself. Thus, by using an Apache-style CLA, OpenStack
is shooting itself in the foot.

And, I have added to SMF (and Elk) linux-kernel-style DCOs anyway. That is a "system" which guarantees the rights of the license already.

The rights granted by an FOSS license are enough to "distribute safely".

And: if it's not safe to distribute, for SM, why is Wedge, or redistribution of SMF, safe to distribute? ;)

SM does NOT need more rights than anyone else. And it is not capable to handle them - which is probably more important, even.

Quote from: Arantor – the copyright line is mostly a side issue in reality at least from my perspective.
Of course.
ETA: well, from my perspective it is: first, the cancer of this project is exactly what the copyright issue means; second, if you will, take it as illustration.
Last Edit: February 18, 2013, 07:24:16 pm by TestMonkey
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Some notes on copyright and licensing

Reply #17 –

QuoteThey do have a sort of need to retain some rights to the assembled work, assuming you don't fancy being the recipient of a lawsuit in the event of one being launched. (If there's no oversight body, anyone starting a lawsuit can and will pursue individuals.)

Point #1:
Actually, I do. I have no problem standing up to the claimed "copyright" of SM. (which is not the poor notice, but we can use it metaphorically, if I may say so.)

As lead developer of SMF, I have been pretty much the only one changing and overseeing any licensing/copyright/notices issues.
As the lead developer actually doing the relicensing of SMF 2.0, and several additional code, and NOT other code, I have done a lot of work to know what is involved and what are the contributors stances on everything.
[insert here description of thousands of revisions diffs, copyright law on software, emails, hundreds of posts, FOSS practices etc]

I know SM Corporation has no "copyright" standing. And I know it does not deserve it. The switch LLC->NPO has failed. That's just how it is.
And it does not matter if you just let it write a notice.

Point #2:
Quote from: link aboveWhere are all these lawsuits brought by contributors to open source projects?
Replace freely with "to". What lawsuits "threaten" me so badly, because I wrote code under an Open License?
(funnily enough, I have an answer to this!)

Ignore this if you don't care anymore about the relation of the actual copyright claim with the entitlement and assumed 'authority' over development. This is just a number of further explanations on it. (probably not well written.)
Point #3:
Arantor,
I am saying that your opinion of where could the 'extra-copyright' come from is not what AB says that she got from SFLC. Pay attention to her statement: someone has to "edit" the work with authority, authority from outside the development process. To have a 'copyright' apart from BSD 3-clause under DCO.

I am saying that the "oversight body" can and does only "work" for an actual copyright claim to *something*, if it has authority over developers, on their own work: the code itself. No other details. On features developers work on, on roadmaps, on code refactoring, on the pull requests being accepted into the code (!), on when to commit a feature and when not, you name it.
Some rules and regulations developers "must" obey, coming from "the authority".

I am saying that developers did not have those. But only if you do, there's an extra-"copyright".
There have been more than far too many pushes from a "project management", dramas, internal stuff, for authority over what developers do to exist. They have slowed us down, they have forced me to waste time and compromise, yes; and pulled down almost all developers and other-badges contributors, from 2010 to 2012. But the code/releases/whatever we managed to, is what we wanted it to be; all you have to do is convince us; aside from (de)motivation issues. Until November/December 2012, anyway.
When events related more-or-less to "the copyright issue" have made developers take another name.

Anything that has entered the code has been as developers want it to be. With the open process, in most cases, an open process we have worked hard to make it reality, and welcome anyone to.
Developers are gatekeepers of the code, and while everyone is welcome to provide input and feedback, no one can interfere.

Open to everyone to contribute, and offer input/feedback. And up to no one to impose.

But. Look what AB told SFLC "this is how the project functions", and this is the "extra"-bit on which they must have told her "ok, then there is a copyright claim on the code, which is most useful expressed by SM and etc".
(I am waiting for answers from both AB and SFLC, but no hurry, we can infer in the meantime :).)

(of course, SM management forgot to tell them that it doesn't function at all, and it dies right now, before the eyes of those too busy to grab authority and control over development in an Open Source project.)

I hadn't known what SM management was doing, but I knew:
# that there is no way in hell to have any "copyright claim". Under DCOs and even CLAs, there isn't any. End of. (yes, I am too preoccupied about the real issues here, than to address properly all your statements; will review.)
# that certain people will try, will try to get from copyright, the right to control releases/development, for the corporation members, aka team, against developers will.
(which is one of the many reasons why I had removed CLAs.)

What I didn't expect (really), is this turn of events: when AB innocently told SFLC that it's an absolute and simple "reality". (I completely understand her, though, and I really apologize for the initial words I used.) That the SMF team sits and "makes decisions over code refactoring" while developers "just code" what their management said. That's why SFLC admitted, it seems (?), that the corporation members "edit/derive the work" (=extra-copyright on the code) by "making decisions" on what developers do.
It's a master-coup, admittedly.

SM or SMF team do not have the expertise, usually for such task. There are a few exceptions of course, in the team, but much more *out there*, again: I have left at SMF a development process which was becoming *open to everyone*, to the community, I kept pushing discussions towards less private/semi-private boards, and finally github/blogs - and of course there were much more steps to make with the community. When the process has been cut off from the inside.

And if they did, they should/would be covered already by the term "contributors".
Last Edit: February 18, 2013, 11:06:10 pm by TestMonkey
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Some notes on copyright and licensing

Reply #18 –

I intend to add up several simple facts of relevance (of a lot of relevance... unfortunately I seem to need some time). As well as a couple of explanations, and as desired, to address point by point a few misconceptions.
I will not start (I think) different topics here on Elk, so this topic will have to address different things (though all related), one at a time.

Please feel free to see also a couple comments to the current proposal for the poor notice, the "legal counseling", "corporations", and "individuals", meaning corporations and developers:
https://github.com/AngelinaBelle/SMF2.1/commit/4b1b59c5ffbb1456a04314ac1ed28bb5936939f4
Please note: (just saw it; answering quickly here. The pieces of the puzzle are many, Arantor and AB.)

QuoteThe entity Simple Machines was set up with the purpose merely to support the individual members in the SMF community
I don't disagree that this is what it should have been. In case you didn't know, I have worked to set it up myself, along with the first BoD, SMF Friends, SMF founders included, and SMF founders excluded.

It has proven, unfortunately, completely incapable of doing so: support. Not manage, not control, not "own", not block (!).

Quoteand most especially SMF team (who have historically contributed nearly 100% of the SMF code)

Note the "most especially". Inequality.

Quoteand most especially SMF team (who have historically contributed nearly 100% of the SMF code)

"The team" contributed nearly 100% of the code?

You've got to be joking. Lets see...

Quick Summary:
January 2010:
- SMF Developers and some SMF Friends (developers who had left, mostly), had contributed 97% of the SMF code, contributors of other-badges, the rest.
- SMF team supported development, by their work on other aspects around the core software;

May 2010:
- SMF Friends had contributed 97% of the SMF code, contributors of other-badges, the rest; including SMF Developer-badge.
- SMF team supported development, by their work around the project; trying to find a way to organize itself, and failing for a long time. Today included.
- NPO started to take over from the LLC.

November 2012:
- some SMF Developers and some SMF Friends contributed 95% of the code and 2-3 SMF team members and a few no-badges members the rest.
- some of SMF team were supporting development by their work on other aspects around the project; some of SMF team were blocking development.

February 2012
- one remaining SMF Developer, many SMF Friends, contributed 95% of the code, several diverse-badges the rest.
- the SMF team supports other aspects, not development; not even by testing.


Same summary with a few comments:
January 2010:
- SMF Developers and some SMF Friends (developers who had left, mostly), had contributed 97% of the SMF code, contributors of other-badges, the rest.
- SMF team supported development, by their work on other aspects around the core software; but it couldn't do so properly, because of many issues, amongst which project management held by a (controversial) project manager.
- SMF translators, beta testers, etc, supported development, by their work; some of them did not have access to repositories, roadmaps, until later.
- there were other issues.
Amongst which, the proprietary cancer of this project. The proprietary license, setting up the culture of control, and centralization. Which is central in my perspective: the proprietary license, the Constitution of a culture of control in a broken "project" and a kept-unaware-by-design community. And to which I will come back on.

May 2010:
- SMF Friends had contributed 97% of the SMF code, contributors of other-badges, the rest; including SMF Developer-badge.
- SMF team supported development, by their work around the project; trying to find a way to organize itself, and failing for a long time. Today included.
- NPO started to take over from the LLC.

I know. In case you weren't aware, I had decided to take full responsibility for that project, in 2010, for the NPO vs LLC to succeed.
And subsequently working with everything: SM, legal issues, copyright and relicensing, software, 2.0 stable, roadmaps, development process, team issues, opening the project, open licensing information, etc. You name or not name it: I had to keep an eye on many things.

I have failed to fulfill it. Under that name and corporation and team 'organization', subjective reasons included.
And no one else took responsibility for everything. Nor do I think anyone in particular - any single person - can possibly make a difference, under the current structures/circumstances. (and that's not even "wrong").

The NPO has failed the role it was meant to fulfill. It was never meant to be a corporation, to begin with. But a support organization.
It was meant to free resources, for people to do the work. Not to block releases, sites, tools. Amongst many others.
It was meant to be an open support organization. Not something superposed on the team, with an uncountable array of private-by-design boards, partially visible-partially not, to developers and team, and not at all to anyone else.
(you can be in 'the team' and not 'corporation', and viceversa, and both are private-by-design "since you left"; or even, are not in the 'right' subgroup - not that anyone knows anymore which/what was where.)

November 2012:
- some SMF Developers and some SMF Friends contributed 95% of the code and 2-3 SMF team members and a few no-badges members the rest.
- some of SMF team were supporting development by their work on other aspects around the project; some of SMF team were blocking development.
- some SM corporate members were blocking development in an essential way: by blocking developers access to resources.
- a few SM corporate members decided on their own to do everything they can to "claim copyright" over the code.
Thereby institutionalizing authority over the software of closed-groups who don't do the work, over those who do.

February 2012
- one remaining SMF Developer, many SMF Friends, contributed 95% of the code, several diverse-badges the rest.
- the SMF team supports other aspects, not development; not even by testing.

I think the issues around "SM Corporation" and "SMF Team" are insoluble. There is nothing to "just reform a bit", IMO.

I will inform you - and everyone else - of more (everyone needs to know critical facts), but to be honest, I think the issues of "SMF" under this name are insoluble... And when developers know that, and I mean really, really, know it, there is probably no option... and it only up to the community to do something, whatever that may be.

Quote Simple Machines owns trademarks, for example.
I am well aware of it. In case you didn't know, I have worked to make it possible.
But SM Corporation has gone the wrong way: it is not a support organization, not a non-profit for the public benefit. It has become a corporation, working in the interests of some of its members.
It has said so itself.

QuoteAs far as I can tell, the current members of Simple Machines accept the role of Simple Machines as editor and as one of the copyright holders of the joint work.
The "current members" accept their own role as "editor" (=authority over the software) and thereby "one of the copyright holders of the joint work".

Self-serving argument.
I will withhold some snarky comments on the circularity of the argument.
Last Edit: February 19, 2013, 05:34:05 pm by TestMonkey
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Some notes on copyright and licensing

Reply #19 –

Are we there yet?

I have no objection to the discussion of legal facts, but personally I would greatly appreciate it if comments about people and their actions and their possible motivations were left out of the discussion. If this is just going to descend into SMF boards Mk 2, a sensible person might be wondering why we left there. ;)
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Some notes on copyright and licensing

Reply #20 –

Oh, Ant, I firmly understand your reluctance to indulge in this. The fact is this does affect Elk, it affects Wedge and it affects SMF. Understanding how our respective projects hold copyright is very important - us developers have to stick together and fiercely protect our work, because it is part of us in some small way.

QuotePay attention to the so-called "comparison" with Apache: developers and contributors have built it, and they set the community-open processes of Apache. The project is free to have its supporters (i.e. most of SMF team) from anywhere and take place anywhere.

Hey, don't get snarky with me! I'm actually on your side more than you might think. It is a comparison because the CLA and the project as a whole were modelled after Apache, thus it makes the most sense to compare to.

I'm specifically comparing with Apache httpd here, which is a project under the ASF much in the vein that SMF is a project under SM NPO. They have their list of contributors, but the project as a whole is listed as copyrighted to ASF. The two are separate entities, just as OpenOffice is a separate project under the ASF as compared to httpd.

QuoteCompare with "SMF project equals SMF team" closed-doors team structure. Remember translators. Remember that "outside" contributors are considered "it's not team/it's not 'the project'". (meh. This wasn't my take, nor what developers kept after me withdrawing. Not that it matters any longer.)
SMF team has the wrong structure. (apart from many other issues.)

Structurally, SM aspires to run the way ASF does. Actually the structure is surprisingly similar, with the side effect that there are more people in the wrong branch, too many people in the committers area, as such, without having earned it.

I don't really see that ASF runs substantially differently in intent - but there is a significantly higher signal:noise ratio in their contributors. They admit they are a meritocracy, this is perhaps something SMF needs to adopt. Everyone else already did.

QuoteSuggestion: if people are so happy to still compare with Apache, why don't you move the project to Apache? After all, it has much more experience in handling an open source project (which IMO, SMF still isn't by a long shot but that's another story), than an ad-hoc Corporation built in broken and confusing circumstances in 2010.

Because it's not like that and you know it. Apache doesn't just accept projects. They go through a process - which is fairly closed as I understand it (though I daresay you'll prove me wrong, hah) - wherein it is voted on by their PMC, which is rather analogous to SM's BoD, with the fact that they're much more active. Notice the wording: The PMC as a whole is the entity that controls the project, nobody else.

The comparison seems rather fair to me.

Re: Some notes on copyright and licensing

Reply #21 –

QuoteRed-herring. If Open Source software cannot be distributed without giving some sort of copyright APART from the license, then 99% of the Open Source projects out there, which everyone is using, are doomed and "illegal".

I call red herring. Especially your bit about CLAs, but I'll get to that in a moment.

Let's start with what copyright is. It is a legal mechanism, defined and enshrined in law, to protect the work from inappropriate distribution. At least in the US, and since that's SMF's jurisdiction, we'll run with that. For the purposes of this the specific matters of the Berne Convention are not entirely relevant, it is sufficient at this stage to work on the basis that creators hold copyright in their works, backed by law.

What, then, is a licence? A licence is a document that does not override copyright law. It is an agreement that you may use/consume the copyrighted work which is distributed in a manner that is not consistent with copyright law, but that provided licence is complied with, no action will be taken. This does not excuse inappropriate actions, nor does it provide any sort of legal defence; if the licence is not complied with, copyright violations can indeed be taken to court.

Now, I said this:

QuoteAnd they're welcome to it. They do have a sort of need to retain some rights to the assembled work, assuming you don't fancy being the recipient of a lawsuit in the event of one being launched. (If there's no oversight body, anyone starting a lawsuit can and will pursue individuals.)

Copyright law is there to protect the creator and distributor. The lawsuit protection is the more practical aspect, certainly, but it works the other way too. Supposing someone ripped off your work and distributed it in a manner inconsistent with the licence. This is now a breach of copyright.

The problem is, if you turn up in court and say 'I hold copyright on the bits of this I wrote which are being infringed', unless it's a substantial part of the work, it's not really going to stand up. Even if the collective group of you, i.e. all the copyright holders, were to stand up together, it would be an interesting case to watch.

On the other hand, if there is a single body that can legitimately claim some kind of copyright on the total work, then yes, there is a much stronger chance of defending the work in court - both ways.

Though I can see your argument about not doing so - after all, it's not like there have been substantial matters along these lines in the past. The only real issue was ttForum, back in the YABBSE days, thinking about it. Ironically it is that unauthorised fork of YABBSE that prompted the closed licence in the first place. YABBSE was happily GPL until someone forked it, replaced all the copyright notices with their own name and shipped it. Funny old world.

Re: Some notes on copyright and licensing

Reply #22 –

Now, the CLA matter more specifically. That's an interesting take on it, certainly. So is your careful quoting to preserve your intent and subtly take the focus away from the rest of the rant.

The comment at the end about 'where are the lawsuits' is a valid one. But it is not unheard of. Little cases like Oracle vs Google over the Java headers can run into issues like this down the road.

Most of the reason for SMF taking on board a CLA is not really about protecting SMF going forward, however. It never was. It was about protecting the move to BSD from issues that might crop up in relicensing the code in the first place. That successful, there's no reason why they had to continue using the CLA - and last year they stopped it. I don't know how involved you were in that move to the DCO, though.

Note that the CLA argument is actually a red herring in itself. The CLA was a means to an end. It has served its purpose and run its course and they are no longer using them.

What does that mean for SMF and for us as sublicensees? That's the only question that really matters at this point in time.

SMF contributors hold their copyrights to their contributions. Even the Apache CLA hasn't changed that. Even if you signed both, it didn't change that fact. We still own our contributions and we granted them the right to use them in perpetuity. That isn't granting of ownership, it is granting the right to use it without ability of ours to withdraw it. You can call it granting of ownership if you like, but in the eyes of the law it isn't.

The problem in your argument comes with the fact that during 2.0's assembly you were presiding over it as an editor, yes? Acting in an official capacity to contribute but also to edit the work? Does that not on some level give SM the right to claim editorship? You were after all a team member at the time.

Anyone acting with a team badge, i.e. in a team capacity, to edit the project's code, to accept or refuse contributors is implicitly an editor. I don't see how that's arguable in any practical sense. Especially since the DCO came into force. Anyone accepting contributions is directly forming an editorial action, regardless of who contributed it.

Re: Some notes on copyright and licensing

Reply #23 –

QuoteThe rights granted by an FOSS license are enough to "distribute safely".

Correct. That's the point of the licence. The CLA was the vehicle to get SMF onto the correct licence. The claiming of editorial copyright is intended to protect distribution in line with the licence so that licence violations can be dealt with.

QuoteAs lead developer of SMF, I have been pretty much the only one changing and overseeing any licensing/copyright/notices issues.
As the lead developer actually doing the relicensing of SMF 2.0, and several additional code, and NOT other code, I have done a lot of work to know what is involved and what are the contributors stances on everything.
[insert here description of thousands of revisions diffs, copyright law on software, emails, hundreds of posts, FOSS practices etc]

And all of that is behind closed doors, funny huh.

I have no idea who the final list of people who signed a CLA was. However I was watching the SVN very carefully from RC3 onwards (July 2010) and I saw no major rewrites, indicating that some components may have dubious licence status without a CLA and with a licence change. Most of this is dancing around the real issues, though.

QuoteAnd: if it's not safe to distribute, for SM, why is Wedge, or redistribution of SMF, safe to distribute?

I never said it wasn't safe to distribute - provided the licence is complied with. Wedge's status is a little more dubious, however, and it is not my intention to dredge that up here.

QuoteETA: well, from my perspective it is: first, the cancer of this project is exactly what the copyright issue means; second, if you will, take it as illustration.

I disagree. I understand the basis under which the team claims some stance on copyright. I understand your very strong concerns with that basis. I want to agree with your stance however what is morally more accurate is not necessarily where the intent or the letter of the law stands. I do not believe you are correct in your assertions as to SMF's copyright status, but that would only ever be an issue in the event of a legal challenge. It is, like all other cases, essentially in limbo until it is tested in a court of law.

The largest problems they have are not related to copyright or ownership but basic project management failings and structures and issues in the way conduct between members even occurs. There is a fundamental lack of respect amongst 'more senior' team members for 'less senior' team members. There is a fundamental misunderstanding with respect to skill sets, skills gaps and the like. But I do not see that any of these stem from what amounts to an ownership complex.

If ownership were fundamentally proven beyond any doubt (e.g. court ruling) that SM held no legal ownership of SMF, it would not change anything. The move to the NPO did not fix anything, nor did the ousting of any demonised figure in the intervening time (Amacythe, yourself, myself on a much lesser degree; not all ousting has to be blatant, nor does it have to be active, much as we have protection against constructive dismissal as a matter of employment law)

QuotePay attention to her statement: someone has to "edit" the work with authority, authority from outside the development process. To have a 'copyright' apart from BSD 3-clause under DCO.

Where has it been stated that such authority must come from outside the development process? Anyone acting under the authority of the team to approve incoming works - i.e. via pull requests - is not implicitly contributing to the project, they are acting as editors. Even if they are contributing themselves, they are still acting in an editorial fashion under the team banner.

QuoteDevelopers are gatekeepers of the code, and while everyone is welcome to provide input and feedback, no one can interfere.

Of course. I understand this as much as the next developer. It is not me you have to convince on this score. I contribute because I want to, not because I am asked to, or coerced in some fashion to do so.

QuoteSM or SMF team do not have the expertise, usually for such task. There are a few exceptions of course, in the team, but much more *out there*, again: I have left at SMF a development process which was becoming *open to everyone*, to the community, I kept pushing discussions towards less private/semi-private boards, and finally github/blogs - and of course there were much more steps to make with the community. When the process has been cut off from the inside.

Correct. But those who are present in the 'team' who have such skills have the developer badge and commit and oversee the repository with editorial status by definition.

Sadly your vision has not really materialised, something I have been vocal about recently. Yes, the repository is open. Is it open to submission? The answer would seem to be not really. Is it open in terms of setting out plans or a roadmap? Again, not really.

I understand for example that they are close to reaching 'beta' and declaring a feature freeze but again no word on this. It is as if they are open in name only. I am not satisfied by this. I should note, I am not holding Wedge up as a paragon of virtue - it isn't. Our repository is mostly closed, through our choice. However our day to day changelog is public, as is regular discussion of what we are doing and we try to include the community where feasible. By any measure I would claim Wedge is more open than SMF, which given that we are closed as such is a poor state of affairs.

But this is a failing on their part to understand what open development (as opposed to open source) means.

QuoteI don't disagree that this is what it should have been. In case you didn't know, I have worked to set it up myself, along with the first BoD, SMF Friends, SMF founders included, and SMF founders excluded.

It has proven, unfortunately, completely incapable of doing so: support. Not manage, not control, not "own", not block (!).

Correct. The organisation exists to support the project and the project exists to serve the demands - by definition. Support != manage, != own. I would note, though, that defending the project in matters of copyright law (be it offensively or defensively) is a matter the organisation should bear. To me it seems as though the holding of copyright is at worst a necessary evil for that to happen.

Quote"The team" contributed nearly 100% of the code?

I think that is a valid statement given the lack of qualification. I would presume - and hope I am not incorrect - that the assertion is 'nearly 100% of the contributed code was contributed by people under the team banner at the time it was contributed'.

Quote- SMF Developers and some SMF Friends (developers who had left, mostly), had contributed 97% of the SMF code, contributors of other-badges, the rest.

Is it not a fair assessment to call that almost 100% of the code by team members? Just because they are not team members currently does not change the fact they were at one time team members.

Quote- one remaining SMF Developer, many SMF Friends, contributed 95% of the code, several diverse-badges the rest.

You mean team members? They're badge holders. Unless you're counting Charter Members or Beta Testers in that. Anyone else was acting on team authority as a team member.

QuoteAmongst which, the proprietary cancer of this project. The proprietary license, setting up the culture of control, and centralization. Which is central in my perspective: the proprietary license, the Constitution of a culture of control in a broken "project" and a kept-unaware-by-design community. And to which I will come back on.

I get the impression you weren't aware of why that licence came into being. The team felt absolutely justified by taking a closed licence, though I find it amusing that they call it open, and they have the temerity to then criticise me for not having an open licence on Wedge at the present time. Even though Wedge's current licence is almost word for word SMF 1.x's licence at this time.

Re: Some notes on copyright and licensing

Reply #24 –

QuoteI have failed to fulfill it. Under that name and corporation and team 'organization', subjective reasons included.
And no one else took responsibility for everything. Nor do I think anyone in particular - any single person - can possibly make a difference, under the current structures/circumstances. (and that's not even "wrong").

You failed to fulfil an almost impossible task, virtually unaided. I wouldn't be so hard on you.

The lack of responsibility is endemic to the organisation and has been for years. I do not know if you remember my activity in the team in late 2009-early 2010 and that I was prepared to take responsibility for things and was subsequently castigated for it.

QuoteI think the issues around "SM Corporation" and "SMF Team" are insoluble. There is nothing to "just reform a bit", IMO.

I will inform you - and everyone else - of more (everyone needs to know critical facts), but to be honest, I think the issues of "SMF" under this name are insoluble... And when developers know that, and I mean really, really, know it, there is probably no option... and it only up to the community to do something, whatever that may be.

I do not disagree with you. I'm willing to believe it is solvable but not under the current situation.

Little story for you, which is directly relevant. In July 2010, Nao and I discussed going our own way, and originally I wasn't going to fork SMF. I even started on my own codebase. But he convinced me that the issues were not endemic in SMF, but SM. Remove SM from the equation and we have a usable system. And so it was he persuaded me to fork SMF. I have regretted the decision in some respects, for it has caused great drama (mostly by my calling out certain hypocrisies I have observed!) but on a purely technical basis, it was a great decision.

I think it is interesting to note the progress Wedge and Elk have made in their respective developmental periods as opposed to comparable progress with all those people supporting the project.

QuoteI am well aware of it. In case you didn't know, I have worked to make it possible.

SM LLC held those for at least a year, if not longer, before either of us took a badge. I do not know exactly when they were granted but there is mention of them being held in 2008.

QuoteBut SM Corporation has gone the wrong way: it is not a support organization, not a non-profit for the public benefit. It has become a corporation, working in the interests of some of its members.
It has said so itself.

Yes. I have no objection to this statement.

QuoteThe "current members" accept their own role as "editor" (=authority over the software) and thereby "one of the copyright holders of the joint work".

I disagree with you on the exact nature of the editorial standpoint, I believe that a developer acting in the manner of the team would implicitly grant the team some editorial role by definition. But that is really the only place you and I disagree in interpretation.

We both agree things are very messed up - if they were not, neither Wedge nor Elk would have begun, would they?

What I will say in closing is that I am no lawyer. I don't even play one on TV. But with my skills, enhanced by Phoenix Wright (OBJECTION!), I contend that you may be incorrect on one or more points. Whether SM does or does not actually own copyright is almost irrelevant though - the project is still doomed one way or the other because even if it doesn't actually own copyright, it acts as if it does including holding too much say in the developmental process. And even now the team's most active mouthpiece claims that developers were never told 'how to code'. Correct. But control, as I have been trying patiently to explain, is not merely about how to do something. It is about what to do and what not to do.

You and I as seasoned developers understand these things. We understand what has to be done and we will do them, as we see fit. And until that is realised, SMF has no future.


(apologies for the long post-split but I wanted to catch all the points I saw as relevant!)

Re: Some notes on copyright and licensing

Reply #25 –

Quote from: Arantor –
QuoteThe "current members" accept their own role as "editor" (=authority over the software) and thereby "one of the copyright holders of the joint work".
I disagree with you on the exact nature of the editorial standpoint, I believe that a developer acting in the manner of the team would implicitly grant the team some editorial role by definition. But that is really the only place you and I disagree in interpretation.

I understand. But there is no copyright granted on a work of authorship by merely your presence in a "team", "corporation", or a "workgroup" while you work on it. There's no legal standing for the corporation/team.

And the (main) problem is, that's not what they're saying.

QuoteFor SMF, the SFLC lawyers told me "Simple Machines and Simple Machines contributors" is the most descriptive and most useful.
That is because I told them that the SMF team does function as an editor of the joint work.  That is my observation of how team members set priorities for features, refactoring, and make decisions on which contributions are going to be accepted into the code. EVERYONE holds copyright -- contributors and editor, and it is useful to add that into the current copyright statement in the SMF code.
They're saying,
the team members "make decisions on which contributions are going to be accepted into the code".
They're "the decision makers", and developers, just do the work.
They're saying,
the team members "make decisions on prioritizing code refactoring".
They're "the decision makers", and developers, just do what they "decide".
They're saying,
the team members "make decisions on the features to want, to accept or to reject" in the codebase.
They're saying they're "the decision makers", and developers, their coders.
Coders for the corporation members will.
Coders to "just code" what the corporation members, aka team, "make decisions" on.

Meaning, their management.

Their so-called "copyright claim" is this:
QuoteEVERYONE holds copyright - the contributors and editor

That the corporation/team members sit and "make decisions" on what they allow their "coders" to do. This is their closed-team enforced "edition" of the software that would get, from now on, released under SMF name - assuming anything ever will.
This, and only this, is their so-called share of "copyright claim".

The corporation does not participate, it interferes with developers by design. Corporations always do that in the end. They always kill open source projects.

In reality, they only have a license. And their help to the project is credit, given on the credit page.
Not copyright.

They're telling you they "protect copyright", but what they're really saying is they have no actual copyright being transfered to them by any of the licenses (and a mere notice means nothing), nor by any abstraction of 'developers with a team badge'.
 
Their copyright meaningless claim is: their "decisions" on the code, from outside the open development process.
The corporation has just given themselves the right to do just that.


I don't know what some people were thinking... In all this time, when they kept pulling developers down... then they went to get their "blessing". For being a corporation, who will extend a notice on copyright... and they do that, because they wanted the right to "make decisions on features, code refactoring, contributions"... against anyone, against those who do the work, those they didn't bother to ask. Against developers' will, against contributors, against community.
Last Edit: March 01, 2013, 08:39:12 pm by Norv
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Some notes on copyright and licensing

Reply #26 –

QuoteThat the corporation/team members sit and "make decisions" on what they allow their "coders" to do. This is their closed-team enforced "edition" of the software that would get, from now on, released under SMF name - assuming anything ever will.

Thank you Norv, you made my day  :)

Exactly what I felt while beeing a SMF team member and the main reason why I've ignored all forms of contact from team members after I left (I've ignored your PMs as well, you may remember, but it wasn't directed against you, I've simply ignored them because you had a team badge at that time).

How volunteer projects work, IMO:
- Wedge is a closed projekt, and it works well, because it has two very competent and strong leaders, who lead the project as well as the codebase.
- Elkarte is a completely open project, and it seems to work well, too.  Everyone can contribute, make suggestions / contributions and it is beeing discussed between the code contributors (and community).
- SMF wants to be open, but IMO it is far away from open. While beeing on the team I had always the feeling, everyone (team and friends) wanted to be involved in any decision, I left a long time ago but from what I read it is still the same..

The SMF company needs to learn this: The coding guys (and girls, of course  ;) ) are the ones who build the base. Without this base the entire project is needless. Don't scare the contributors away or the project will die, sooner or later..
Thorsten "TE" Eurich
------------------------

Re: Some notes on copyright and licensing

Reply #27 –

I gotta admit, while you and I might quibble over some of the finer points of interpretation, the fundamentals we agree on: unwelcome interference in development. And they refuse to accept any of this as a problem.

Related, more than one team member has said to me that they see developers as 'no more important to the project' than other roles, e.g. support.

Quote- Wedge is a closed projekt, and it works well, because it has two very competent and strong leaders, who lead the project as well as the codebase.

Thank you :) What I would say is that while yes, we are closed, we are not closed from suggestions and contributions as such, though we have been extremely wary of accepting contributions of code based on history. But we do try and involve people in what we're doing as best we are able.

Quote- Elkarte is a completely open project, and it seems to work well, too.  Everyone can contribute, make suggestions / contributions and it is beeing discussed between the code contributors (and community).

Yup. The atmosphere here is fantastic; I feel like I can make a suggestion and it be listened to - even when it isn't implemented. The simple act of being listened to makes a huge difference.

Quote- SMF wants to be open, but IMO it is far away from open. While beeing on the team I had always the feeling, everyone (team and friends) wanted to be involved in any decision, I left a long time ago but from what I read it is still the same..

I don't know if they understand the meaning of openness. What I do know is that the team as a whole seems consider itself to be better than the community, and that their opinion is correspondingly more important.

Re: Some notes on copyright and licensing

Reply #28 –

Just adding here, for your information, and for who wants to keep themselves informed, at least in the measure I, personally, may be able to bring issues in the open, as I should do, or should have done.

https://github.com/AngelinaBelle/SMF2.1/commit/4b1b59c5ffbb1456a04314ac1ed28bb5936939f4#commitcomment-2726368

Please accept my apologies for writing a bit on the run.
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Some notes on copyright and licensing

Reply #29 –

It has come to my attention that SFLC has sent these days, to the SM Corporation, an advice.
Along these lines - I can't be sure entirely, again, closed-corporate-processes-by-design prevent me to. But along these lines:
--
That it's not sensible of them to keep claiming "editorial authority" for the Corporation. (aka copyright).
And that perhaps they should reconsider their insistence on "Simple Machines" in the copyright line.

Because there is actually no real "legal OMG legal matter!!" here.
Since not all contributors agree with the role of the corporation as "authority"/"editor", over the software, then they should just stop their claims. Since they only alienate the community. Over no real "legal issue".
--

Result: the same people - the select few of the corporate management - disagreed with it.
The same corporate management disagree with their own legal counsel.
The same corporate management disagree with their own legal counsel, right now. When in the same time they keep throwing "legal-legal-legal" scarecrows at you, at me, at the community.


And if that's not enough. It appears that the SM corporate management hid again the follow-up discussion, from their own members, and from everyone else. From developers, contributors, team, friends, community. They call all these the "3rd parties"... you see. They're treated as a "3rd party" on their own work. The interests of a very closed group of non-contributors are more important than you, your work, your time, your code.
Are more important than everyone else.
The best moment for testing your PR is right after you merge it. Can't miss with that one.