Alternative to FIG 3.0: Encourage *-interop projects

[Paul Jones]

Dear Voting Members,

There is another way to solve the problems listed in the [FIG 3.0 summary][1]: formally encourage the creation of a *-interop project as a prerequisite to a FIG entrance vote. (Look to container-interop and async-interop as examples.)

* * *

Point by point from the FIG 3.0 tl;dr:

> Everyone has equal say on FIG PSRs, no matter their expertise or their project’s relevance in the PSR’s problem space

A *-interop project concentrates on its particular problem, and can invite (or draw the attention of) those who have relevant expertise. Both container-interop and async-interop were able to this successfully.

> There are lots of clever awesome people involved in the FIG who are not project representatives

A *-interop project need not be limited to only project representatives. It can accept (or refuse) anyone it wants.

> Member projects find it difficult to engage in everything going on in the FIG

Interested parties can enagage in as many, or as few, *-interop projects as they like.

> There is an ongoing question if the FIG produces PSRs for member projects or for the wider community; especially when the wider community pays it so much attention due to its de-facto status as ‘the php standards body’.

Each *-interop project can define for itself the audience it addresses.

* * *

This has several advantages over the FIG 3.0 approach.

- fewer rules changes (perhaps only one!)

- less bureaucracy

- less centralization

- reduced hierarchy

- fewer committees

- more flexibility

- greater openness

Each *-interop gets to operate in the way it likes, according to its own project members.

Each *-interop can work through its ideas among a smaller set of interested participants, perhaps with implementation trials, without having the pressure of "being a standard" from the outset.

Once a *-interop project feels it has solved its particular problem, it can petition for FIG entrance under current FIG bylaws.

If there is more than one *-interop groups tackling the same problem in different ways, FIG can pick from the different groups, or ask that they merge their efforts before entrance.

FIG can also see how broadly the work of *-interop group has been accepted, providing real-world information as to the value of the work before the entrance vote.

* * *

Please consider this the opening of the 2-week discussion that occurs prior to a vote; of course, it may go on longer than that.


[1]: https://medium.com/@michaelcullumuk/fig-3-0-91dbfd21c93b#.4fhp3srq0

--

Paul M. Jones
http://paul-m-jones.com

[Alessandro Lai]

This is a really nice proposal.

I also think that this does not solve anyway the issues of the FIG itself; maybe the best option could be to push for both approaches? Nothing in the FIG 3.0 proposal forbids that!

In fact, I think that the FIG 3.0 modification are good anyway, and that the *-interop groups can still be formed and promoted, even outside of the FIG reach; then, each *-interop can choose to "be embraced" by the FIG, where the work (which is already done) can be formalized as a PSR, with little work and two simple votings.

What do you think?

[Larry Garfield]

I actually see little in the suggestion below that isn't already implicit in FIG 3.  *-interop is, really, just the Working Groups.  If people want to work informally on something before coming to FIG to form a WG, we certainly can't stop them.  If they'd rather form a formal WG early on for better visibility, I'm good with that too.

All the proposal below is saying is "please talk a lot informally before you come to us".  Which, while a nice thought and one that I do not oppose, doesn't address the structural issues that FIG has at all.

--Larry Garfield

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/b14f9c91-265b-4606-80c0-fdbfcbf37169%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jan Schneider]

Zitat von Paul Jones <pmjo...@gmail.com>:

> Dear Voting Members,
>
> There is another way to solve the problems listed in the [FIG 3.0
> summary][1]: formally encourage the creation of a *-interop project
> as a prerequisite to a FIG entrance vote. (Look to container-interop
> and async-interop as examples.)

IMO the WGs are the formal creation of what used to be interop
projects. Lessons learned from these projects have sure been taking
into account when creating the ideas of working groups. At least
that's my personal impression.

> * * *
>
> Point by point from the FIG 3.0 tl;dr:
>
>> Everyone has equal say on FIG PSRs, no matter their expertise or
>> their project’s relevance in the PSR’s problem space
>
> A *-interop project concentrates on its particular problem, and can
> invite (or draw the attention of) those who have relevant expertise.
> Both container-interop and async-interop were able to this
> successfully.
>
>> There are lots of clever awesome people involved in the FIG who are
>> not project representatives
>
> A *-interop project need not be limited to only project
> representatives. It can accept (or refuse) anyone it wants.
>
>> Member projects find it difficult to engage in everything going on
>> in the FIG
>
> Interested parties can enagage in as many, or as few, *-interop
> projects as they like.
>
>> There is an ongoing question if the FIG produces PSRs for member
>> projects or for the wider community; especially when the wider
>> community pays it so much attention due to its de-facto status as
>> ‘the php standards body’.
>
> Each *-interop project can define for itself the audience it addresses.

Besides that latter, all this applies to the FIG 3.0 WGs too. And I
don't think that each group should define its own audience. For
consistency and relevance reasons, this should be defined by the FIG
as a whole. If a WG considers the audience too narrow for their
purposes, they can start a discussion to broaden the audience on the
FIG level.

> * * *
>
> This has several advantages over the FIG 3.0 approach.
>
> - fewer rules changes (perhaps only one!)

This is not necessarily an advantage on its own.

> - less bureaucracy

While I consider this generally a good idea, I would also say that
more rules make some discussions less necessary. Or even meaningful.
Also, for a standardization entity, a very formal approach is making
the outcome more transparent and confident.

> - less centralization

This is also achieved by the FIG 3.0 proposal.

> - reduced hierarchy

Didn't work in the past where the whole FIG body discussed and decided
everything. I suggest we see more hierarchy as distributed
responsibility instead.

> - fewer committees

See above.

> - more flexibility

Not necessarily a good goal for a standardization body.

> - greater openness

I don't see this.

> Each *-interop gets to operate in the way it likes, according to its
> own project members.

Again, not necessarily good in standardization processes. Who trusts a
standardization group if the groups processes aren't standardized too?

> Each *-interop can work through its ideas among a smaller set of
> interested participants, perhaps with implementation trials, without
> having the pressure of "being a standard" from the outset.
>
> Once a *-interop project feels it has solved its particular problem,
> it can petition for FIG entrance under current FIG bylaws.

Like the WG.

> If there is more than one *-interop groups tackling the same problem
> in different ways, FIG can pick from the different groups, or ask
> that they merge their efforts before entrance.

This shouldn't even happen right from the start. That's why the CC is
a good idea.

> FIG can also see how broadly the work of *-interop group has been
> accepted, providing real-world information as to the value of the
> work before the entrance vote.
>
> * * *
>
> Please consider this the opening of the 2-week discussion that
> occurs prior to a vote; of course, it may go on longer than that.
>
>
> [1]: https://medium.com/@michaelcullumuk/fig-3-0-91dbfd21c93b#.4fhp3srq0
>
> --
>
> Paul M. Jones
> http://paul-m-jones.com

--
Jan Schneider
The Horde Project
http://www.horde.org/

[GeeH]

I completely agree with Paul here, this is, for me, at least worth investigating. It takes the onus off the FIG organising the minutiae of HOW standards get created but puts the focus on the group to ratify things that are ready to be added as a standard. Container Interop is a great example here, it was self-formed and has got wide adoption and is ready to be ratified as a PSR in my opinion. I'm not convinced that this group needs to worry about who is involved in creating a standard, or how the   proposals get to the point where they can be considered a PSR - it's been proven that self-formed small groups can get that job done.

I appreciate that the role of this group could not be completely "hands off" - for example, if no standard exists for $x, and the group feels that a standard is needed in this area, then it will need to address the problem and encourage a team to tackle this problem. I know people will say "that's exactly what working groups are going to be!" and I can see that, but in all reality, it's not. Working Groups (from my understanding) will be regulated and will need at least $y number of people of which $z are from the group. I would prefer to see the FIG simply maintain a list of things they think need addressing, and encourage teams to look at the problems. 

I believe that moving the focus of the FIG from a problem-solving body to a ratification body will make life easier for everyone, and will solve some of the problems being addressed in the FIG 3.0 proposal.

Gary

[Glenn Eggleton]

100% agree with Gary and Paul.

*-interop projects are the embodiment of everything the FIG wishes to achieve, "Framework INTEROPERABILTY group". 

Can this be done in the purposed "Working Groups of FIG 3.0" ? I do not think so.

From the TLDR of FIG 3.0, context of talking about the Working groups.

Doing what: Actually working on the spec. They also have the main vote on if the spec is ready for approval, essentially the technical sign-off part of the current acceptance vote.

Who: Consists of the Editor (Can be anyone just as per the status quo), core committee representative (sponsor) representatives from member projects with relevance and problem space experts

What is lacking from the TLDR is the political wall FIG 3.0 imposes on community members.

This is directly from the draft: https://github.com/php-fig/fig-standards/pull/752/files#diff-b58538881047f8ede6b65a2ca2e01261R76

Members of the general public may apply to join the Working Group at any time, subject to the approval of the Editor or Sponsor if, in their judgment, the applicant's experience and perspective would be particularly valuable to the development of the specification.

I think making the community generate an *-interop project before even the draft PSR is a good thing for a number of reasons:

1. It forces the community to do all of the hard work [ like negotiating with design decisions, forming alliances ... etc ]
2. Out of the interop projects; there becomes implementations available, and wide-spread adoption
3. FIG is simply to formalize the outcome of the Interop process, nothing more.

I find it quite offensive that FIG thinks it has the power to modify community lead interop projects. Nothing that doesn't already have an implementation should become a PSR.

A PSR should be a formalization of something the community already has.

The only way to do that would be to have an interop-group before you submit for a PSR.

[Phil Sturgeon]

Hey Gary!

As Larry suggests, the two approaches are very similar and not mutually exclusive. Taking container interop as an example again, it could easily be a random project by interested parties that is then turned into a working group, as a working group is what would be needed to really beat it into shape over the last mile.

If the purpose of FIG 3.0 is to turn into a proper standards body - and not just a ratification of stuff more than half of the member projects are currently doing (or like the sound of) - then a working group is important. Extra eyes, extra time, extra steps, etc are all required to make it hit that level. 

If we want to carry on exactly as the FIG has done, then letting people make standard implementations and build a bunch of code off it, then get frustrated if anyone wants change and just let it languish for years or slap a rubber stamp on it because close enough... then continue with the interop approach. 

I don't think the FIG 3.0 suggestions as they stand make them a problem solving body, I think they're just saying "Come and have the conversation with us" instead of "Ah do what you like, come back when you're done and hopefully it'll be something we want to ratify without totally recoding it." I'd hate to see that happen. 

Glenn: You seem a bit disgruntled here, maybe I could add some context as an observer of the FIG 3.0 conversations.

The "political wall" you refer to is "Should this person be in here." You'll often see a large group of inexperienced junior devs wanted to standardize something (we've seen about ten standards groups pop up and burn away to nothing in the space of months), mostly due to those folks being inexperienced. If you just let literally anyone get involved then you have a noisy mess that creates either nothing, or creates junk.

"I find it quite offensive that FIG thinks it has the power to modify community lead interop projects."

Where does it say this? What do you think the FIG is suggesting? If people want to make a GitHub repo with -interop in the title then they're perfectly welcome to do so, the FIG is not trying to stop that from happening and how the heck would it even do that? :D Don't forget, a foo-interop project could be a working group later, nothing would suggest otherwise. 

"A PSR should be a formalization of something the community already has."

Yeah mostly. Take a look at the HTTP Middleware examples, the community had implemented multiple approaches. Seeing as the community had multiple existing solutions, which would it standardize? The most popular? By which metric? 

Regardless of which of the many approaches should be standardized, many of the most popular implementations were using approaches that were full of holes. Should we rubber stamp this busted approach, or should we use the standardization process to improve the situation, and bring the PHP community up to scratch in the process?

I entirely agree that PSRs should have implementations built to test the theory, and they could be interop projects, or they could be Working Groups. They're not mutually exclusive, but I'd rather have a formal Working Group than just telling people to go away and come back with something to be ratified. 

The goal is to make the FIG a formal standards body, instead of just a pile of cowboys knocking out standards based on whatever implementation happens to be around like PSR-3 == monolog. :) 

On Tuesday, August 9, 2016 at 5:44:08 AM UTC-4, GeeH wrote:

[Glenn Eggleton]

Hey Phil, thanks for responding ;)

Glenn: You seem a bit disgruntled here, maybe I could add some context as an observer of the FIG 3.0 conversations.

Thanks :) I apologize if my response seemed a bit "ranty", that was not my intention.

 

Don't forget, a foo-interop project could be a working group later, nothing would suggest otherwise. 

Yes, absolutely... I would fully expect that an interop-project would be merged into the Working Group under 3.0...

However  allow me please to be the devil's advocate here...

Here is a scenario that I think is quite likely to occur in FIG 3.0.

Assuming Editor A and Sponsor B dislike working with interop group member C... It would then be possible to eliminate C from the working group as A + B could block the entry [given the current version of the rules which I mentioned above as being a "political wall"], even if C has a very vested interest in the PSR and could conceivably be a very import member of it.

[Context psr-15] Regardless of which of the many approaches should be standardized, many of the most popular implementations were using approaches that were full of holes.

I would recommend that you accept it, and guide the community to making another PSR that betters the current one.... IE PSR-X that extends PSR-7.

Please understand that when the community has an existing implementation, changing that implementation has significant cost.

1) Businesses use our software

2) If the implementations change then we must fix them and issue new versions [usually major new versions]

3) The cost is real of changing these things... It can be measured in dollars.

Without keeping these things in mind, you are just simply going to lose developers that follow these standards....

[Magnus Nordlander]

Hi!
 

Here is a scenario that I think is quite likely to occur in FIG 3.0.

Assuming Editor A and Sponsor B dislike working with interop group member C... It would then be possible to eliminate C from the working group as A + B could block the entry [given the current version of the rules which I mentioned above as being a "political wall"], even if C has a very vested interest in the PSR and could conceivably be a very import member of it.

First of all, I would argue that this is not the case in FIG 3.0. Under that proposal, the core committee should be stepping in at the acceptance vote (if not sooner) and send the proposal back as it hasn't considered all the stakeholders.

Secondly, how would this be prevented in an interop group? Seeing as an interop group doesn't actually have any oversight, refusing to cooperate with someone could just as easily (I'd argue even more easily) happen there?

 

[Context psr-15] Regardless of which of the many approaches should be standardized, many of the most popular implementations were using approaches that were full of holes.

I would recommend that you accept it, and guide the community to making another PSR that betters the current one.... IE PSR-X that extends PSR-7.

Please understand that when the community has an existing implementation, changing that implementation has significant cost.

1) Businesses use our software

2) If the implementations change then we must fix them and issue new versions [usually major new versions]

3) The cost is real of changing these things... It can be measured in dollars.

Without keeping these things in mind, you are just simply going to lose developers that follow these standards....

So, instead of creating a new standard, let's call it PSR-N, you suggest first creating a PSR-N-prime, which basically is just the FIG rubber stamp on one of the existing, problematic implementations, and then create PSR-N as an extension (or perhaps a successor) of PSR-N-prime? (Please do correct me if I have misunderstood you)

While that makes it easy for one of the implementations to implement PSR-N-prime, how would it make it easier on anyone implementing PSR-N? Also, if PSR-N-prime is created with known problems, and people know that there is an upcoming PSR-N fixing these problems, why would anyone implement PSR-N-prime? Even if there isn't an upcoming PSR-N, any standard with known problems is going to face difficulty getting adopted, because other implementations won't want to introduce problems they haven't had before.

Best regards,
Magnus Nordlander

[Nate Abele]

In broad brushstrokes, I see how this could be understood to be superficially similar to the other FIG re-org proposal, but it's actually a major (and important, I think) philosophical departure: the final deliverable is an actual piece of software, rather than a spec for an actual piece of software. This moves FIG's organizational process to what I believe is the Platonic ideal for an organization of its type: one where a +1 vote is more like an 'intent to implement'.

This has a number of knock-on effects, including:

 - Interop group participants are more sensitive toward and naturally incentivized to develop around what existing projects are doing, and

 - ...are more likely to solicit meaningful, practical feedback and buy-in from the intended audience

Using code as the fundamental unit of organization also encourages something which often seems to be an afterthought: the opportunity to iterate on real, working examples.

In sum, I think this approach will help keep people focused on what matters, and the openness of the process allows FIG to capitalize on the efficiencies that make OS itself work so well.

Thank you all for indulging my musing. I yield the balance of my time. :-)

[Michael Cullum]

Hi all,

It's worth noting here an issue we just came across with container-interop, essentially the problem exists in the licensing in that we essentially need specs to be licensed to the FIG from the beginning otherwise we hit issues with copyright reassignment (we [secretaries] are currently working with the PSR-11 team behind the scenes to get this resolved).

https://github.com/php-fig/container/pull/4

--

Michael C

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/eae2fc8b-30ed-44ae-b8a4-9226d15d501c%40googlegroups.com.

[Keith Casey]

Why does FIG need to own it in this regard?

--

Michael C

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

[Alessandro Lai]

I think it's needed as owner of the license, even it's an open source one.

[Larry Garfield]

Disclaimer: IANAL TINLA, however I did work with the lawyers at the Software Freedom Law Center when setting up Drupal's copyright policies and procedures and currently serve on the Licensing Working Group.  So feel free to take with some salt, but not too much salt. :-)

It's not that FIG needs to own the code per se; strictly speaking there is no legal entity called FIG, so it cannot own copyright on anything.  However, bear in mind that under copyright law you own any non-trivial work you produce immediately upon doing so, and no one else has any legal right to copy it, much less use it, without your explicit consent (modulo fair use).

So work done on what will become code for a PSR is by default copyright its original owners and no one else is allowed to use it without their consent.

FIG has a standing policy that all code "we" produce is MIT licensed, and any prose/documentation is CC-BY 3.0:

http://www.php-fig.org/bylaws/licensing-policies/

Therefore, it's a much more defensible position to say that anyone working on a FIG-umbrella spec is explicitly releasing their work under MIT than in a random GitHub repository with no such published statement.  The alternative is to have to go through the rigmarole as seen in the last several comments of this thread:

https://github.com/php-fig/container/pull/4#issuecomment-242247526

(Basically, under the FIG umbrella those statements become implicit in participation and PRs in the first place.)

To be fair, the odds of this becoming a problem in practice are small.  However, I'd much rather err on the side of crossing our T's and dotting our I's where copyright law is concerned, just to be safe and minimize the chances of something becoming an issue in the future.

The more aggressive, defensible position would be for FIG to be a legal entity and have a Contributor License Agreement, but I'm fairly sure the latter is much farther than we want to go.

(This is your regular reminder that if you find a random GitHub repo that you want to use, but it has no license specified, *it is a felony for you to use it without the prior written consent of the author*.  I never said copyright law was good, but it is what it is.  Please license your code.)

--Larry Garfield

On 08/23/2016 08:24 AM, Keith Casey wrote:

[Keith Casey]

On Thursday, August 25, 2016 at 1:11:04 PM UTC-5, Larry Garfield wrote:

It's not that FIG needs to own the code per se; strictly speaking there is no legal entity called FIG, so it cannot own copyright on anything.

Then you're assigning copyright to an entity that have standing or process for determining who can represent it where and how? Sounds like that's a bigger problem to solve first.

 

However, bear in mind that under copyright law you own any non-trivial work you produce immediately upon doing so, and no one else has any legal right to copy it, much less use it, without your explicit consent (modulo fair use).

Adding a license - any license - governs the terms of contribution, usage, etc, which the MIT (or BSD or Apache) covers as is.

The "entity" only has to own the copyright if there's a need to relicense it or transfer ownership later and you don't want to contact all the contributors. Are you planning to transfer ownership?

* I ran a GPL->BSD relicense a few years back after forking a project: http://web2project.net/2011/01/web2project-license-change/ and worked through all the details with extensive legal and technical advise.

keith

[Paul Jones]

> On Aug 25, 2016, at 13:10, Larry Garfield <la...@garfieldtech.com> wrote:
>
> So work done on what will become code for a PSR is by default copyright its original owners and no one else is allowed to use it without their consent.
>
> FIG has a standing policy that all code "we" produce is MIT licensed, and any prose/documentation is CC-BY 3.0:
>
> http://www.php-fig.org/bylaws/licensing-policies/

It seems trivial, then, to say that any *-interop project to be considered by FIG needs to be licensed in that fashion before FIG can consider it.

[Larry Garfield]

It's not that we're transferring copyright ownership to FIG, as FIG isn't a legal entity.  It's that by working on it under the FIG umbrella, it's clearer that contributors are individually offering whatever they're doing under MIT, as opposed to something else or not at all.  There's no transfer of ownership, just a clarity about the license used by the individual contributors collectively.

--Larry Garfield

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/760607af-4fef-427f-afd7-6d17bd1d9e85%40googlegroups.com.

[FGM at GMail]

Chiming in on the "no legal entity". I'm not sure of which legal system is involved here and what its limitations are, but in french law, for instances, FIG would be an "association de fait" (de facto association), with limited legal capability, but existing nonetheless and able to act in some ways.

2016-08-26 15:52 GMT+02:00 Larry Garfield <la...@garfieldtech.com>:

It's not that we're transferring copyright ownership to FIG, as FIG isn't a legal entity.  It's that by working on it under the FIG umbrella, it's clearer that contributors are individually offering whatever they're doing under MIT, as opposed to something else or not at all.  There's no transfer of ownership, just a clarity about the license used by the individual contributors collectively.

--Larry Garfield

On 08/26/2016 08:47 AM, Keith Casey wrote:

On Thursday, August 25, 2016 at 1:11:04 PM UTC-5, Larry Garfield wrote:

It's not that FIG needs to own the code per se; strictly speaking there is no legal entity called FIG, so it cannot own copyright on anything.

Then you're assigning copyright to an entity that have standing or process for determining who can represent it where and how? Sounds like that's a bigger problem to solve first.

 

However, bear in mind that under copyright law you own any non-trivial work you produce immediately upon doing so, and no one else has any legal right to copy it, much less use it, without your explicit consent (modulo fair use).

Adding a license - any license - governs the terms of contribution, usage, etc, which the MIT (or BSD or Apache) covers as is.

The "entity" only has to own the copyright if there's a need to relicense it or transfer ownership later and you don't want to contact all the contributors. Are you planning to transfer ownership?

* I ran a GPL->BSD relicense a few years back after forking a project: http://web2project.net/2011/01/web2project-license-change/ and worked through all the details with extensive legal and technical advise.

keith

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/760607af-4fef-427f-afd7-6d17bd1d9e85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/7975ecaf-b65d-86c4-7ba5-9bac90ed3163%40garfieldtech.com.

[Matthieu Napoli]

Therefore, it's a much more defensible position to say that anyone working on a FIG-umbrella spec is explicitly releasing their work under MIT than in a random GitHub repository with no such published statement.  The alternative is to have to go through the rigmarole as seen in the last several comments of this thread:

https://github.com/php-fig/container/pull/4#issuecomment-242247526

Larry, there was still no actual explanation given as to why we had to change the original license which *was* MIT license.

I'm really uncomfortable with this whole thing, and the fact that people present that as "a problem" makes me even more uncomfortable.

[Keith Casey]

That's the key point.

The license is the license. As long as the license is acceptable - as MIT it was - ownership of the work is irrelevant.

Ownership is only relevant if you want to change the license.

Larry says that's not the intent, so it appears you're adding unnecessary work and potential complications for no reason.

keith

[David Négrier]

I wholeheartedly support Mathieu's and Keith's point of view.

The MIT license was applied to container-interop from the very start and the copyright notice was added according to the MIT license.

PSR-11 constitutes a derivative work based on container-interop and as such, modified work done by PHP-FIG should also by copyrighted (to the PHP-FIG group).

The fact that part of the copyright belongs to "container-interop" is a none issue unless FIG wants to change the license to something else than MIT (which is unlikely to happen).
Furthermore, since PSR-11 is a derivative work based on a MIT license project, container-interop cannot claim ownership of PSR-11 either.

So in my opinion the only thing we really need to do is to add a copyright notice for PHP-FIG in addition to the copyright notice of container-interop.

Also, the FIG bylaws do not indicate that the license should be copyrighted to PHP-FIG. It only dictates that it must be MIT (see https://github.com/php-fig/fig-standards/blob/master/bylaws/005-licensing-policies.md)
Finally, the whole idea of open-source is to be able to improve and extend the work of others. If each project forking another had to deal with copyright issues, open-source would be pointless.

++
David.