Improve Intellectual Property Policy #513
Comments
|
@copiesofcopies @agitana we'd appreciate FINOS' input on this issue. |
kriswest
added
formal specification
project governance
and removed
formal specification
labels
|
HI @openfin-gavin - thanks for raising this. Looking at the Community Specification License, I can see that rather than being a FINOS-specific licence, it is a copy of the CSL from here: https://github.com/CommunitySpecification/1.0 This is a Linux Foundation initiative: Linux Foundation has been supporting standards development, with a significant number of patent-holding vendors involved in the process, for a number of years. I'm confident that they have considered the issue you have highlighted above. @scooter99boston @mindthegab what are your thoughts? Also, this is where FINOS should lean on Linux Foundation for support, this is one of the areas where FINOS stands to benefit from being part of a broader open source organisation. If you have concerns, I'd recommend engaging with LF and the team behind Community Specification. |
|
@ColinEberhardt This was discussed in detail with FINOS and Linux Foundation. They acknowledged that they don’t currently address these issues and encouraged us to take it up directly with the FDC3 community. @mindthegab can confirm. The current IP governance does not require the kind of disclosure that is required by W3C which is the body responsible for HTML5 and web standards. Additionally, the current governance allows working group participants to write down what is said during meetings and to file patents on that information. |
|
Chiming in since several FINOS Members have asked the LF to express LF's views on this. For context, I'm Andy Updegrove - author of the current FINOS IPR provisions in the IP policy and outside counsel to the LF. As requested, here is some input from the LF on IPR policies for standards development in general, and on the three points Mazy raises in particular.
That said, the negotiation that went on within W3C was a beginning and not an end of the process of IPR policy development and evolution. There are over 600 standards setting organizations (SSOs) in existence at any one time, and their IPR policies vary significantly. A major goal in all of these policies is balancing not only the rights of IPR owners with the rights of implementers, but also the balancing the burdens of IPR policy compliance with the benefits of creating safe standards. In the vast number of IPR policies, that balance is found by only requiring the disclosure of patent claims that would be unavoidably infringed (i.e., found in “standards essential patents”, or SEPS) by the implementation of a standard only when they will be withhold by their owners, or, in some SSOs, if the owner reserves the right to charge a royalty. This makes more sense because many of the most important companies an SSO hopes will assist in the development of a standard will have large patent portfolios - sometimes including tens of thousands of patents. Those same companies may participate in hundreds of standards organizations, and multiple, or even tens, of working groups within any individual SSO. Determining whether or not such a company owns any SEPs in thousands of working groups would be a Herculean task. I’ve written and negotiated many IPR policies for SSOs where some of the founders said they would refuse to join if the disclosure of SEPS beyond those being withheld was required. I should note that it is common for an SSO to have a “patent call” at the beginning of each working group meeting, but this is only a “soft” requirement for the individuals present to pipe up if they’re aware of their own personal knowledge, and not that of their employers, of a patent owned by anyone that might prove to be essential under the current draft of the standard under development. The reason the great majority of SSOs believe requiring disclosure of only withheld claims makes sense is that each member of the working group is required to extend a RAND license (in many SSOs, that license also has to be free); there’s not a lot of value to requiring that available SEPs be disclosed if its assumed that the working group will include the same technology either way. Indeed, there’s even a benefit to not imposing this requirement, since many companies make up their mind when they join a working group that they will make their patents available if they have them, and then don’t check to see if they have any SEPS under the standard under development. If they were required to, they might decide after the effort of reviewing their patent portfolio that they might as well require licenses now that they’ve gone to the trouble of finding them. In summary, only a very few SSOs require disclosure of SEPs unless a working group participant wants to withhold one, and a modest number require disclosure if the owner is willing to provide a RAND license but reserves the right to charge a royalty. So while FINOS could decide it would like to do otherwise, it should keep in mind that the prevailing wisdom is that the harm outweighs the good, and that there’s not much good anyway. Finally, it’s work keeping in mind that open source projects never require patent disclosures, even though the risk of patent infringement is just as real. At the end of the day, FINOS should make the same determination that other standards and open source communities do - in this case, whether the burden of making the disclosures would result in a big enough benefit to make the requirement worthwhile. As noted, SSOs rarely conclude that it does.
Finally, note that SEPs can be powerful tools to protect the community, just as those owned by the Open Inventions Network (OIN) help protect the open source community. SEPs owned by SSO members can be used to level the playing field when non-member vendors seek to extract unfair licensing fees from standards implementer. Where that happens, the member-SEP owners are freed from their licensing obligations, and can assert their SEPs against the third party and bring them to the bargaining table.
“9.8. Implementation. “Implementation” means making, using, selling, offering for sale, importing or distributing any implementation of the Specification 1) only to the extent it implements the Specification and 2) so long as all required portions of the Specification are implemented. This conforms to the terms of virtually all IPR policies for SSOs everywhere. The right to use a working group member’s SEPS is limited to the four corners of the spec, but how you go about implementing the spec is up to you. If it has just text describing functionalities, performance benchmarks and the like, then the implementer has to do all the design work. If the standard includes sample code, they’re free to use that or write their own. It’s completely normal for different implementations to be different - indeed, it’s unavoidable. But - the implementer needs to keep in mind that the license rights they’re operating under only apply to those portions of their resulting products that actually implement the standard, and those rights only bind if they have implemented all required portions of the standard. By way of summary, in making its decision, FINOS, like every other SSO, should figure out how to best balance the rights of IPR owners and users. SSO IPR policies have evolved over many decades, and as a rule, it’s a good idea to stay in the mainstream of those policies (just as almost everyone has come to adopt just a small handful of open source software licenses) so that prospective members will be willing to join FINOS, so that the marketplace will rapidly adopt FINOS standards, and so that other standards organizations will reference FINOS standards when they, along with FINOS, help build how a healthy and vibrant ecosystem for the benefit of FINOS members and users. Happy to answer any questions anyone may have. |
|
I believe it is best for the LF and FINOS legal and patent experts to advise on this, as @aupdegrove has done so eloquently above. To my untrained eye the FINOS IP Policy seems to provide adequate protection by automatically granting licenses on submission, and requiring immediate disclosure where someone aims to enforce patents. However, in the spirit of transparency and openness, I am not against strengthening this to always require patent disclosure. With regards to bad faith in terms of IP, I am not aware of anyone who is looking to file patents based on working group meetings, but it seems that would also be invalidated/protected by the above. Again, I am happy to defer to FINOS/LF legal here on best practices. Regarding “flavours” of FDC3, I don’t necessarily see it as an issue. Building on top of, alongside, or only partially on FDC3, as required, has always been part of its promise. However, I see a single, well-defined standard with clear compliance requirements, as having the best chance of cross-industry adoption and success. This is why the FDC3 maintainers are currently working with FINOS to review and formalise the standard documents for 2.0, which will also make it easier to validate compliance, and hopefully provide clarity on what is and isn’t covered by the FINOS IP Policy. |
|
Thank you to everyone who has provided comments so far. We suggest leaving this issue open until at least the next FDC3 Standard Working Group meeting on December 16th, 2021 to get additional input from the community (cc/ @finos/fdc3-maintainers). Unless further support is garnered for this proposal by then, we suggest that the Standard Working Group consider closing this issue at or after the December 16th meeting. @openfin-gavin if you would like to propose specific verbiage for the FINOS-wide version of the Community Specification License for future adoption, which can be socialized with FINOS Members beyond FDC3, feel free to raise a pull request to https://github.com/finos/standards-project-blueprint/blob/master/5._Governance.md |
|
@agitana I think this is a good idea, I would definitely be supportive of a PR with suggested changes to the CSL that tries to address any concerns. @aupdegrove what is your view on the ambiguities around whether implementations of FDC3 fall within the standard, and hence within the IP policy or not? I can understand the concern that software that implements or uses FDC3, but also enriches or expands it (or customises it for bespoke use cases), falls in a grey area in terms of the current IP policy (I am not even clear how we would determine what is covered by the standard or not at the moment...), and with patents and their scope not being disclosed, it may come as a total surprise to participants if they are suddenly accused of infringing a patent they didn't know existed. Then it becomes a legal argument about which part(s) of a particular adoption of FDC3 falls within the standard and IP policy, and which not. From that perspective, would it make sense for patents to be known, so that people could at least check whether they are in contravention of them or not? I would be in support of such a change to the policy if it makes FDC3 participants more comfortable, even if that part of the policy is only specific to FDC3, and not applied to other FINOS projects. |
|
@rikoe, I should start by saying that I'm not a developer (I don't even play one on TV), so I need to answer your question generically rather than in reference to this specific standard. That said, here we go. It sounds to me that if there's a problem, it lies not with the IPR Policy but with the standard itself. A standard should be written in such a way that it is clear what it covers (scope) and how (requirements). Think of it as the blueprint for the floor plan of a house. Anyone gains the necessary patent license rights it needs to build that house, and so long as the house matches the blueprint, it can use whatever materials it wants to build that house and otherwise be creative. But if it adds a bathroom or an attached garage, it's at risk with respect to those additions. A well-written standard should be as clear as the blueprint of a house, and it should be just as easy to look at an implementation and spot an extra bathroom if there is one. This may be a case of "says easy, does hard," but it is the basis upon which a century of standards development has been based. You're correct in saying that another way to solve the same problem - in part - would be to require every working group member to disclose every patent claim it believes would be unavoidably infringed by building our hypothetical house (a "Necessary Claim"). But standards organizations traditionally don't do this, because it puts extra burdens on patent owners to search their patent portfolios and disclose Necessary Claims that they might not want to assert at all (which is almost always the case in standards organizations that develop internet and web standards, for example). Note that this also wouldn't totally solve your problem. The same patent might read on that extra bathroom - but in fact the implementer would have no right to receive a license to build that bathroom, because it's outside of the standard. So an implementer couldn't actually benefit from the approach you're proposing to solve the problem you started with. In fact, it could provide a false sense of assurance and lead to possible litigation. What your question tells me is that perhaps the existing standard needs a re-look, and possibly revision to make it as clear as a building blueprint. |
|
What your question tells me is that perhaps the existing standard needs a
re-look, and possibly revision to make it as clear as a building blueprint.
Fortunately, that project is well underway:
https://github.com/finos/FDC3/issues?q=is%3Aissue+is%3Aopen+label%3A%22formal+specification%22
K
…On Fri, 10 Dec 2021 at 21:15, aupdegrove ***@***.***> wrote:
@rikoe <https://github.com/rikoe>, I should start by saying that I'm not
a developer (I don't even play one on TV), so I need to answer your
question generically rather than in reference to this specific standard.
That said, here we go.
It sounds to me that if there's a problem, it lies not with the IPR Policy
but with the standard itself. A standard should be written in such a way
that it is clear what it covers (scope) and how (requirements). Think of it
as the blueprint for the floor plan of a house. Anyone gains the necessary
patent license rights it needs to build that house, and so long as the
house matches the blueprint, it can use whatever materials it wants to
build that house and otherwise be creative. But if it adds a bathroom or an
attached garage, it's at risk with respect to those additions.
A well-written standard should be as clear as the blueprint of a house,
and it should be just as easy to look at an implementation and spot an
extra bathroom if there is one. This may be a case of "says easy, does
hard," but it is the basis upon which a century of standards development
has been based.
You're correct in saying that another way to solve the same problem - in
part - would be to require every working group member to disclose every
patent claim it believes would be unavoidably infringed by building our
hypothetical house (a "Necessary Claim"). But standards organizations
traditionally don't do this, because it puts extra burdens on patent owners
to search their patent portfolios and disclose Necessary Claims that they
might not want to assert at all (which is almost always the case in
standards organizations that develop internet and web standards, for
example).
Note that this also wouldn't totally solve your problem. The same patent
might read on that extra bathroom - but in fact the implementer would have
no right to receive a license to build that bathroom, because it's outside
of the standard. So an implementer couldn't actually benefit from the
approach you're proposing to solve the problem you started with. In fact,
it could provide a false sense of assurance and lead to possible litigation.
What your question tells me is that perhaps the existing standard needs a
re-look, and possibly revision to make it as clear as a building blueprint.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#513 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAM7PBDGD5VQWYHGGS7YWZLUQJUY3ANCNFSM5I2Y237A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
--
Kris West
Principal Engineer
[image: Cosaic]
+1 (800) 821-8147
***@***.***
Cosaic.io: <https://cosaic.io/> ChartIQ <http://cosaic.io/ChartIQ> +
Finsemble <http://cosaic.io/Finsemble>
|
@aupdegrove thanks for your response - this underlines an issue we have already identified, and is working to address with FINOS's assistance, as @kriswest also points out |
|
Thanks for the thoughtful feedback @aupdegrove. It is helpful to know what standards organizations do generally speaking. However, there is only one standards organization that governs the Web -- the foundational technology that FDC3 is built on. That standards organization is the W3C and it has active participation from Apple, Google, Intel, Microsoft and Samsung among others. The W3C has a disclosure policy which, as you point out above, was the product of lengthy deliberation. The policy can be found here: https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure Many of the concerns you raise above are related to a participant not being aware that their firm has a patent relevant to the subject of the working group. However, the W3C disclosure policy is clear that disclosure is only required if "[an] individual has actual knowledge of a patent which the individual believes contains Essential Claim(s)". This requirement protects all participants and addresses the valid concerns you raise. The issue we would like to see addressed is the case where a participant attends working group sessions and files patents on the work product of the working group. Surely we can all agree that this should not be how participants conduct themselves. In your comments on the "Bad Faith" issue, do you not feel it's bad faith for a participant to take work product developed jointly by the group and to claim that work product as their own invention? I'd like to understand which FINOS member is happy to attend meetings and share ideas collaboratively only to find that another participant has written down what they said and filed a patent on it. This kind of behavior is not just bad faith - it's illegal. When you apply for a patent in the US, you are required to sign and file an inventor’s declaration, confirming that you did indeed invent the subject matter claimed in your patent application. Finally, with respect to infringement gray area, the section of FINOS IP policy that you quoted illustrates the problem very clearly. 9.8. Implementation. “Implementation” means making, using, selling, offering for sale, importing or distributing any implementation of the Specification 1) only to the extent it implements the Specification and 2) so long as all required portions of the Specification are implemented. I'm fairly certain that the many banks, buy-side and vendors who are implementing the FDC3 standard aren't aware that they can be the target of a law suit for simply neglecting to implement all the required portions of the FDC3 standard. In fact, we've spoken to many customers and not one of them is aware of this legal risk they are taking by implementing FDC3. I must say I'm perplexed by FINOS and Linux Foundation's unwillingness to help address this problem that affects our entire industry. |
|
Thanks for your comments on what is clearly an issue of the utmost importance from OpenFin's perspective - it's not every day that we see CEOs chiming in into Github issues, kudos. While at this point I want to make sure I don't pollute the discussion amongst participants on the substance of the matter, I feel the need to chime on a couple of points on the role FINOS and LF play in this, i.e. a steward.
in one of two ways:
So I truly believe we have actually been more than "willing" to address your concerns, like we would for any Community contributor regardless of their Governing Board and Membership status, and we continue soliciting participants to provide feedback and come to a decision on this issue. And, while we provide recommendations and context when asked for it, it's important not to set expectation for FINOS or LF would put forward our sole interpretation in either direction.
is quite of an overstatement, when compared to the growth of adoption of and contribution to the standard in the last two years from financial institutions and vendors alike. In fact, as you know, when similar concerns have been raised by OpenFin via bi-lateral conversations with our Members and FINOS over the last two years, the feedback we received from our Governing Board, our Members (including several financial institutions) was that the current governance provides the right level of protection for ideation and implementation without stunting collaboration through being over prescriptive. Despite that we then went on to recommend you to open this issue to provide once more a transparent place to gather support for your proposals in the open. And with this issue open - and I know widely socialized - for almost three weeks, I still don't see the additional support that would raise this as an industry-wide issue. My read, and keep me honest here, is that participants instead seem to be gravitating towards relying on the existing IPR provisions in the IP policy (until they might adopt the CSL in the future) approved by the FINOS Board you once were part of, and strengthening its applicability by focusing instead on adapting 2.0 to have a more formal specification to remove gray areas and create the basis for a software conformance program any firm can use to validate their compliance to FDC3.
So while I think it's important for FDC3 participants to make an informed decision based on feedback on this issue (it's on the agenda on Thursday), nothing would be immediately effective short of amendments in the IP policy to be approved by the GB. I just wanted to clarify the process here to manage everyone's expectations. In the spirit of efficiency, I am left to wonder if a more future proof approach is to directly raise pull requests with proposed verbiage) on the FINOS wide CSL as @agitana recommended above, considering:
That might make more sense and then it would be up to the Governing Board to review and approve for use for all FINOS standard projects, and, if approved, then changes would flow in FDC3 if/when this group adopts the CSL. Thanks again everyone for your input here, it's great to see the Community passionately debating - it means we are doing something important for the industry. |
|
Responding to your question about what you see as a “gray area,” you seem to suggest that there is something unusual about the licensing requirement found in the current IPR Policy. In fact, restricting licensing obligations to products that implement all “Required Elements” of a standard is a very common feature of standards IPR Policies. As I’ve mentioned previously, the standards world has evolved its best practices over a long period of time, and during that process has reached a sense of what’s fair to IPR owners and implementers and what’s practical to implement. This process has involved over 1,000 standards organization and tens of thousands of working group over that period of time. With respect to some IPR policy requirements, there may be several alternative paths that a given market vertical might lean towards in comparison to others (e.g, royalty free required vs. royalties permitted). In the case of interoperability standards, this kind of term is particularly common, because the community of standards developers and implementers gets no benefit from a device that does not implement all sections that are necessary to achieve interoperability. Such a policy may therefore differentiate between required elements (the subset of the standard elements necessary to achieve interoperability) and optional elements (“nice to have” additional features). I can’t explain why the given people you asked were unaware of this term. Likely it’s because they’re engineers implementing the standard rather than engineers who participate in standards working groups. But I can assure you that the FINOS language is not only common, but completely unambiguous to those who participate in standards development. Here is a random sample of terms from the IPR policies of other standards organizations that include a similar term; I could easily find very many more: IMS Global Learning Consortium: Licensing obligation only applies to products that include all Required Elements:
PCI Security Standards Council: Licensing obligations apply only to Compliant Products: ” A product or service that implements all Required Elements of a Standard. For the avoidance of doubt, where more than one option for implementing a given Required Element is included in a Standard, implementation of any such option is regarded as implementation of such Required Element for purposes of the definition of Compliant Product.” [PCI Security Standards Council: https://www.pcisecuritystandards.org/ipr_policy ] OSGI Alliance: Licensing obligations apply only to Fully Compliant products "FULLY COMPLIANT" shall mean: (a) an implementation of a FINAL SPECIFICATION which supports or implements all of the portions of that FINAL SPECIFICATION defined as being "Required", or (b) an implementation of all portions of a FINAL SPECIFICATION required for a specific type of product or component thereof; in either case, such implementation shall be able to pass all applicable COMPLIANCE TESTS that are adopted by OSGi and licensed to the implementor for such FINAL SPECIFICATION. [Definitions, |
|
Statement from the FDC3 maintainers on handling this issue, given at Standards Working Group meeting #526:
|
|
As suggested by @mindthegab, there is now a pull request against the FINOS Standards Project Blueprint Governance document. finos/standards-project-blueprint#4 |
|
Many thanks @mazydar. Let us know when it's decided and we'll work on bringing any changes back into FDC3. On one specific point, I thought my lay-person's view might be helpful:
We've been trying to raise the standard of the various meeting's minutes to better document the work that happens verbally - input into those is always welcome (they are a lot of work to produce). That would provide evidence (with a timestamp) that that work/inventive step happened in the meeting. Also raising issues and more importantly PRs on the standard's repo does the same, and ensures that work is a contribution under the contributor license agreement, which, I hope, provides a further degree of protection. Hence, if something inventive does come out of a meeting, I'd get it into minutes and a contribution ASAP ensuring that it's immediately protected for all users of the standard. Also, most of what we do at FDC3 isn't particularly unique/patentable - rather its value is in the fact we all agree to do it the same way. I don't mean to re-open debate here - but thought it worth mentioning what we (FDC3) try to do from a process perspective that should (at least according to my understanding) prevent issues/behaviours of the type you mention. |
The FDC3 Working Group is currently considering whether to align with or adopt the FINOS Community Specification License (CSL) which provides new governance for IP issues among other things. Currently, IP issues for FDC3 are governed by the FINOS IP Policy.
There are a few critical problems with both policies that we believe should be addressed irrespective of whether the FDC3 Working Group adopts the CSL or not:
No Disclosure Requirement: The policies don’t require Working Group participants to disclose that they have filed a patent application relating to the work product of the Working Group. This is part of the governance for the World Wide Web Consortium (W3C).
No Bad Faith Deterrent: The policies don’t disallow Working Group participants from filing patents on the work product of the Working Group. Any participant is free to write down what is produced in Working Group meetings and file patents on the information.
Infringement Grey Area: The policies are unclear as to whether implementers of the FDC3 standard are protected from patents if they implement something similar to the specification, but not the specification exactly. Many banks, buy-side and vendors currently have “flavors” of FDC3 that do not fully conform to the specification.
These issues place all FDC3 implementers at risk and jeopardize the integrity of the FDC3 standard.
To address the first two issues, we propose the FDC3 Working Group adopt a policy that includes language similar to the following:
Patent Application Disclosure; Good Faith
An organization that employs (full or part time) or engages as a contractor any Working Group Participant or Observer will be considered a “Participating Organization.” Disclosure is required when a Participating Organization has knowledge of the inclusion of claims in a patent application and, either such claims were (i) developed based on, or (ii) include (in whole or in part), information from a Working Group document (including draft or final specifications) or discussions (“Working Group Claims”). The Participating Organization must disclose the existence of such pending patent applications upon the earlier of: (i) filing the application(s), or, (ii) when the claims are discussed or included in a Working Group document or discussion. Disclosure can be actioned by making a pull request or commit to the repository’s Notices.md file and including either:
Furthermore, Disclosure is required for unpublished, amended and/or added claims that have been allowed by relevant legal authorities and that are Working Group Claims.
All Participants and Observers must, as a condition to participating on the Working Group, deal with other Working Group Participants honestly, fairly and in good faith in all respects.
Violations by Participants, Observers or Participating Organizations of this section of the project governance will be considered and treated as violations of the Code of Conduct.
The text was updated successfully, but these errors were encountered: