--
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.
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
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.
Glenn: You seem a bit disgruntled here, maybe I could add some context as an observer of the FIG 3.0 conversations.
Don't forget, a foo-interop project could be a working group later, nothing would suggest otherwise.
[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.
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 software2) 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....
--
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.
--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.
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).
--
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.
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.
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