MIT License and/or W3C CLA and FSA
Closed this issue · 36 comments
Extracting conversation from #323 (review)
License
The group will use the MIT license for all its work items.
@elf-pavlik:
I looked at some other CG drafts and final reports and they mostly use
@csarven
Indeed to publish a W3C "Community Group Report" ( https://www.w3.org/community/about/process/ ). Works under solid/ use the MIT license, including the publications that are under https://solidproject.org/TR/ , and so far they have not been CG Reports. As I understand it, a CG Report document is not required in order to transition to a WG deliverable. I think the Solid CG can still publish CG Reports by simply creating snapshots of particular versions.
If we have consensus on publishing CG Reports in addition to versioned publications, we should distinguish them in the charter (and later in the contributing guide), and thereby clarifying the License and IPR.
@woutermont
Re the license: given that the only formal requirement seems to be that final reports of the CG fall under a W3C FSA license, is there any other advantage/incentive to switch all current MIT-licensed contributions to the W3C CLA?
@pchampin
if the goal is to publish a final report under W3C FSA, W3C CLA has the advantage of ensuring a smooth transition (especially about patents). AFAIK, there is no commitment regarding patents in the MIT license, so people may block the publication under W3C FSA by saying "wait a minute, I never signed up for that!".
@elf-pavlik
Maybe we could request guidance from someone at https://www.w3.org/staff/legal/ ?
@TallTed
+1
Pierre-Antoine asked me to comment:
The current charter says: "The group will use the MIT license for all its work items."
Looks like there was a decision made. As long as this decision is not revised, it makes no sense to discuss any further. This decision does not integrate well into the CG system IMHO.
Just for your information:
CLA and FSA have a meaning within a given and working system and legal framework. This framework was established after long discussions within the PSIG. The licenses have certain semantics. The MIT license has only few semantics that distinguishes it from the public domain: Do not use the name of MIT and MIT is not liable. Which doesn't look very meaningful in our context here, especially with respect to patent, trademark and copyright protection. If you want a tutorial on the meaning of all those licenses, we can organize a call once I'm back from vacation.
In preparation, it may be a better course of action to ask what the group wants and what the group does not want, a kind of real requirements discussion. I can then help to answer questions whether those requirements fit within the CLA and the FSA (my guess by a probability of 90% is that they do)
@rigow , thank you. To be clear, the proposed charter is using MIT license until we better understand the direction we'd like to take.
Quick background: We've been using the MIT license historically since this GitHub solid organisation originally used it for software, and later for early specification development predating the W3C Solid CG. We kept at it through the lifetime of the CG but now we're reviewing the material pertaining to the CG going forward. We also had an understanding that specifications are also code - although the notions was not codified in a document.
Do I understand correctly that CLA can cover all kinds of "Contributions to the Specifications" (as per https://www.w3.org/community/about/process/cla/ ), including software, e.g., test suite, or is that something separate, along the lines of https://www.w3.org/copyright/test-suite-license-2023/ or https://www.w3.org/Consortium/Legal/2008/03-bsd-license.html ?
To be clear (to everyone), any changes to the license would be applied to CG's work items, and not all repositories under the GitHub solid organisation.
If we do decide to use CLA/FSA in our specifications, do you have any recommendations / best practise to changing the current licensing from MIT to CLA/FSA? Would it suffice to PR the license change, wait for a reasonable amount of time, and go ahead with it if no objections?
My understanding is that only using W3C CLA/FLA (and any other W3C license for software) in the W3C Solid CG would suffice for our needs. Using MIT does not overly tie us to W3C in a way but I'm not sure if there are significant advantages to that in practise. After all, patent concerns with the MIT license aside, it is highly unlikely that our Web specifications would go through another standards body than the W3C. There may potentially be Internet specifications that can go to IETF or elsewhere - so then would this mean that when the CG accepts a "work item", the intention is to use W3C licenses and to potentially have them transition to a W3C REC under a WG? What if we later find out that something should've been passed on to IETF, would CLA/FLA pose any problems?
@timbl , ping!
Thanks for the person who brought this to my attention -- I was/am out of office. For me the MIT licence has been what we have insisted for all open source code for decades. The (mostly python) SWAP project, including cwm, in 2001 used MIT licence, and for me there is a continuum of code around sem web and linked data. Some of that code was translated (using pyjs) into Javascript to form the core or rdflib.js which is the core of lost of browser side stuff including webapps and SolidOS. I would like anything in the Solid ecosystem I am ever going to touch to be MIT licensed so I can mix it in. Yes, if specs have example code in them that must be MIT licensed too. This whole mass of code over the ages which anyone can dip into when they want to create another part of it has been really valuable.
It was important, by the way, when Inrupt Inc was started in this space -- and I imagine other companies -- that all the code around it was MIT licenced and so usable by commercial or non-commercial entities with impunity.
Please keep the Community Group using the MIT licence.
Thank you @rigow, Solid CG holds weekly meetings every Wednesday at 14:00 UTC. Would you see it possible to join one of those meetings for 30 min (or even a full hour) to help us understand nuances around licensing of:
- specifications
- code snippets included in examples
- test suites
- sample implementations
If that is possible we could try to plan this meeting at least a week or two ahead, publish the agenda and invite everyone with questions (especially questions not answered in this issue) to join.
Just to keep track of other inputs
- @CxRes pointed out https://www.w3.org/copyright/software-license-2023/ (to me it looks very similar to MIT)
- One of the Solid CG drafts received this PR solid/data-interoperability-panel#313 - some of my contributions were part of a project with NLnet and https://reuse.software/ is also involved with NGI0 the PR adds to the top of most files some metadata with copyright to the draft editors and relevant license.
To be clear, an ideal or preferred license for code in the Solid ecosystem is a separate discussion. This discussion focuses on setting a good path to help the mature Solid CG's Work Items advance to a WG.
CG's work items do not currently include software besides the test suite software to aid implementers in prototyping. Other types of software, including reference implementations, may become work items in the future. Implementations are separate works and aren't under the CG's authority. The CG cannot dictate the software license for implementations, just like a WG can't.
To distinguish between different types of work items, and also touch on the case of test suites, I suggest we could update the license section to the following.
The group will use W3C copyright licenses for all its work items except any software code artifacts, for which the group will use the MIT license. Concretely, this means that the group will use:
- the W3C Contributor License Agreement (CLA) for all its draft specifications;
- the W3C Final Specification Agreement (FSA) for all its final specifications;
- the W3C Document License for all its other public documents;
- a dual license combining the W3C Test Suite License with a 3-clause BSD license for all its authoritative test suites; and
- the MIT license for all its other software artifacts.
In particular, the group will NOT use the W3C Software License.
@timbl please note @csarven's comment above
To be clear, an ideal or preferred license for code in the Solid ecosystem is a separate discussion. This discussion focuses on setting a good path to help the mature Solid CG's Work Items advance to a WG.
There is a lot of software being developed by the participants (individuals and organizations) of Solid CG. All the code I write is open source and under the MIT license, but the Solid CG charter doesn't apply to any of that code. It is the same with the projects you mentioned, neither SolidOS nor rdflib.js are direct work items of Solid CG.
@woutermont I think we could add just one more sentence to what you are proposing:
The group strongly encourages its participants to use MIT license for all their implementations conforming to Solid specifications
Keeping in mind that each participant will make their final choice, similar to how mentioned Inrupt, which generously shares some code under MIT license, also chooses to keep other code proprietary (e.g. Enterprise Solid Server)
The group strongly encourages its participants to use MIT license for all their implementations conforming to Solid specifications
@elf-pavlik This specificity to MIT is not a good idea. I for example prefer MPL 2.0 and Apache 2.0 as these as written by legal experts and have patent specific clauses. Others may have a different preference. I would be OK with "OSI Approved" licences or similar.
My query was indeed for software generated as part of CG work items only, keeping in mind consistency with wider W3C practices. I think W3C Software License over MIT is the right choice here, but it is not a strong preference.
Hello all,
I would like to both throw in my opinion and request that we postpone this decision on the license and treat it separately from the Charter renewal discussions.
As @csarven has noted, we have been using the MIT License for everything since the beginning of the SolidProject, and it has not prevented or limited us from doing anything. Regardless of whether the W3C License is or is not more appropriate and brings us to parity with other groups, every individual and commercial entity in the ecosystem has made their contributions under the assumption that everything they have been working on is MIT licensed.
A license change after the fact is not something that should be taken lightly as it requires both legal and risk reviews. In this case, there are 5+ years worth of contributions, artifacts, derivative works, etc. that will need to be reviewed and assessed. We’re wading into potentially complex legal territory here.
To reference the quote from @pjchampin, "wait a minute, I never signed up for that!" We did sign up for the MIT license and many folks had legal reviews and risk assessments done day one. And everyone’s decisions up until this point have been based on that assumption. We did not sign up for the W3C license (yet) and if we’re changing those assumptions it’s going to involve significant legal review, risk review, content review, and due diligence.
If we’re not gaining anything significant by making the switch aside from parity, then I would recommend we avoid it altogether as it will be both time consuming and monetarily expensive to do properly. But if the group feels this is the right direction, then I would again request we decouple this from the Charter discussions and treat it as a standalone issue. I’d also request we postpone a decision here until everyone has had sufficient time to perform their legal review, risk review and due diligence so that we can make more informed decisions.
I say this as a representative of Inrupt inc. but I suspect many of the organizations involved in the Solid Project as well as individual contributors will have similar concerns with respect to the legal implications and change in the contract regarding their contributions.
Thanks.
@oolivo I do not want to contest or argue the complexity of issues involved. I think there is consensus with decoupling the license from the new CG charter to be updated this month.
Nevertheless, my question to you is: wouldn't the use of a new license (W3C licenses) apply only to new publications/works (including new updates to work done under MIT License, which MIT allows) and all the prior work would continue to remain licensed under MIT? So how will it affect anyone who contributed to the CG under MIT license as the change would not at all be retrospective? Contributers may decide if they wish to make new contributions or not going forward based on the new licenses (at most contributor may be asked to resign up). I am concerned here particularly as I intend to bring up new work items to the CG and want this issue to be addressed definitively before I do so!
Thanks @oolivo for so clearly and transparently representing Inrupts opinion on this matter 🙏
Note though, that your actual request ("that we postpone this decision on the license and treat it separately from the Charter renewal discussions") was already what we approved in last week's CG meeting: we will conclude the discussion on the charter next Tuesday (the 8th), with the option to discuss the license further until the end of August and then update the charter to our conclusion.
Regarding the license itself, it is also important to distinguish between the contributions to the CG work items (which, apart from the test suite and some example snippets in the technical reports do not include code), and other contributions within the ecosystem as a whole. This discussion only impacts the former; anything published (open source or not) by an organisation other than the CG is a matter for that organisation only.
License considerations in the Solid CG charter was introduced on 2023-07-04 and there has been five weekly calls since then (to date). As mentioned, we are in the last stretch for approval (2023-08-08) with the understanding that the considerations on licenses will be resolved and changes are incorporated into the charter by 2023-08-31. Charter is effective 2023-09-01.
Any CG participant that wishes to raise objections to license changes in the W3C Solid CG or to the forming of the W3C Solid WG with the deliverables taking on the W3C licenses are welcome to chime.
Unless the Solid CG can hire independent lawyers to consider the legal implications for 270+ participants representing 90+ organisations, I believe we are privileged to go with @rigow's (W3C's Legal Counsel) advisory. I suggest we continue responding directly to Rigo's "what the group wants and what the group does not want, a kind of real requirements discussion".
Participants have signed the agreement upon joining the Solid CG that is using a two-step patent commitment: CLA covering CG-DRAFTs, and voluntary FSA for CG-FINALs.
With the exception of some of the CG work items indicating copyright to W3C, the rest are copyright Solid CG with MIT license. The Solid CG work items that are listed as deliverables in the proposed Solid WG charter have copyright Solid CG and MIT license.
Rigo, it'd be great to have your response to the above two statements. Is the CG copyright meaningful? Are there any issues towards the publication of a FPWD or publications thereafter under a WG using W3C copyright/licenses/IPR?
Test suite software included in CG's work items use the MIT license, and its development will continue in the CG as well as potentially under the WG.
Rigo, would the CG and/or the WG requires to or can benefit from using the W3C licenses instead?
The proposed CG charter is explicit about its aim to avoid any conflicts with the requirements of the W3C CG/BG Process (so that it can play well with the W3C patent policy.) The CG's current specifications are not published as CG-DRAFTs/FINALs, but the CG should consider shifting towards making CG-DRAFT/FINAL publications and using W3C IPR (which facilitates transition to Recommendation track).
Can we consider adding to next week's agenda, a call for a special CG meeting with @rigow (at his convenience) to take up his offer to understand the CG needs, so that he has all the information to make a recommendation?
Very good point raised by @csarven! Indeed, everything that has been contributed to the CG already falls under W3C CLA.
Regarding software in particular, let me repeat that none of the TR repo's contain any actual code, except for the tests and test suite, which have to be converted to the W3C Test Suite licenses anyway, if we ever want to lift them to the WG as authoritative test suites for the spec. There is thus, once more, no actual code in the CG that could be licensed as MIT, and thus no code for which there would be an actual license change.
The only decision that rests us to make, is therefore under which license we would publish any possible future code. Two points on that:
-
I strongly believe the CG should publish its own code under the W3C Software License. It is basically the same as the MIT license, with the added explicit restriction that the licensee cannot use the W3C trademark in its advertisment/publicity. This makes a lot of sense i.m.o. to distinguish between official W3C software and any derivatived products that might try to seem W3C approved.
-
I do agree with @elf-pavlik and @CxRes that as a CG, we are in a good position to encourage open source developers in the ecosystem to publish their work under the MIT license or another OSI approved license. Again, all currently existing open source software in the ecosystem would fall under this encouragement, not under the CG's choice of license for its own work.
A license change after the fact is not something that should be taken lightly as it requires both legal and risk reviews. In this case, there are 5+ years worth of contributions, artifacts, derivative works, etc. that will need to be reviewed and assessed. We’re wading into potentially complex legal territory here.
@oolivo could you please share few specific examples of contributions, artifacts, and derivative works? Especially those which you think we should keep in mind and don't fit under any of the categories already explicitly mentioned in this issue.
I have been asked to respond to @csarven 's comment
To be clear, an ideal or preferred license for code in the Solid ecosystem is a separate discussion.
I feel this is wrong. The licence for the CG and the ecosystem are very related, as the CG is a part of the ecosystem. (Or, if it not part of the ecosystem - that's a bug!).
For example in a given application area,
- A dev finds finds an ontology
- They write an RDF UI form to make an app around that ontology
- They convert the form into a SHACL or SHEX shape
- The shape becomes the basis of a spec.
- They revise and publish the spec
Where does the CG begin and end?
- A developer has a project but need help with some of the solid bits
- They search the web for the problem
- They find documents which contain examples of what they need to do
- They cut and paste the example into their code.
Don't say "The CG won't really write code, only [insignificant] code snippets" - those snippets are so valuable for devs out there! The CG will have many different interfaces with other parts of the ecosystem.
It is all sort of simple.
Regardless of the MIT license's usefulness in the ecosystem, CG, WG, or the universe at large, W3C publications necessitate W3C licenses. The proposed WG charter specifies the use of the W3C Document and Software License for its deliverables. Do you think this might pose a concern for the ecosystem or present an issue?
W3C licenses are necessary for CG Reports. Moving work from a CG (or any other source) to a WG doesn't mandate CG Reports. While the Solid CG hasn't yet issued CG Reports, it has the option to do so if necessary. If W3C's legal team identifies no conflicts in accepting derivatives of MIT-licensed content for CG Reports or RECs, the transition from the CG to a WG can occur. The ease of this transition, the potential for objections or exclusions from contributors, additional work for the CG (or WG, or W3C), or something else, are some aspects we're striving to comprehend better to make informed choices.
The MIT license might generally be more favourable within the Solid ecosystem. While working within the W3C space, it's generally advisable to use W3C licenses, aside from their requirement for certain publications. It's possible to hold multiple perspectives simultaneously.
Disclaimer: IANAL 🙄 I don't have a vested interest in the license debate but understand various parties do for specific reasons. My focus is on facilitating smooth work processes and commitments.
@timbl, you give an example which i.m.o. fails to point out a problem with the W3C CLA. Can you elaborate on where something would go wrong?
The CLA explicitly permits the use of (parts of) the licensed work to be used in implementations, with as only demand the mere mention of the name of the spec.
Likewise, the W3C Software License permits any use of (part of) the code, requiring nothing but inclusion of the copyright notice and license, and barring the use of the W3C trademark in publicity of the derivative.
Just for clarity, these are the licenses contributed work automatically falls under because of CG/WG actions.
-
Participant contributes to CG
→ Automatically W3C CLA: fully permissive with attribution (45d opt-out). -
CG finalizes CG Report (e.g. for uptake in WG)
→ Optionally W3C FSA: fully permissive with attribution (commitment). -
WG publishes Report (on W3C website)
→ Automatically W3C Document License: permissive with attribution, modification limited to implementations. -
WG Report contains code snippets
→ Automatically W3C Software License: fully permissive with attribution and explicit prohibition of W3C trademark. -
WG publishes an authoritative test suite
→ Optionally W3C Test Suite Licenses: permissive with attribution, modifications cannot claim to be W3C tests.
There is no circumventing this. Saying everything in Solid should use the MIT license disregards this reality of how the W3C works. The only question we can ask is whether or not the CG already adopts the WG-level licenses, in particular the W3C Software License, to make transactions to the WG fluent.
Note that use of software code and code snippets is in no way limited by those licenses, as long as the code is attributed to the W3C, the license notice is included, and the W3C trademark is not falsely used. In the examples @timbl gave, the dev writing a shape around an ontology and contributing that to the spec does so under CLA, and when part of a Report the shape will fall under Software License. Everyone can using the shape for all purposes, as long as they include the notice and don't falsely claim to be W3C approved. Any dev finding such code snippets in the Report can thus simply copy-paste the code and the notice, no problem whatsoever.
@woutermont My example was to refute @csarven 's suggestion that licences for the CG and for the rest of the ecosystem are independent variables.
You suggest that the case of the CG being CLA and the app code being MIT should be fine. Yes writing that app would be fine - but the MIT licence does not guarantee W3C immunity (in that example) so the CLA allows you to use the code in an implementation but (very strictly) it does not give the right to re-licence that code as MIT.
And similarly in the other direction you can use that MIT code but not re-licence it as W3C.
So any world in which there are license boundaries between parts of the ecosystem becomes a pain.
It is inappropriate for us to consider this issue before the WG has been formed, as that group will have and represent a large stake in it. I'm closing this issue on that basis.
You suggest that the case of the CG being CLA and the app code being MIT should be fine. Yes writing that app would be fine - but the MIT licence does not guarantee W3C immunity (in that example) so the CLA allows you to use the code in implementation but (very strictly) it does not give the right to re-licence that code as MIT.
Can we clarify what specific code this reasoning applies to? Example snippets in the specs are usually pretty trivial, often not directly executable, and even if potentially executable never distributed in a way that would allow directly importing them (since no one would really want to do it in actual software).
I think the only executable code which the CG would govern could be found in test suites. Here I think that we should consider the possibility of sharing modules between test suites and conformant software. I'm not even sure if sharing code between test suites and implementations is desirable. Maybe @edwardsph and @michielbdejong can offer more insights for this specific case.
EDIT: We also have vocabularies/ontologies, JSON-LD contexts (/frames?), and shapes as a distinct group of artifacts that have to be licensed.
It is inappropriate for us to consider this issue before the WG has been formed, as that group will have and represent a large stake in it. I'm closing this issue on that basis.
The only thing that's inappropriate here is you closing the issue, @timbl. An eventual WG has no more say in the CG than any other participant, just like you in fact. The CG makes its decisions based on consensus.
Towards that consensus, I can only repeat that the W3C's copyright system is not optional when building a W3C standard, for a WG even less so than for a CG. And once more, this only applies to code snippets in the reports; if we choose to, we can keep publishing other code under the MIT license.
Btw, the 'pain' you feel license boundaries to be, is in fact nothing more than the mere effort of copying an extra notice, really the least of respect developers should have for writers whose code they reuse.
The only thing that's inappropriate here is you closing the issue, @timbl.
I concur. This issue has not been "completed".
There is an ongoing effort in a W3C CG to charter a W3C WG, and both of these groups have W3C-dictated licensing requirements, as you should recall, as former Director and now "Non-voting Board meeting participant" Founder Director. Those requirements have been enumerated above, but I have seen no acquiescent statement that they will (or even should) be complied with.
any world in which there are license boundaries between parts of the ecosystem becomes a pain.
Indeed. That is unfortunate, because there are license boundaries between parts of the current ecosystem. Apparently, this was not contemplated when this (and other) CG(s) was/were chartered, with WGs anticipated to be chartered at some point in the future of such CG charter(s).
It seems to me that W3C should dig into this, and issue new licensing recommendations if not requirements to CGs, such that future evolution from CG to WG does not incur such pain. Regardless of what W3C does going forward, we are where we are, and that does indeed involve some growing pains.
I think the only executable code which the CG would govern could be found in test suites. Here I think that we should consider the possibility of sharing modules between test suites and conformant software. I'm not even sure if sharing code between test suites and implementations is desirable. Maybe @edwardsph and @michielbdejong can offer more insights for this specific case.
In the case of the conformance-test-harness (& specification-tests), it deliberately makes no use of solid client libraries in order to avoid the potential of a mistake at one level being propagated to the tests. They are maintained independently.
I don't think that will pose a problem. We can keep the test software independently MIT licensed until the moment a WG might pick it up as an authoritative test suite and then license it under the W3C licenses.
@timbl ,
To the best of our understanding, it is not obligatory for works to hold an MIT license to be included in the Solid ecosystem. Within the Solid ecosystem, there are works with various copyright holders and licenses. If you believe that clarification or correction is needed such that the MIT license is required for works to be part of the Solid ecosystem, please make a public statement with your role as the Solid Project Director, and see to it that it is part of project's main communication.
Your input is appreciated for the following inquiry:
Regardless of the MIT license's usefulness in the ecosystem, CG, WG, or the universe at large, W3C publications necessitate W3C licenses. The proposed WG charter specifies the use of the W3C Document and Software License for its deliverables. Do you think this might pose a concern for the ecosystem or present an issue?
Furthermore, if you consider this to be a concern, please submit a PR against the Solid WG charter proposal to modify the licensing terms for the deliverables.
This issue was created by @elf-pavlik (CG participant) following CG's needed guidance from W3C. The request was met by @pchampin (W3C staff, CG participant) and @rigow (W3C legal counsel) to investigate the best approach for the CG.
The issue was closed by @timbl (W3C staff, CG participant) on the basis that the CG should not deliberate on licensing until the WG is formed.
It is inappropriate for CG participants to close an issue actively under the CG's consideration without the group's consent.
As per W3C Process, requirements for participation in all W3C activities are detailed in the Disclosure section of the W3C Patent Policy.
To give different perspectives the benefit of the doubt and to make an informed decision, I support the suggestion that the CG remains open to W3C's advice towards resolving this matter regarding the questions raised.
I (CG chair) am re-opening this issue on the basis that group's investigation is ongoing. Taking into account the input received, the investigation can more effectively integrate the best course of action(s) should the Solid WG is formed or in other scenarios.
Apologies for closing the issue "completed". That is what github labels it whenever you close it, you can't close it "postponed to September". And clearly the group wants to continue discussing it now. So I accept it is open.
First of all of course the whole Solid ecosystem will have code with all code in it is all kinds of licence. And much if it not open source. The boundary is with the CG work and other stuff in open source github. That's where a lot of stuff has the MIT licence and where NPM sucks in a lot of code when we build things.
@elf-pavlik You ask "Can we clarify what specific code this reasoning applies to? Example snippets in the specs are usually pretty trivial, often not directly executable,..."
I find I often cut and paste large chunks of text from web sources like Stack Overflow and the Mozilla Developer Network, MDN, like say MDN on CSS Grid. In that case I am protected pasting it into a MIT licensed document because the MDN code all has CC0 licence.
If you wish to contribute to MDN Web Docs, you agree that your documentation is available under the Attribution-ShareAlike license (or occasionally an alternative license already specified by the page you are editing) and that your code samples are available under Creative Commons CC-0 (a Public Domain dedication).
I hope stuff the CG produces will be as useful as the MDN stuff, and developer time will be saved by being able to cut and paste code examples. If in fact all code samples in CG stuff are explicitly CC0 that would do the trick. Then they could be pasted into W3C or MIT licensed documents.
Universal reuse was the reason why I insisted on ns/solid and ns/spec using CC0.
The current CG charter proposal incorporates - based on the input from this thread - the use of MIT and other OSI approved licenses as an encouragement for software conforming to Solid specifications. Perhaps this can be stronger about certain categories of documents or software. For instance, vocabs, JSON-LD context, data shapes, will have high reuse in the Solid ecosystem. They don't strictly fit under document or software, and so specifically calling out certain categories can be useful. Similar to the distinction we are making with the test suite software and other software.
On a related note, the WIP w3c/ns repository includes https://github.com/w3c/ns/blob/main/LICENSE.md :
All documents in this Repository are licensed by contributors under the W3C Software and Document License.
I don't know how that overarching license statement works alongside specific ns/ resources declaring their own licenses (like in ns/solid, ns/spec, and probably others) 🤷
There must be long deliberations on these matters at W3C =)
FWIW, the HTML specification includes the following IPR statement and perhaps we can introduce something to that effect in the charter (and Solid TRs.):
Copyright © WHATWG (Apple, Google, Mozilla, Microsoft). This work is licensed under a Creative Commons Attribution 4.0 International License. To the extent portions of it are incorporated into source code, such portions in the source code are licensed under the BSD 3-Clause License instead.
The CG charter could also distinguish between "published" artifacts (like the use of W3C licenses for CG-DRAFT/FINAL reports) from the information found in its work space (such as source code in GitHub discussions, chats/meetings, and elsewhere). The solid GitHub organisation makes that clear by stating the use MIT for its repositories.
What concerns me about the case-by-case approach to licensing is the potential complications that goes into communicating and verifying (when needed). "Document" and "software" are simple categories that's well worked out.
Thank you, @timbl, for the constructive response and elaborate clarification.
I find I often cut and paste large chunks of text from web sources like Stack Overflow and the Mozilla Developer Network, MDN.
As you say, MDN indeed publishes code snippets under CC0. This is a decision of MDN, not the contributors to the pages themselves. (To contrast, Stack Overflow content actually falls under CC-BY-SA, so simply copying and pasting is not allowed.)
Just like MDN and Stack Overflow, W3C has, for better or worse, made a licensing decision regarding code snippets, which, just as with MDN and Stack Overflow, authors cannot circumvent. That decision is that every code snippet in a W3C published document (which falls under the W3C Document License), falls under the W3C Software License.
As noted earlier, this only holds for WG documents published on the w3.org domain. Snippets in CG documents on solidproject.org can, in theory, remain MIT. I say "in theory", because I believe we all hope that our best drafts will ultimately enter the Recommendations Track (which entails being published as a W3C Document). Copying from earlier CG drafts will of course remain possible, but for WG drafts it will remain an issue.
If this is good enough for you, @timbl, then I believe the current licensing section of the CG charter is clear enough: "[T]he group licenses all its software artifacts under the MIT license ... [A]ll software artifacts that become part of a Working Group's Technical Reports will fall under the W3C Software License." We could possibly even include an explicit "including code snippets", if that would make people feel more comfortable.
If this is not good enough, however, I fail to see another legally possible middle ground, and propose that someone else comes up with an idea. (With eyes on the future, @timbl could, for example, set things in motion within the W3C to replace the W3C Software License with the MIT license.)
Other possible (I think - not a lawyer) middle ground: dual-licence. Assuming publishing on w3.org doesn't involve a copyright transfer, the copyright holders could just choose to apply both licences. Since an open source licence only gives additional rights, it's possible to give people all the rights granted in both licences. Unless the W3C stipulates that that's not allowed either.
It was important, by the way, when Inrupt Inc was started in this space -- and I imagine other companies -- that all the code around it was MIT licenced and so usable by commercial or non-commercial entities with impunity.
Please keep the Community Group using the MIT licence.
My apologies that I respond that late. I only saw it when cycling my mail backup. I'm an email person and communication going into a dozen web silos hasn't helped me remaining on top of all current expectations.
@timbl gave crystal clear requirements. I applaud them personally. My addition here is that those requirements can not only be achieved with the MIT License. This started as an initial question about compatibility. Now that I see Tim's requirement, I want to state:
1/ There is no issue with dual licensing here, because the CLA fulfills the requirements above, but adds patent commitments to the license. MIT license gives LESS rights (except to MIT) than the CLA, because it only touches on copyright, let alone the FSA. To pencil an MIT license onto the Specification in addition to the CLA thus does no harm AT ALL, if everyone commits to the patent rights in the CLA as well. If it contributes to end this discussion and re-establish peace and love. I would be all for it.
2/ Please make a clear distinction between the Specification, the code, the pseudo code and the test suite. We have well established and functioning licenses in W3C for all of them. They are all catering to the open world that Tim wants. For code, I'am personally a fan of the Apache license as it goes beyond copyright while still allowing for exactly what Tim wants: free mixing of code.
3/ For testsuites, open copyright does not make sense as everyone could manipulate the tests without the CG or WG having a scrutiny whether the test is correct and corresponds to the specification. Manipulating test cases would contribute to market distortion and to the make-up for false claims of conformity. This is why the W3C testsuite license leaves change control in the hands of the CG/WG, but allows for a wide range of uses, e.g. in software. In case of doubt, e.g. for internal testsuites in companies, W3C so far always gave licenses with the assumption that the W3C name or any relation to the W3C Specification is excluded.
I'm back from vacation next week and could join a call, if needed, to explain all that.
@rigow , thank you for chiming. Yes, we'd be glad to have you join us next Wednesday at 14:00 UTC ( https://meet.jit.si/solid-cg ). See also https://www.w3.org/events/meetings/a97faf55-e599-4fdd-b64b-32db74813e3b/20230906T140000/ .
@rigow , @timbl , may I ask you to review the current license section: https://github.com/solid/process/blob/7916591d1ffdc4cfae7cf2c8a11772c198ae7db0/solid-cg-charter.md#license and identify any issues, request for clarification or further discussion in the next meeting?
Resolved as per 2023-09-06 CG meeting decision.