Project Support => General ElkArte discussions => Topic started by: AngelinaBelle on February 08, 2013, 02:29:27 pm
Title: Some notes on copyright and licensing
Post by: AngelinaBelle on February 08, 2013, 02:29:27 pm
Hey all,
I wanted to share some legal tidbits that might be interesting to everyone contributing to the Elkarte project. This information comes from the Software Freedom Law Center.
1) The copyright line question -- the answer, for Simple Machines, is that the copyright statement says "Simple Machines and Simple Machines contributors". This acknowledges that the organization has the right to defend against copyright infringement. This is only important to Elkarte if it ever wishes to have the "Elkarte project" sending notices to copyright/license violators, as opposed to having them sent on behalf of the individual contributors.
2) Some small recommended changes to the copyright block and distribution a) Where each file says "license statement at <URL>", it should also be "and in the file license.txt at the top level of this distribution" b) There should also be a mention, at the top of the file, of a contributors.txt c) and, of course, license.txt and contributors.txt files at the top of the distribution.
3) If Elkarte wants to do more to establish copyright, it will register copyright ($35 online) to each major release. Minor releases would be derivative works, and so would be covered by the copyright on the major release. The idea is to AVOID ever going to court, because court is too expensive.
Angelina Belle VP, Simple Machines.
Title: Re: Some notes on copyright and licensing
Post by: Trekkie101 on February 09, 2013, 06:04:45 am
Quote from: AngelinaBelle – 1) The copyright line question -- the answer, for Simple Machines, is that the copyright statement says "Simple Machines and Simple Machines contributors". This acknowledges that the organization has the right to defend against copyright infringement. This is only important to Elkarte if it ever wishes to have the "Elkarte project" sending notices to copyright/license violators, as opposed to having them sent on behalf of the individual contributors.
Is this not what actually just caused WW3 at SM?
Title: Re: Some notes on copyright and licensing
Post by: TestMonkey on February 09, 2013, 07:39:12 am
Sort of. The "kind of told" side of it.
AngelinaBelle, thank you for the heads-up. Could you please make known to us what information have you provided SFLC, when asking for their recommendations? Your email(s) of the exchange, or the relevant part of, for the purpose of this question. You're saying you have an "answer" but you're not telling us the question. :)
Title: Re: Some notes on copyright and licensing
Post by: TestMonkey on February 09, 2013, 12:36:31 pm
Quote from: AngelinaBelle – 1) The copyright line question -- the answer, for Simple Machines, is that the copyright statement says "Simple Machines and Simple Machines contributors". This acknowledges that the organization has the right to defend against copyright infringement. This is only important to Elkarte if it ever wishes to have the "Elkarte project" sending notices to copyright/license violators, as opposed to having them sent on behalf of the individual contributors.
I don't fully understand. First off, the proposal to have the copyright notice tweaked this way has been made to SM "corporation", and SM has rejected it without even admitting they did so. It was a compromise, which shouldn't have been necessary as compromise, but anyway.
What this says, however, is that SFLC advices that a "corporation" (or project) has standing to sue for copyright infringement, only because they write (c) in the notices? That's a joke, probably. Whatever you add in a poor notice, doesn't give you the right to sue for copyright infringement.
You either hold copyright, or you don't. If you don't, the only other option is to do it exactly on behalf of contributors*. A notice doesn't "give copyright". It might acknowledge what exists or not, but not "add" copyright. So you can only sue on behalf of contributors if they enable you, or assist them when *they sue.
So what exactly does this mean, mind pasting exactly the wording you have received from SFLC on the matter?
I suspect that what SFLC means is far less: that you can send a notice to infringers, thanks to the so-called "evidentiary weight" of notices. Meaning, 3rd parties can see a notice if it is written at all (as opposed to not have a (c) notice at all), and when they remove it, it's clear they did so intently, removal is an action. They can't claim "oh I didn't know this code was copyrighted". But the notice text does NOT make any difference to who is the copyright holder: and Simple Machines "Corporation" is not. This was the issue - the issue SM created - that they must "hold copyright". Not that we can tweak the notice.
I think same goes for ElkArte (though for Elk, it's slightly more interesting, since we're an informal association). Sure any of us can send an email and sign it "ElkArte project", saying "look, it said (c) ElkArte project and you remove that", but that means nothing else than a way to do so on behalf of contributors. And, "the project" can't sue (note that this is different than a poor sending of an email). Only copyright holders can, unless they explicitly give rights to sue on their behalf to some entity.
Removing copyright holders from the (c) notice doesn't do that. Adding an entity to a notice doesn't do that. It's a text, not a contract, not an assignment, not something that would make a difference as to who the copyright holder is.
Title: Re: Some notes on copyright and licensing
Post by: AngelinaBelle on February 11, 2013, 05:15:38 pm
I agree that the truth of statements about who the copyright holders are is the same no matter what is in the copyright line. That line is merely for information, to let everyone know who the copyright holders are, since they might not know without this information line.
For 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. Making such a change to the copyright statement is a decision which should be made by the SMF project team members, who are more or less also the Simple Machines members.
Each project can be different, depending on how it is run. Elkarte project members are the only ones who can explain to the world how the Elkarte project functions, and whether "Elkarte" belongs in the copyright statement at all, or whether Elkarte would prefer only "Elkarte contributors".
Title: Re: Some notes on copyright and licensing
Post by: AngelinaBelle on February 11, 2013, 05:28:26 pm
Quote from: TestMonkey – the proposal to have the copyright notice tweaked this way has been made to SM "corporation", and SM has rejected it without even admitting they did so.
I think this was a signal-to-noise problem. I think that, by that time, there was so much confusion and argument, and so many people confused about what was "legally OK" that this proposal got lost in the noise.
I read so many posts, and understood so little myself, that I could not have any opinion about what the best copyright line would be.
And I will review my notes, so I can post more of what I actually asked the lawyers, both in email and over the phone. I understand this context is important to understanding.
My only thought was that legal counsel was needed. And so, with the assent of some other folks at Simple Machines, I did that.
If I personally offended anyone by failing to understand the law well enough to recognize this proposal as a good one the first time it came around, I sincerely apologize for my own actions.
Title: Re: Some notes on copyright and licensing
Post by: TestMonkey on February 15, 2013, 11:04:13 am
To make myself clear. I appreciate your efforts and I consider the role you have played in this coup, more as one of those being fooled, than actual initiator. I do consider that your role is unfortunate. Please take the rest of the notes as not referred personally. They are not.
I will make a few quick initial corrections. I will come back on this.
Quote from: TestMonkey – the proposal to have the copyright notice tweaked this way has been made to SM "corporation", and SM has rejected it without even admitting they did so.
If I personally offended anyone by failing to understand the law well enough to recognize this proposal as a good one the first time it came around, I sincerely apologize for my own actions.
I said it was something proposed to the corporation as compromise, a temporary compromise for that matter. To calm down the loud intentional yells of certain people and their corporate agendas.
I did not say it was "omg the law". I did not say it was in any way warranted. Legally or otherwise.
But. That's the past. For the record, I no longer support anything of the kind. It was strongly rejected by two contributors, to my knowledge, in the meantime. I am one of them.
Quote from: AngelinaBelle – My only thought was that legal counsel was needed. And so, with the assent of some other folks at Simple Machines, I did that.
"Some other folks at Simple Machines" means: no one knew what the management was going to tell SFLC. You discussed in closed, BoD-private boards, closed to everyone, and didn't bother to ask anything, not even, y'know, developers and contributors. Those who actually were DOING THE WORK you were "talking" about to SFLC.
You'd think they might have an idea as to who has been "editing their work", huh? In the past 10 years, by the way.
Quote from: AngelinaBelle – EVERYONE holds copyright -- contributors and editor, and it is useful to add that into the current copyright statement in the SMF code.
Let me get this straight.
The entry-level for the SMF team is two months of simply providing user support in the boards.
So, according to the information provided in this topic.
If you want to "own copyright"1 to the SMF codebase, then all you have to do is:
provide 2 months of support in the boards.
in the 3rd, you can be invited in "the SMF Team", and in the SM Corporation.
then, you automatically "own copyright" over the code. The "corporation", you say, does. SFLC "told you so".
or, perhaps it's not automatic, you also should behave according to any of the following:
claim you "make decisions over prioritizing of the code refactoring". It doesn't matter if you're willing to step up and do the work. It doesn't matter if you even know what code refactoring is. It doesn't matter if developers consider your particular opinion grounded in valuable reasoning or not.
yell you "make decisions over what contributions are accepted into the codebase". No need to get a github account or actually read pull requests, nor contribute to them, it "just works"tm).
state you "set priorities for features". Or, simply propose a feature I suppose. Don't bother to use the issue tracker, just sit on your seat and post it "in the team boards" closed view.
Then, miracle: you're the copyright holder of the SMF code. Your corporate management states that SFLC "told you" this is the US copyright law2.
You can just sit and talk and by that, "own copyright" over developers work.
Have I got this right so far?
1 This is a quote of the expression used by certain people over at SM. 2 Rather, this is what some people's agenda to achieve from the legal counseling, combined with what SFLC thought they're being told.
Title: Re: Some notes on copyright and licensing
Post by: Arantor on February 15, 2013, 12:09:50 pm
OK, first up, as I understand it, Angelina was the one who actually spoke to the SFLC. I would also note that I have been known to stand up and shout this one from the rooftops.
There are multiple issues at stake.
Firstly, the matter of original and individual copyright ownership. Is there any doubt of understanding that those who have contributed code hold copyright on the code they have contributed? They hold copyright. Even those who signed CLAs have not waived that, they just gave SM a licence to use it. The proposition as put forward essentially asserts the copyright of the code in each file as 'SM + all contributors' with a full file indicating everyone who has contributed. This is in line with how the Apache project operates. (And incidentally with the way the CLAs were originally written, based as they were on the Apache CLA)
Secondly, the matter of collective copyright ownership. I own the copyright on the code I contributed. You own the copyright on the code you contributed. There's no doubt or assertion to the contrary.
Who owns the total collective code? This is where it gets tricky. You and I might own individual lines, individual functions or more. But who owns the collective copyright on how those lines are assembled into a single work?
More importantly, who is going to defend the work when claims are made against it (either by people copying it inappropriately, or against claims of copied work)? Are you going to defend it? You can defend the parts you wrote, but you have no business defending the work to which you have no copyright, and that would get laughed out of any legal centre you walked into with it, including a court.
SM as the distributor has a certain amount of legal precedent in its favour as being the collective copyright owner as an organisation.
Thirdly: copyright exclusivity This is the part I think you're most upset about, and I think if I'm honest it's a misunderstanding on your part.
It has never been the intention of SMF to claim sole and exclusive rights to anything you contributed. It may have been misunderstood as that - and certainly that was the impression I was given, more than once.
However, the intent has always been about protecting the work - at no point were you ever asked to sign over your copyright. Assuming you signed either or both of the CLAs, you should re-read the clause about what you granted to SMF - a perpetual non-exclusive irrevocable right to use the work and to build derivative works. But that doesn't change the fact that you own it. You always did. Just as I always owned my contributions. Just as Unknown legally owns his, etc.
The whole concept of the CLA was about joint ownership - we still own our work, but we allow SM to use our work and in return for our contribution, they defend it on our behalf as part of defending the overall package.
Thus the correct copyright line is indeed "Simple Machines and Simple Machines contributors", on the basis of the two separate strands, with the full list of contributors included with the package. This is how other, longer established, larger projects work.
It also provides a blanket of protection - if there were to be a lawsuit, it would naturally target the parent distribution first rather than targeting individuals.
Your argument about 'owning copyright' is flawed, as is to a point the viewpoint of the person who probably made that quote (if it is who I think it is). You can, after a couple of months of support, be eligible for team duties. And onwards to NPO membership.
However. that does not give you any rights to the code's ownership. You certainly don't own anything in the code unless you put it there yourself, not even as an NPO member. The organisation owns some limited rights, but not enough to claim ownership of anything.
If you leave the NPO, you don't get to magically keep the rights you had. The organisation has those, not the people in it. Only people acting in an official capacity, working on official business, can actually make any claim - and even then it's still not as strong as any claim you hold on anything you contributed.
Title: Re: Some notes on copyright and licensing
Post by: Antechinus on February 15, 2013, 02:02:23 pm
Question: do we have to import all the arguments and acrimony from the SMF boards to this site?
Suggestion: anyone who wants to do that should get a room, and leave the rest of us in peace.
Title: Re: Some notes on copyright and licensing
Post by: TestMonkey on February 15, 2013, 02:17:09 pm
Re: Antechinus.
I am well aware that the topic is prone to hot discussions. However, I am not going to prevent use of elk boards because it's prone to hot discussions, nor am I going to censor fully all my statements - though I refrain more than I probably should. On the contrary, I am stating only a few of the things that need to be stated.
FYI, don't worry too much: I and only I take full responsibility for my statements. I have actually tried to understand what the heck was SFLC told by the management, I have contacted them (since there is no "omg legal matter here, look SFLC said we're ALL copyright owners" anyway, but some interests at SM make the scarecrow appear so), and I stand by my statements. Since this site has been "discovered" so-to-speak, before we (somehow) may have intended, people from SMF community may find this discussion useful.
Counter-hint: put it on ignore and/or use disregard. :) And hint: if you don't care, that's your privilege.
Re: Arantor.
You refer only at SM Corporation "why would it be useful to own copyright", and not at Angel's statements. Did I understand correctly? (before I answer, which might be tomorrow.)
Title: Re: Some notes on copyright and licensing
Post by: Arantor on February 15, 2013, 03:33:30 pm
QuoteSuggestion: anyone who wants to do that should get a room, and leave the rest of us in peace.
It affects Elk, just as it does Wedge.
QuoteYou refer only at SM Corporation "why would it be useful to own copyright", and not at Angel's statements. Did I understand correctly? (before I answer, which might be tomorrow.)
I've had the privilege of seeing a little more depth to what's been said. The reality is that SMF does not, has not, and will not lay claim to own your contributions nor does it, will it or has it laid claim to copyright of your individual contributions. Nor mine. Nor anything else.
It has laid claim to the total sum of the package. That is what the SFLC have said. You and I individually might have copyrighted contributions for bacon and eggs while SM holds the order in which these things have to be cooked to make a fantastic breakfast.
I see no problem with SM and contributors being credited. If anything it is more accurate and legally protective than just SMF contributors. I would love to hear what actual specific objections you have to what has been proposed and stated.
Title: Re: Some notes on copyright and licensing
Post by: AngelinaBelle on February 15, 2013, 04:31:50 pm
I did promise, and I will keep my promise, to share my notes about my discussion with SFLC with the entire SMF community. Of course, SFLC lawyers will not answer questions about its discussions with a particular client, unless they come from that same client. They can answer your questions about what was said if Simple Machines gives permission for them to do that.
I will be happy to do my best to clear up confusion, as much as possible.
TestMonkey, If I understand you correctly, you do not agree that the project team, as a whole, should stand in the position of "editor" of the joint work (not as contributor or even editor of any individual contributions, of course). It is worth having a discussion over this. It has a lot to do with how a project is run.
I think that the current SMF team members have the understanding that the SMF team actually does have the role of editor of the work. And that one of the main reasons for setting up, first the LLC, and then the NPO, is so there is some entity which exists to protect the copyright, should that ever become necessary.
Arantor's analogy is pretty good.
Quote from: Arantor – You and I individually might have copyrighted contributions for bacon and eggs while SM holds the order in which these things have to be cooked to make a fantastic breakfast.
Of course, not every project runs the same way. And you might not agree that this is how the SMF project functions. In the end, it might not matter, because it may never be necessary to legally defend the SMF copyright. I am sure the lawyers could do a much better job than I could of explaining all of this. So I will talk to them more about it.
Title: Re: Some notes on copyright and licensing
Post by: TestMonkey on February 15, 2013, 05:46:14 pm
Arantor, a note:
I am surprised you even consider the issue of the so-called "exclusivity". That is a red-herring.
No one and never in FOSS grants any exclusive rights. Not even actual copyright assignments don't: even they grant back a maximal license (they mean exactly the converse of Apache-type CLAs.).
Note also that the *copyright license*, again, is non-exclusive, and grants exactly the rights it grants.
Please, lets move forward from that. Just leave it aside, because if that is what you read, then the reading is incorrect.
As a side note to this. So, I get that this is how people are pressured and conversations messed up in private environments at SM lately.
Title: Re: Some notes on copyright and licensing
Post by: Arantor on February 15, 2013, 07:41:16 pm
So, let's move from that, which brings me back to the question I already asked: what exactly is the problem you have with the proposal, and WHY is it a problem?
Right now all I'm getting from you is that you disagree with it because it's not what you want. This is bigger than you.
Title: Re: Some notes on copyright and licensing
Post by: TestMonkey on February 17, 2013, 07:13:51 pm
Quote from: Arantor – So, let's move from that, which brings me back to the question I already asked: what exactly is the problem you have with the proposal, and WHY is it a problem?
Quote from: AngelinaBelle – 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.
Translation: "SMF" is dead.
Quote from: Arantor – I've had the privilege of seeing a little more depth to what's been said. The reality is that SMF does not, has not, and will not lay claim to own your contributions nor does it, will it or has it laid claim to copyright of your individual contributions. Nor mine. Nor anything else.
In the interest of historical accuracy: of course it has (but nothing to do with exclusivity crap). Endlessly.
To clarify a few things. (there are many ideas I have to take the time to answer, and please note: I will come back on this.)
Apache-type CLAs are maximal license grants, and honestly, they're confusing. They grant any sub-rights of copyright, except practically the right to sue for infringement. That's what they do NOT grant, to my knowledge.
In the past, we have taken them for joint copyright, because tbh that's what they almost are: copyright to both the developer and the corporation. I know I did, and afaik anyone else did. And in this sense: of course SM was thought to own the software. It has been said over and over, including in public boards. That, as some people put it: SMF was [thought to be] "the property of the corporation".
(TBH, the license grant being so wide, even if you read (for a change) and see it as grant, of course it gives room to something practically similar anyway.)
Think. It's simple: it was intended by some to be exactly what you read, be the property, or treated as the property, of a corporation of non-contributors. (be = be treated as. It doesn't matter "omg legally", it matters what people make of it...)
property/corporation/non-contributors. Three words that shouldn't add up in the same phrase. They had a good share in what killed the project. Because, of course, they have... They enable and "institutionalize" entitlement. And thereby management.
They "legitimize" the incessant attempts to create an environment of control and authority, of those who don't do the work, over those who do.
That's why I have removed CLAs.
An Open Source project is not the property of anyone. No one "owns" SMF. And this is the truth. It dies anyway, but I cannot allow this. It's the only thing that I could do in the end.
OTOH. It's the same thing if an entity has more rights than anyone else: any right. Bear with me.
Quote It has laid claim to the total sum of the package. That is what the SFLC have said. You and I individually might have copyrighted contributions for bacon and eggs while SM holds the order in which these things have to be cooked to make a fantastic breakfast.
Yes and no. There is no total sum of the package, that is not whatyoudo*. That's what it is: what you do. What commits you accept, what refactorings you make, what features you set as goals for the next release. What pull requests you accept. It's joint work of all developers/contributors, yes, and that is ALL there is to it: yours and who was making it with you. The work of those who make it. I did not notice any "order" being set by SM in my work. I set the order. Developers do.
(It's only if *some entity interferes with the process, that there may be something "extra" created, a difference, something copyrightable.)
Developers do so under the development process. We had, in SMF, set up a development process which transitioned from a closed environment to open development. That process welcomed everyone to take part to: to.take.part. To be a part of the project, as developers were making it. [Compare with AB's, (and everyone else's) historically accepted assumption that "the team is the project, the rest are outsiders".]
No. A part is a part: with equal chances and equals rights to shape up the project. Not a "outsider who donates a contribution to the higher entity". Not "an individual that works for the corporation". Not "a corporation/group/team with the right to impose something on you, on your work." A part of the project, in its real sense, that SMF will never move towards... the true bigger-than-you.
The open development process offers everyone the right to help with code refactoring and whatnot. Everyone, not only the team.
In no case, I don't see here anything different than what people do*, I don't see any licensing/copyright transfered, when people work together. The sum is what it is: a commons of software. The software on which you push a button on a release.
So, where does the extra-"copyright" come from?
Now. You say, Apache is doing something, there must be some sense of this "sum" which they can copyright. I'm not entirely sure of all Apache handlings, note. But I *think[/i] it's about: both CLAs and the Apache development processes. On a joint work, only authors hold copyright, and they grant a license - for Open Licenses, a license that allows everyone to use/modify/share/reshare the work, in the same conditions for everyone. No one is discriminated, no one is privileged. However, if this work was submitted to Apache foundation development processes (which of course SM has nothing in common with; SM is not Apache.), which include decision making from the foundation, then the result is edited, meaning derivative, by someone else too: by Apache. (by the way, they include the notice changes, which are only possible thanks to their 100% CLA coverage, or 97% lately) I don't know the details of the claim more than that. But I think it's important to understand a point: for someone else to receive some copyright/licensing right which wasn't granted, this someone else has to make changes on the work.
The answer is right here.
Quote from: AngelinaBelle – 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.
The only thing that "a few folks at Simple Machines" (it is a quote, not sarcastic) ever aimed, is authority over the software. Control development.
Under the current development policy on licensing/copyright, There is no right granted to anyone, including the SMF team, including SM corporation, to interfere with the software. Everyone can participate (that's in the license and development process I had left there), no one can interfere. Not by using copyright as means of enforcement. => only contributors notice is appropriate.
But, If 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.
Quote from: Arantor – More importantly, who is going to defend the work when claims are made against it (either by people copying it inappropriately, or against claims of copied work)? Are you going to defend it? You can defend the parts you wrote, but you have no business defending the work to which you have no copyright, and that would get laughed out of any legal centre you walked into with it, including a court.
Lets take another example.
QuoteJudge: In the name of what do have standing? SM 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? SM Corporation: well we pulled them down, and there's no one left in what we call "project" Judge: err, huh, ...why? SM Corporation: well they were all annoying gits, because they didn't like it when we sit and made decisions on prioritizing code refactoring. But we have standing because we did that; after all, SM corporation was created to have authority over the software. Judge: ...
QuoteThe whole concept of the CLA was about joint ownership - we still own our work, but we allow SM to use our work and in return for our contribution, they defend it on our behalf as part of defending the overall package.
SM can use the work under the same license terms as anyone else: BSD 3-clause license. We don't need to "allow SM" specifically anything. This isn't SMF's old proprietary license: everyone gets the right to use it freely, to distribute it at will, modify it and reshare it. No need for "permission". But also: NO entity needs more licensing rights than others, specially as: - you're talking about a closed-doors corporation of non-contributors, a corporation that is not capable to handle such double-edged rights. - 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.
Quote This is how other, longer established, larger projects work.
This is how none that I know of, of longer established projects work: :) Through authority on the software, of those who don't do the work, over those who do. Not alive projects, anyway.
Title: Re: Some notes on copyright and licensing
Post by: Arantor on February 18, 2013, 11:29:43 am
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.
Title: Re: Some notes on copyright and licensing
Post by: TestMonkey on February 18, 2013, 01:16:43 pm
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.)
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.
Title: Re: Some notes on copyright and licensing
Post by: TestMonkey on February 18, 2013, 02:31:48 pm
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".
Title: Re: Some notes on copyright and licensing
Post by: TestMonkey on February 19, 2013, 04:39:23 pm
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.
Title: Re: Some notes on copyright and licensing
Post by: Antechinus on February 19, 2013, 05:51:12 pm
Are we there yet? (http://www.councilofexmuslims.com/Smileys/custom/popcorn.gif)
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. ;)
Title: Re: Some notes on copyright and licensing
Post by: Arantor on February 19, 2013, 10:35:03 pm
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.
Title: Re: Some notes on copyright and licensing
Post by: Arantor on February 19, 2013, 10:35:18 pm
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.
Title: Re: Some notes on copyright and licensing
Post by: Arantor on February 19, 2013, 10:35:29 pm
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.
Title: Re: Some notes on copyright and licensing
Post by: Arantor on February 19, 2013, 10:35:47 pm
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.
Title: Re: Some notes on copyright and licensing
Post by: Arantor on February 19, 2013, 10:36:17 pm
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!)
Title: Re: Some notes on copyright and licensing
Post by: TestMonkey on February 28, 2013, 05:58:34 am
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.
Title: Re: Some notes on copyright and licensing
Post by: TE on February 28, 2013, 02:49:59 pm
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..
Title: Re: Some notes on copyright and licensing
Post by: Arantor on February 28, 2013, 03:28:09 pm
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.
Title: Re: Some notes on copyright and licensing
Post by: TestMonkey on March 02, 2013, 01:15:47 am
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.
Please accept my apologies for writing a bit on the run.
Title: Re: Some notes on copyright and licensing
Post by: TestMonkey on March 05, 2013, 11:52:00 am
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.
Title: Re: Some notes on copyright and licensing
Post by: Arantor on March 05, 2013, 11:59:05 am
QuoteIt has come to my attention that SFLC has sent these days, to the SM Corporation, an advice.
My understanding that it is over the revised wording of the copyright in respect of what they think it should say and what the SFLC says about it.
QuoteBecause 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".
SMF team? Cede control? descends into insane laughter
I'm not sure they disagree with the legal counsel. However... I'm not sure the real situation was made clear to the legal counsel in the first place - so the counsel advises based on what they are told but if what they are told is inaccurate, they're going to provide 'bad' advice.
I have an understanding of what the proposal is. If it is as I understand, it is not substantially different to what we have seen before, in that it is just as inaccurate as we have seen and that the underlying problem of who really owns what hasn't been solved, and may well have been misrepresented.
QuoteThe interests of a very closed group of non-contributors are more important than you, your work, your time, your code.
More critically, they do not understand 1) that it IS a problem, 2) WHY it is a problem, or 3) that it applies to THEM.
The upcoming SMF project manager election is interesting. At least one candidate is campaigning on the bill of getting the NPO as far out of the main SMF project as possible. It will be interesting to see what happens and whether it fosters a change in this deeply-entrenched mindset.
Title: Re: Some notes on copyright and licensing
Post by: TestMonkey on March 19, 2013, 09:00:22 am
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).
I know, TE, and I should apologize. The simple truth is, no serious developer would or can contribute to a project which is not lead by developers. If developers don't try, find, or succeed a good way for a governance model (which is not a corporate model, and never a corporation of non-devs, of course), then there is no "project". Under that name. I'm sorry. FWIW, I apologize.
QuoteHow 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.
And they've done amazing work, and advanced the community software in the direction of their dreams, involving in a way the community too. Even as an essentially closed project, they're doing it very well, come forward with their intentions, and take community input.
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).
From (part of) my perspective, we continue doing what we were doing. I believe every one of us here had their goals to achieve in the best forum software we want to have, and we want everyone to have. And I know developers were going towards this kind of process we see here now. They're focusing more on the code than the process or project presentation (and that was normal), at the moment, but as we're getting ready for public beta release, we will see more on how it works, with everyone who is getting involved at any level.
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..
Yes. Actually, it's worse than how you left it. It's fizzling away over there, TE. You were right in 2010, and I couldn't turn it around.
QuoteThe 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..
Some people never learn. Management never learns. Corporations are always this way, they suffocate Open Source projects, no matter if you call them LLCs or NPOs. SM should have never become a corporation, but it did, to a level which is, IMO, simply unfixable, all things (and I mean all) considered.
That makes it only more important (and I address to Arantor as well here), that we move forward. People need to rely on the project they choose to run on their servers. It's important for thousand of installations out there.
The thing is, at the end of the day, that Open Source projects don't really die, as long as there are dedicated developers and a community around them. They will be reborn under another name, when it comes to that. It's not easy, it's not a game of sorts, as some people imagine. It takes work, it takes dedication, it takes knowledge and it requires freedom. And they have all that, and it is what they need to do, to make sure the software is safe, at the level of quality they're comfortable with, filling the goals they set for the releases, free to be deployed when they know it has to.
Title: Re: Some notes on copyright and licensing
Post by: Arantor on March 19, 2013, 06:34:40 pm
QuoteThat makes it only more important (and I address to Arantor as well here), that we move forward
I've left them to it, because after the last few days I've come to the conclusion that there's not really anything of the project to salvage and of the software, all concerned who want, and have the ability, to move it forward are doing just that under their own steam.
I find it slightly ironic, and slightly sad, that in the pursuit of the title of openness, they have secured the software's future, but at a very high cost.
Title: Re: Some notes on copyright and licensing
Post by: TestMonkey on April 04, 2013, 10:13:02 pm
(05:00:52 PM) Norv: Oh, on another note. A remark. It's been so so sad to me (or enraging!), to see some thing on the April 1st joke: in News and Announcements, meaning "officially", people state their pride to "ask and receive permission" to use the software - or icons or theme. SM/SMF is PROUD and officially continues to endorse proprietary software.
On one side, I think themes and design generally, should have always leeway. Just think at premium themes. That's not an issue. What people do on their work is whatever they choose to do.
But what the project does, "officially", the announcements, the way they interact, recommend, to the community, is another story. Endorsing proprietary mindset in the own acts of the project. (The sad part is, I have the subjective conviction that people don't even realize when they're doing it... It's a reflex, after 10 years of proprietary project. It's "normal" to state they proudly continue to apply proprietary software - not only old stuff [existing], but also newly.)
On the other hand, I think we all know the Wedge issue with the "ban" from so-called "official showcasing" of forks. (which in itself is strange... and yet another story.) To summarize: do what I say, don't do what I do. Heh.
Title: Re: Some notes on copyright and licensing
Post by: TestMonkey on April 04, 2013, 11:50:17 pm
QuoteI find it slightly ironic, and slightly sad, that in the pursuit of the title of openness, they have secured the software's future, but at a very high cost.
Not exactly, Arantor. "They" (whoever you mean) did not really pursue openness - sure, people usually agreed with it, but did usually not pursue it. They usually don't know how. And I understand that - after 10 years of proprietary mindset and culture of closeness-by-design. (by design, not randomly, not temporary, not any other way)
I am not blaming people for not knowing, I am not blaming people for not wanting, even. It's the empty pretenses that ... lets just say do not stand right with me. And even that, is not fully relevant.
I have made the project free, and tried to open it, in the measure I could, and could figure out how - considering the circumstances and people's will. Until the movement ended. Until the corporation - one way or the other - and proprietary/corporate mindset and actions made it impossible. Pushed out all developers, and other people, and left the project with no future. "They" support - and claim to "own" - a dying project, and that's... just how it is.
You see, I believe the project needed, absolutely needed, freedom, and I tried to do so. To bring it out, to the community. To the best of my knowledge and conviction, it was an absolute necessity and a will of an entire community in 2010. Remember SMF-Friends site, remember former developers intentions to make an alternative project BSD-licensed, in 2010/2011.
Not "they", not the "corporation", not the "team", not the "steering committees". With all due respect. People usually agreed, with the steps we (developers, most of the time) made, and that's how it's supposed to be, but that's saying something different.
But I failed to bring the project much on the path of openness. It ended too soon, for the mentality of openness, and the culture of freedom, to stick with people, to change the way it works. Perhaps it was impossible anyway, perhaps it's my mistakes, perhaps both. I don't know.
What you see today, is not "they" and "their openness". There is no such thing, most of the time. It's a confused number of people, taken over by a corporation and its management, and a project in agony, under that name. It doesn't know where it is, and it's unfixable.
Title: Re: Some notes on copyright and licensing
Post by: Arantor on April 05, 2013, 12:25:39 am
QuoteOn the other hand, I think we all know the Wedge issue with the "ban" from so-called "official showcasing" of forks. (which in itself is strange... and yet another story.)
Of course we do. We've always known. I would have long been satisfied if they'd just admit it rather than hide it behind some 'it's not open therefore you can't play in our sandbox' malarky.
QuoteNot exactly, Arantor. "They" (whoever you mean) did not really pursue openness - sure, people usually agreed with it, but did usually not pursue it. They usually don't know how. And I understand that - after 10 years of proprietary mindset and culture of closeness-by-design. (by design, not randomly, not temporary, not any other way)
Ah, you misread me. I never said they pursued openness. I said they pursued the title of openness. Something far less noble. They don't know how, they don't know what openness is. Their actions have shown this, time and again, that they don't understand what openness means. They just act in a way that seems to work towards having the title.
Much like one can have a certification in something and have no idea on its practical applications (like a number of my fellow Zend Certified Engineers would seem to be)
QuoteWhat you see today, is not "they" and "their openness". There is no such thing, most of the time. It's a confused number of people, taken over by a corporation and its management, and a project in agony, under that name. It doesn't know where it is, and it's unfixable.
You and I disagree on this. There is a 'they'. They can claim the title of openness and by the letter of the lay of things, there is an argument they might even be right. But to call something open and for it to be open are two distinctly different things.
I have been part of events for some time now. The moments I have re-entered their stream of things I became part of the fabric of those events. I am only too aware that what they have, they truly believe is open. They believe they have reached a place that they can call open. And if you look at it from their perspective, you might be able to see why they have come to that conclusion. They're wrong, in every conceivable sense, but you can at least see why they have the position they do.
Openness is not a state they understand. It is one that we chose not to embrace at the present time in strict deed, but I would argue that even our closed state is more open than their self-anointed 'open state' and that when a final point of judgement is made, when history looks back on us, our (Nao and myself) calls for openness and the apparent discrepancy with our own actions (the apparent hypocrisy of calling for openness when being closed ourselves), I believe that our decision will ultimately be vindicated.
/me remembers the troll last summer that I refused to ban, on the grounds that despite his insults, he had a point of sorts and a valid opinion.
It's late and I'm pontificating, but I think you're largely preaching to the converted. We know their definition of openness is a bit skewed, as is their definition of compromise. Their institution is damaged, warped, yes. Unfixable? I don't know. It feels like it might as well be.