Bug#388141: Handling the copyright mess of the website
Hi, Le 04/01/2012 07:20, Charles Plessy a écrit : > Le Tue, Jan 03, 2012 at 02:56:48PM -0400, David Prévot a écrit : >> >> We could contact every current contributor, and ask them if they are OK to: >> - grant copyright of their future contributions to SPI; >> - grant copyright of their past contributions to SPI. Le 04/01/2012 07:20, Charles Plessy a écrit : > I think that the disclaimer to the FSF is not the same as a copyright > transfer, > and may be actually more appropriate as a starting point (or > http://unlicense.org/ ). Here is a draft of a text (more than) inspired by those examples, we could ask people to send it us back, signed with their public GPG key if possible (will ask for proofread on debian-legal before actually sending those request): I hereby acknowledge to Software in the Public Interest, Inc. non-profit organization of Indianapolis, United States,, that I disclaim all copyright interest in my works, which consist of edition or translation of portions of text from one human language to another human language, that I have provided to the Debian website or that I will provide in the future. To the best of my knowledge and belief, my contributions are either originally authored by me or are derived from prior works which I have verified are not subject to claims of copyright by other parties. To the best of my knowledge and belief, no individual, business, organization, government, or other entity has any copyright interest in my contributions, and I affirm that I will not make contributions that are otherwise encumbered. > Otherwise, if you chose copyright transfers (and associated objections, as in > my understanding, copyright transfer does not exist in some countries), I > think > that it would be fair to at least indicate if the license that is considered > will be copyleft or not. Of course, the message sent to current (and past) contributors should begin with something like: In order to relicense the website content with a DFSG compatible license, as documented in #238245, we'd like to gather all website contributions as copyright SPI, that will allow us to move away from the Open Publication License (to 2-clause-BSD-style or GPLv2 for example). Please refer to the discussions in #238245 and #388141 for the rationale of this request, and please participate if you want to help us in solving this long standing license issue. Le 04/01/2012 09:34, Tommi Vainikainen a écrit : > I believe that copyright transfers are wrong path. > […] Also, discussions > during many years in #388141 seems to indicate that not even all Debian > developers would be willing to assign copyright. Let's not focus on those who won't accept, and let's be glad if most of us will (and then, handle the specific cases one by one, hopefully, there won't be too much). We can still ask to those who didn't accept to assign copyright if they accept to change to a DFSG compliant license, and remove unsuitable content (if we have no response for example). > IMHO, your strategy works just fine if the request is instead only for a > license change. If the license chosen (well, #238245 is open since 10 May 2003, it would be nice if someone could try and provide a partial conclusion about what license would be our first choice) doesn't fit our needs in ten years, we'll be back at square one, harder actually, since we will have more difficulty to contact the older contributors, and because there will be (hopefully) more contributors in the mean time. > It can be a generic statement from authors such as any > future license change by Debian project leader decision or just giving > list of licenses as options. Will it be the Debian project leader or SPI, as soon as it is clear enough that Debian is able to use a DFSG free license (and change it if this license becomes incompatible with DFSG for example), I don't mind who is the copyright holder. > AFAIK, currently there isn't full list of all authors to > website. CVS knows. Le 04/01/2012 12:00, MJ Ray a écrit : > I will not assign copyright to [SPI] because I feel that > would make it more attractive to attackers. SPI already holds too > many assets for too long, in my opinion. Would you care to propose a more suitable copyright holder? > 2. I feel that forcing a choice between copyright assignment and being > airbrushed out of the website is rather at odds with the usual idea of > voluntary contributions to the project. If we don't ask people, we're stuck (as we are for many years), unless there is another nice solution we didn't yet think about. If a few persons prefer to refuse copyright assignment and prefer to forbid the rest of us to comply with our Social Contract, I don't see the point of allowing them to do that. > Nevertheless, I probably would grant DPLs (or suitable delegates) > permission to pick a dual licence for material on the website if > asked, so long as the previous licence(s) also held. I
Bug#388141: Handling the copyright mess of the website
David Prévot > If they refuse to grant copyright of their future contributions to SPI, > or if they don't respond, the first action would be to remove their > commit access, so starting at 2012, all the new content of the > website will be copyright SPI. That seems a bad situation in two ways: 1. even though I think SPI is A Good Thing, I will not assign copyright to it because I feel that would make it more attractive to attackers. SPI already holds too many assets for too long, in my opinion. 2. I feel that forcing a choice between copyright assignment and being airbrushed out of the website is rather at odds with the usual idea of voluntary contributions to the project. It seems like demanding a fee before work is considered on its merits for inclusion. Nevertheless, I probably would grant DPLs (or suitable delegates) permission to pick a dual licence for material on the website if asked, so long as the previous licence(s) also held. Hope that informs, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#388141: Handling the copyright mess of the website
David Prévot writes: > I don't know what would be the best approach for future contributors > (i.e. I don't know if we'll need to ask them explicitly for their > consent, or if a page on our website would be enough), but for current > and past contributors, we need their consent. > > We could contact every current contributor, and ask them if they are OK to: > - grant copyright of their future contributions to SPI; > - grant copyright of their past contributions to SPI. I believe that copyright transfers are wrong path. Neither other contributions to Debian project require copyright assignments and also there does not seem to be consensus that copyright could be even transferred without paper as in dead trees involved. Also, discussions during many years in #388141 seems to indicate that not even all Debian developers would be willing to assign copyright. IMHO, your strategy works just fine if the request is instead only for a license change. It can be a generic statement from authors such as any future license change by Debian project leader decision or just giving list of licenses as options. Anyway this work can be started with by writing this wml::debian::copyright tag, and start filling pages with that information about authors. After there is list of authors, it is also easier to request permissions to either license change or copyright assignment. AFAIK, currently there isn't full list of all authors to website. Together with author information per page, I think we should add e.g. copyright.txt to CVS root directory which contains information per author, which relicensing are fine, or possible copyright transfer to SPI. -- Tommi Vainikainen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#388141: Handling the copyright mess of the website
Le Tue, Jan 03, 2012 at 02:56:48PM -0400, David Prévot a écrit : > > We could contact every current contributor, and ask them if they are OK to: > - grant copyright of their future contributions to SPI; > - grant copyright of their past contributions to SPI. > … > > Unless someone objects on the principle, we'll start bugging > coordinators with this request. The DPN could give input about the > better approach to handle and draft these request, I don't know if we > need something as formal as the FSF does for translation [0], asking to > reply on the webmaster@d.o address might be enough (it will be archived > on master.d.o), the same way we ask new developers to agree with DMUP. > > 0: http://translationproject.org/html/whydisclaim.html Hello David, I think that the disclaimer to the FSF is not the same as a copyright transfer, and may be actually more appropriate as a starting point (or http://unlicense.org/ ). Otherwise, if you chose copyright transfers (and associated objections, as in my understanding, copyright transfer does not exist in some countries), I think that it would be fair to at least indicate if the license that is considered will be copyleft or not. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#388141: Handling the copyright mess of the website
On Tue, Jan 03, 2012 at 02:56:48PM -0400, David Prévot wrote: > Once the copyright granted to SPI, it will be a lot easier to address > the licensing issue, but I would prefer not to take care of everything > at once (given past experience, trying to do everything at once is > doomed to fail): this is a long standing issue that has seen no update > in years, and as stated, I'd be in favor to > - first: handle copyright for future contributions; > - second: handle copyright for past contributions; > - third: handle copyright exceptions that will allow us to relicense the > website content. FWIW, thumbs up. Thanks for devising and working on this plan, to you and the other -www folks. I confess it is hard for me to imagine the ratio of how many people will respond, in which time frame. Ultimately, I cannot imagine how many pages will be affected by the impossibility to relicense them. But those metrics will be of paramount importance to decide what to do in the end. One thing that could help with that is then monitor the various figures and their evolution overtime (yeah, I know, "patches welcome" :-)). Good luck with this challenging, but very important, topic! Cheers. -- Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o . Maître de conférences .. http://upsilon.cc/zack .. . . o Debian Project Leader... @zack on identi.ca ...o o o « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#388141: Handling the copyright mess of the website
Hi, Since this year began with the website being free of the old charset mess, I wonder if we could continue, and try to address as much as we can of the copyright/license mess, starting with the copyright. Talking on IRC with Rhonda and others, we came to the conclusion that even if we'll have trouble to handle the previous mess, nothing should stop us to address the future one. I don't know what would be the best approach for future contributors (i.e. I don't know if we'll need to ask them explicitly for their consent, or if a page on our website would be enough), but for current and past contributors, we need their consent. We could contact every current contributor, and ask them if they are OK to: - grant copyright of their future contributions to SPI; - grant copyright of their past contributions to SPI. If they refuse to grant copyright of their future contributions to SPI, or if they don't respond, the first action would be to remove their commit access, so starting at 2012, all the new content of the website will be copyright SPI. We'll then have to contact previous contributors (that don't have commit access anymore) and ask them to grant copyright of their previous contributions to SPI. Once the cleanup is done for future contribution, starting at , we can tag all previous pages that are not fully copyright SPI, using a tag that can be handled later with some WML magic, e.g.: #use wml::debian::copyright years="1997, 1999" holder="John Doe" #use wml::debian::copyright years="2007-2011" holder="Jane Doe" if John Doe edited the page in 1997 and 1999 and Jane Doe between 2007 and 2011, and those are the only editors of this page who didn't grant their copyright to SPI. We'll of course add this footer in translations too, and maybe some more lines will be needed there (if translators didn't grant their copyright to SPI). Translation coordinators will of course be of great help if they can handle their translated part of the website. Unless someone objects on the principle, we'll start bugging coordinators with this request. The DPN could give input about the better approach to handle and draft these request, I don't know if we need something as formal as the FSF does for translation [0], asking to reply on the webmaster@d.o address might be enough (it will be archived on master.d.o), the same way we ask new developers to agree with DMUP. 0: http://translationproject.org/html/whydisclaim.html Once the copyright granted to SPI, it will be a lot easier to address the licensing issue, but I would prefer not to take care of everything at once (given past experience, trying to do everything at once is doomed to fail): this is a long standing issue that has seen no update in years, and as stated, I'd be in favor to - first: handle copyright for future contributions; - second: handle copyright for past contributions; - third: handle copyright exceptions that will allow us to relicense the website content. Regards David signature.asc Description: OpenPGP digital signature