The on-wiki version of this newsletter can be found here: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-12-21
--
As planned, we are closing the licensing discussion. The decision, summarizing the will of the community, is as follows:
- All contributions to Wikifunctions and the wider Abstract Wikipedia projects will be published under free licenses. - Textual content on Wikifunctions will be published under CC BY-SA 3.0. - Function signatures and other structured content on Wikifunctions will be published under CC 0. - Code implementations in Wikifunctions will be published under the Apache 2 license. - Abstract Content for Abstract Wikipedia will be published under CC BY-SA 3.0.
We proposed a summary last week https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-12-16, and we heard your feedback. During Monday’s office hour, which was also used to officially close the discussion, we incorporated two more points of feedback:
- First, we will leave the question about the license of the generated content from the abstract content open for now. We will re-visit this question when we discuss the location of the abstract content for Abstract Wikipedia next year. - Second, we will write a document with the Legal department about how people can re-use code from Wikifunctions as painlessly as possible, while adhering to the license.
We also published the complete logs of Monday’s office hour https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/Office_hours_2021-12-20 .
We couldn’t really reach consensus on the questions (which probably had to be expected), so we followed the !votes and arguments raised. Thanks to everyone who participated in the discussion, thank you for the lively arguments, and thank you for working through the complicated situation. I want to particularly thank Stephen LaPorte https://meta.wikimedia.org/wiki/User:Slaporte_(WMF) for his support, and Quiddity https://meta.wikimedia.org/wiki/User:Quiddity_(WMF) for facilitating the work.
--
The team, together with a few volunteers, had the opportunity to reflect on our wishes and hopes for Wikifunctions in 2022. I wanted to use the chance of this year’s final newsletter to let you know about some of these hopes.
Our plan is to launch Wikifunctions in 2022. And our expectation is that in the first few weeks and months after launch we will discover many bugs and issues, and we will rely on your patience and help with those. We will switch from a team developing a product into a team maintaining and expanding a product, reacting to bug reports and issues. We will need to balance the issues of an on-going project with the need to develop new features beyond those with which we will launch.
One thing that was mentioned several times was that we look forward to being surprised. Surprised by the creativity of the community, and what they will do with this new project. We hope for a number of communities to grow around parts of Wikifunctions, and that Wikifunctions will be used in novel and unexpected ways.
Particularly high on our wishlist was the hope that smaller, underserved communities will find their way to Wikifunctions, and that Wikifunctions will be one way for achieving more balanced and representative communities within current Wikipedias and the Wikimedia movement as a whole. We hope that the functions in Wikifunctions will be requested and used by a great diversity of contributors and users, and that Wikifunctions will start contributing to knowledge equity in our world sooner rather than later. We hope to see the diversity of the world reflected in our usage, in our users, in our contributors, and in the depth and breadth of our catalog of functions.
We hope that Wikifunctions might have the opportunity to dispel the myth that “programming is really hard”. WIkifunctions will let people ask their questions and answer them using functions. But not just that: we will also expose and make transparent how these functions work. Everyone will be able to "peek behind the curtain" and see how the answers are being computed. This is not only meant as a way to build trust in the results of Wikifunctions, but also to show that these computations are not that complicated. By showing how functions are composed from simpler functions, and allowing people to read these compositions in their language, we hope to democratize access to functions and the knowledge of their inner workings, not just in Wikifunctions itself but in the computers that surround us all.
We hope to overcome in a timely fashion any challenges of technical scaling and our growing pains as we discover new use cases for Wikifunctions. We have a lot of ideas on how to grow and improve the system and the services that we will offer, and we hope that the usage patterns of Wikifunction and discussions will guide us in picking the most productive areas for improvement.
We hope to iterate and experiment with the Wikifunctions software, and over time discover and implement a good experience and a good conceptual model to make Wikifunctions widely usable for everyone. We hope that people will discover the low hanging fruit with which Wikifunctions can help them, and that we will quickly grow beyond that into the role of being an integral part of tomorrow’s knowledge infrastructure.
The first newsletter of 2022 should be expected in the week of 10 January 2022. Happy holidays, and a great start into the new year 2022!
Hoi, The data is cc-0 the functions are cc-0 but the generated text is licensed.. Great, so I take the data run, the functions and have the text anyway.. or is that too simple a thought? Thanks, Gerard
On Tue, 21 Dec 2021 at 23:27, Denny Vrandečić dvrandecic@wikimedia.org wrote:
The on-wiki version of this newsletter can be found here: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-12-21
--
As planned, we are closing the licensing discussion. The decision, summarizing the will of the community, is as follows:
- All contributions to Wikifunctions and the wider Abstract Wikipedia
projects will be published under free licenses.
- Textual content on Wikifunctions will be published under CC BY-SA
3.0.
- Function signatures and other structured content on Wikifunctions
will be published under CC 0.
- Code implementations in Wikifunctions will be published under the
Apache 2 license.
- Abstract Content for Abstract Wikipedia will be published under CC
BY-SA 3.0.
We proposed a summary last week https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-12-16, and we heard your feedback. During Monday’s office hour, which was also used to officially close the discussion, we incorporated two more points of feedback:
- First, we will leave the question about the license of the generated
content from the abstract content open for now. We will re-visit this question when we discuss the location of the abstract content for Abstract Wikipedia next year.
- Second, we will write a document with the Legal department about how
people can re-use code from Wikifunctions as painlessly as possible, while adhering to the license.
We also published the complete logs of Monday’s office hour https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/Office_hours_2021-12-20 .
We couldn’t really reach consensus on the questions (which probably had to be expected), so we followed the !votes and arguments raised. Thanks to everyone who participated in the discussion, thank you for the lively arguments, and thank you for working through the complicated situation. I want to particularly thank Stephen LaPorte https://meta.wikimedia.org/wiki/User:Slaporte_(WMF) for his support, and Quiddity https://meta.wikimedia.org/wiki/User:Quiddity_(WMF) for facilitating the work.
--
The team, together with a few volunteers, had the opportunity to reflect on our wishes and hopes for Wikifunctions in 2022. I wanted to use the chance of this year’s final newsletter to let you know about some of these hopes.
Our plan is to launch Wikifunctions in 2022. And our expectation is that in the first few weeks and months after launch we will discover many bugs and issues, and we will rely on your patience and help with those. We will switch from a team developing a product into a team maintaining and expanding a product, reacting to bug reports and issues. We will need to balance the issues of an on-going project with the need to develop new features beyond those with which we will launch.
One thing that was mentioned several times was that we look forward to being surprised. Surprised by the creativity of the community, and what they will do with this new project. We hope for a number of communities to grow around parts of Wikifunctions, and that Wikifunctions will be used in novel and unexpected ways.
Particularly high on our wishlist was the hope that smaller, underserved communities will find their way to Wikifunctions, and that Wikifunctions will be one way for achieving more balanced and representative communities within current Wikipedias and the Wikimedia movement as a whole. We hope that the functions in Wikifunctions will be requested and used by a great diversity of contributors and users, and that Wikifunctions will start contributing to knowledge equity in our world sooner rather than later. We hope to see the diversity of the world reflected in our usage, in our users, in our contributors, and in the depth and breadth of our catalog of functions.
We hope that Wikifunctions might have the opportunity to dispel the myth that “programming is really hard”. WIkifunctions will let people ask their questions and answer them using functions. But not just that: we will also expose and make transparent how these functions work. Everyone will be able to "peek behind the curtain" and see how the answers are being computed. This is not only meant as a way to build trust in the results of Wikifunctions, but also to show that these computations are not that complicated. By showing how functions are composed from simpler functions, and allowing people to read these compositions in their language, we hope to democratize access to functions and the knowledge of their inner workings, not just in Wikifunctions itself but in the computers that surround us all.
We hope to overcome in a timely fashion any challenges of technical scaling and our growing pains as we discover new use cases for Wikifunctions. We have a lot of ideas on how to grow and improve the system and the services that we will offer, and we hope that the usage patterns of Wikifunction and discussions will guide us in picking the most productive areas for improvement.
We hope to iterate and experiment with the Wikifunctions software, and over time discover and implement a good experience and a good conceptual model to make Wikifunctions widely usable for everyone. We hope that people will discover the low hanging fruit with which Wikifunctions can help them, and that we will quickly grow beyond that into the role of being an integral part of tomorrow’s knowledge infrastructure.
The first newsletter of 2022 should be expected in the week of 10 January 2022. Happy holidays, and a great start into the new year 2022! _______________________________________________ Abstract-Wikipedia mailing list -- abstract-wikipedia@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikimed...
Yes, that is (almost) correct.
The data on Wikidata is CC 0 licensed. The functions implemented in Wikifunctions are Apache licensed. But when I call a function from Wikifunction on data from Wikidata, there is nothing that makes the generated text be licensed under any particular license.
But then we also have Abstract Content, that is ideally represented by an ordered and hand-selected series of function calls and is potentially rather longish - dozens if not hundreds of such function calls. That Abstract Content is stored and published for Abstract Wikipedia under the CC BY-SA license. Running a function for text generation from Wikifunctons on that Abstract Content would generate a text that we'd consider to be published under CC BY-SA as well.
Sure, you could say "if I run these 50 functions in a row and then combine the results, none of the individual function calls causes copyright to kick in". But that's like saying "if I type these 500 keys in a row on my keyboard and then combine the results, none of the individual keystrokes causes copyright to kick in." If those letters happen to be in the same order as the letters in the first chapter of "The Midnight Library", you still may encounter copyright issues.
I hope this explanation helps.
Thanks for asking, Denny
On Wed, Dec 22, 2021 at 11:04 AM Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, The data is cc-0 the functions are cc-0 but the generated text is licensed.. Great, so I take the data run, the functions and have the text anyway.. or is that too simple a thought? Thanks, Gerard
On Tue, 21 Dec 2021 at 23:27, Denny Vrandečić dvrandecic@wikimedia.org wrote:
The on-wiki version of this newsletter can be found here: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-12-21
--
As planned, we are closing the licensing discussion. The decision, summarizing the will of the community, is as follows:
- All contributions to Wikifunctions and the wider Abstract Wikipedia
projects will be published under free licenses.
- Textual content on Wikifunctions will be published under CC BY-SA
3.0.
- Function signatures and other structured content on Wikifunctions
will be published under CC 0.
- Code implementations in Wikifunctions will be published under the
Apache 2 license.
- Abstract Content for Abstract Wikipedia will be published under CC
BY-SA 3.0.
We proposed a summary last week https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-12-16, and we heard your feedback. During Monday’s office hour, which was also used to officially close the discussion, we incorporated two more points of feedback:
- First, we will leave the question about the license of the
generated content from the abstract content open for now. We will re-visit this question when we discuss the location of the abstract content for Abstract Wikipedia next year.
- Second, we will write a document with the Legal department about
how people can re-use code from Wikifunctions as painlessly as possible, while adhering to the license.
We also published the complete logs of Monday’s office hour https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/Office_hours_2021-12-20 .
We couldn’t really reach consensus on the questions (which probably had to be expected), so we followed the !votes and arguments raised. Thanks to everyone who participated in the discussion, thank you for the lively arguments, and thank you for working through the complicated situation. I want to particularly thank Stephen LaPorte https://meta.wikimedia.org/wiki/User:Slaporte_(WMF) for his support, and Quiddity https://meta.wikimedia.org/wiki/User:Quiddity_(WMF) for facilitating the work.
--
The team, together with a few volunteers, had the opportunity to reflect on our wishes and hopes for Wikifunctions in 2022. I wanted to use the chance of this year’s final newsletter to let you know about some of these hopes.
Our plan is to launch Wikifunctions in 2022. And our expectation is that in the first few weeks and months after launch we will discover many bugs and issues, and we will rely on your patience and help with those. We will switch from a team developing a product into a team maintaining and expanding a product, reacting to bug reports and issues. We will need to balance the issues of an on-going project with the need to develop new features beyond those with which we will launch.
One thing that was mentioned several times was that we look forward to being surprised. Surprised by the creativity of the community, and what they will do with this new project. We hope for a number of communities to grow around parts of Wikifunctions, and that Wikifunctions will be used in novel and unexpected ways.
Particularly high on our wishlist was the hope that smaller, underserved communities will find their way to Wikifunctions, and that Wikifunctions will be one way for achieving more balanced and representative communities within current Wikipedias and the Wikimedia movement as a whole. We hope that the functions in Wikifunctions will be requested and used by a great diversity of contributors and users, and that Wikifunctions will start contributing to knowledge equity in our world sooner rather than later. We hope to see the diversity of the world reflected in our usage, in our users, in our contributors, and in the depth and breadth of our catalog of functions.
We hope that Wikifunctions might have the opportunity to dispel the myth that “programming is really hard”. WIkifunctions will let people ask their questions and answer them using functions. But not just that: we will also expose and make transparent how these functions work. Everyone will be able to "peek behind the curtain" and see how the answers are being computed. This is not only meant as a way to build trust in the results of Wikifunctions, but also to show that these computations are not that complicated. By showing how functions are composed from simpler functions, and allowing people to read these compositions in their language, we hope to democratize access to functions and the knowledge of their inner workings, not just in Wikifunctions itself but in the computers that surround us all.
We hope to overcome in a timely fashion any challenges of technical scaling and our growing pains as we discover new use cases for Wikifunctions. We have a lot of ideas on how to grow and improve the system and the services that we will offer, and we hope that the usage patterns of Wikifunction and discussions will guide us in picking the most productive areas for improvement.
We hope to iterate and experiment with the Wikifunctions software, and over time discover and implement a good experience and a good conceptual model to make Wikifunctions widely usable for everyone. We hope that people will discover the low hanging fruit with which Wikifunctions can help them, and that we will quickly grow beyond that into the role of being an integral part of tomorrow’s knowledge infrastructure.
The first newsletter of 2022 should be expected in the week of 10 January 2022. Happy holidays, and a great start into the new year 2022! _______________________________________________ Abstract-Wikipedia mailing list -- abstract-wikipedia@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikimed...
Abstract-Wikipedia mailing list -- abstract-wikipedia@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikimed...
Il giorno mer 22 dic 2021 alle ore 20:04 Gerard Meijssen gerard.meijssen@gmail.com ha scritto:
The data is cc-0 the functions are cc-0 but the generated text is licensed.. Great, so I take the data run, the functions and have the text anyway.. or is that too simple a thought?
Il giorno ven 24 dic 2021 alle ore 00:11 Denny Vrandečić dvrandecic@wikimedia.org ha scritto:
Yes, that is (almost) correct.
[...]
Sure, you could say "if I run these 50 functions in a row and then combine the results, none of the individual function calls causes copyright to kick in". But that's like saying "if I type these 500 keys in a row on my keyboard and then combine the results, none of the individual keystrokes causes copyright to kick in." If those letters happen to be in the same order as the letters in the first chapter of "The Midnight Library", you still may encounter copyright issues.
Exactly. Moreover, adding on what Denny said, the difference between CC0/Public domain and CC licenses is that the former is a status, the latter are proper licenses.
In other words, if something is in CC0 or public domain, there are NO obligations whatsoever - including the obligation of re-releasing under CC0/Public domain a derivative work based on those CC0/Public domain materials. If *you* want to release it under CC0/Public domain, it's fine - but you cannot do anything about those who want to include that material in a fully copyrighted derivative work.
So, using a CC BY-SA license on derivative texts will allow us to re-use them directly on Wikipedia (since the license is the same), and to keep them freely re-usable by anyone for their own purposes. Also, there is NO 100% certainty that combining something that is in PD will not cause copyright to kick in - see the founding principle of the infamous database copyright directive in the EU. With a free license, we shield ourselves also from this kind of risk.
It definitely is a limitation for those who want the output in public domain, but it's a necessary compromise to prevent someone in the future from doing anything that can harm the project.
L.
On Fri, Dec 24, 2021, 00:11 Denny Vrandečić dvrandecic@wikimedia.org wrote:
Running a function for text generation from Wikifunctons on that Abstract Content would generate a text that we'd consider to be published under CC BY-SA as well.
There is something in this that I find to be contrarian to the idea of copyright in the first place. (Copyright is needed in order to be able to license something CC BY-SA.) How can one get _copy_right for something one never wrote in the first place (and in many cases not even formulated as a sentence in your mind). Let me expand on the thoughts I shared in the office hours.
Take for example how many millions of articles about places in various languages could be formed. It could look something like this: The description of some Abstract content: *generates a sentence which ranks something compared to similar items in some location by some property*. It would then behave something like (over-simplified pseudocode):
rank(this,property(P1082),location(administrative unit(this)))
Depending on where it is used, it could generate:
- Stockholm ist die größte Stadt im Stockholms län. - San Francisco is the fourth largest city in California. - Gimo är den näst största tätorten i Östhammars kommun.
Not only is it inconceivable for someone to know of the phrasing of all the combinations this simple example can generate at the time the Abstract content is written, it will also be updated on Wikidata with new places added and new population data will change the ranking over time, changing the output of the function without the author being in control of it, and likely not even being aware of it. I find it a revolting suggestion that *copyright* could be attributed to the author of the Abstract content for this output.
This leads me to conclude that we either need to have the possibility to assign different licenses to the output of Abstract content or to make it all CC0 (in order to not committing copyfraud). As Denny implies, some Abstract content will be more static and "handwritten", but I suspect that for a foreseeable time that it will be in absolute minority in terms of generated output, so we can not ignore the situation we are putting ourselves in through the choices we make.
/Jan Ainali
abstract-wikipedia@lists.wikimedia.org