On Tue, 2006-02-14 at 20:52 -0600, Patrick Barnes wrote: > The Fedora Documentation Project has agreed to the OPL[1] for all formal > documentation. We now wish to apply this same license to the > fedoraproject.org wiki. To be clear, and I'll wait for response before changing WikiLicenseTalk, the FDP is accountable for all Fedora content. Does this not cover the Wiki content already? Why the differentiation? 1. Work on the Wiki tools is obviously under a different license, so we need to be clear we mean Wiki content. 2. The OPL is a policy we need to set for all content that is copyright of the Foundation. The same content can be dual-licensed (or triple- licensed), it's just that the Foundation wants to use the OPL. This matters because of how we interact with other knowledge repositories. This weekend the Fedora Unity project is voting on using the OPL for their websites, and I'm going to be at that meeting to encourage that they do for interoperability. We have to consider this when approving additional Fedora websites as formal. The owners of that content are welcome to whatever license they prefer, but if they don't also put it under the OPL, we cannot intermingle with it. Shame for modularity and reduction of efforts. > This will require some dramatic actions and changes, > and will have a huge impact on contributions to the wiki. The single biggest > change would be the requirement of the CLA for EditGroup privileges. While I'm in favor [below for reason], I note that this is a sea change. Adding someone to the Wiki has gone from: 1. Add them to EditGroup 2. ??? 3. Profit to: 1. Get them started on admin.fedora. 2. Teach them about GPG. 3. Wait and watch 50% of them disappear. 4. ... We have benefited from very low barriers when it comes to the Wiki. The question is, is the barrier too low? Greg had suggested that we just put out on the sign-up page, this is OPL, like this has: http://directory.fedora.redhat.com/wiki/ContentLicense AIUI, that page is lawyer-dude approved. Without the CLA, the Foundation doesn't have any copyright on the materials, but if we create a mechanism that is a click-through agreement to use the OPL, aren't we covered for the future of that content? If they put it on the Wiki, it is OPL, so we can use it, and who cares about the copyright? Well, only if we want to relicense *again* someday, and, Lords and Ladies, I hope I am not around if that happens. [reason] Why am I in favor of the CLA for all contributors (code and content)? Because then we _never_have_to_do_this_again_. We are looking at having to pull out content from the Wiki from anyone who doesn't agree to the OPL. Just think about that. For the XML in CVS, which you have to have a CLA to get into, if someone doesn't agree, that's OK, Fedora can fork and relicense as a copyright holder. Right? Our job is to convince every single content contributor that this license changes is a Good Thing. And it really is. But you know how people are ... So: * We risk losing active contributors who don't like our tactics, no matter what they are. * We risk future contributors who don't want to get over the barrier. A question is: * What is fedoraproject.org? 1. End-user created documentation? 2. Project-member created documentation? If it is 2, then it has to have the same protections and guarantees as the rest of the code. Without the CLA in place, we cannot guarantee that the content we are providing is going to remain forever free/libre. > Rather > than make a closed and unilateral decision, this is now briefly open for > discussion. The currently-proposed plan is now on the wiki[2], and this wiki > page is the place to add your comments. You may subscribe to the page if you > wish to keep track of things. > > If the decision is made to go through with this plan (and, no, it isn't a > vote), To be clear, the OPL change to the Wiki is not what is up to vote. How we implement that change is up to discussion. Please help us make the right decision. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-marketing-list mailing list Fedora-marketing-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-marketing-list