[Foundation-l] Dual-Licensing Wiktionary :fr ?

Gerard Meijssen gerard.meijssen at gmail.com
Wed Nov 15 18:50:12 UTC 2006

A copyright holder can license his content. This is why several Open 
Source projects insist that any the ownership of a contribution that is 
to be merged  into the core of that project is to be transferred to the 
organisation that maintains the project. This way they can provide both 
free and proprietary services based on the same code-base. The Wikimedia 
projects are not the same. It is possible to write a quality NPOV 
Wikipedia article in many ways, just compare articles in different 
Wikipedias and you will see what I mean. Wiktionary is very much more 
factual; the translation for child in Dutch is kind. The gender is 
neutral, the plural is kinderen. You cannot copyright this. The 
information in WiktionaryZ and Wiktionary is very much like this. It is 
very much the reason why WiktionaryZ could be developed in this way.

It is as you indicate, there are multiple copyrights involved. The 
MediaWiki is GPL. The database design is GPL. The database specific 
copyright is as indicated earlier with either with the Wikimedia 
Foundation or with the community of a Wiktionary project. It is not 
possible for a single person to lay claim to the whole of the collection.

The WiktionaryZ project is completely differently organised from the 
Wiktionary projects; one is relational the other flat file organised. 
When it comes to the data itself, for Wiktionary an article exists for 
each each expression spelled in a particular way. In WiktionaryZ there 
is a record for each occurrence of the expression per language. It is 
therefore impossible for WiktionaryZ to "infringe" on the license held 
by Wiktionary in all the ways that you specify for the "database 
specific copyright".


Jerome Banal wrote:
> Hello Gerard,
> Hmm, this is pretty adventurous, isn't it?
> GPL is not compatible with GFDL and a poll to change a license of current
> content is only valid if the license is entitled to the community as a
> collaborative work and not to contributors like in the case of Wikimedia
> projects. Otherwise, you should be only able to get edits made 100% by
> people who agreed (but I guess, you know all that already).
> Also, in some countries (France for example), there is a "database-specific
> copyright law" that may apply on dictionaries (a structured list of
> synonyms, translations and all being nothing more than a database for the
> law) and which basically forbids to copy a "substantial amount" -both in
> term of data fields and entries- of a database (if you read some French:
> http://www.murielle-cahen.com/p_base_de_donnees.asp).
> Thanks,
> Jerome Banal
> 2006/11/15, Gerard Meijssen <gerard.meijssen at gmail.com>:
>> Hoi,
>> Let me explain why WiktionaryZ allows for what are in effect two
>> licenses that are not compatible otherwise.
>> It is not possible to copyright facts. It is however possible to
>> copyright collections of facts. Every Wiktionary is a collection of
>> facts but there is no single person who owns this copyright. At best
>> there is a formal owner; the Wikimedia Foundation and there is a
>> practical owner that is its community. There are arguments about
>> definitions being copyrightable and there have been court cases about
>> this. It was typically found that there is often only one way of
>> defining certain things. This resulted in many dictionaries having bogus
>> information that only aims to "prove" that when found, the content of
>> their collection was illegally copied.
>> For WiktionaryZ we have defined success as: "When people find an
>> application for our data that we did not think about, that is success".
>> The consequence is that the data has to be available for inclusions in
>> applications. This means that we aim to provide the data in STANDARD
>> export formats. The data has to be identifiable to be in a recognised
>> language, a recognised script and a recognised orthography. There are
>> few practical standards for this. We went on a limb by choosing
>> ISO-639-3. This is the best currently available but this still does not
>> provide sufficient granularity. This may only arrive with the ISO-639-6.
>> When the data itself cannot be "protected" with licenses or copyright,
>> the question is what is it that we want from the copyright, the license.
>> What we want to make plane is that the data is available at WiktionaryZ
>> for any purposes and that we REALLY want people to help us complete
>> curate our data. This is what the CC-by allows us to do. It is possible
>> to include the data necessary to build OpenOffice (or any other) spell
>> checkers. These can be re-build every week. As long as the end-user
>> knows how and where to fix errors and omissions, we have the
>> functionality of our license. This is what mandatory attribution provides.
>> When a Wiktionary community wants to /cooperate /with WiktionaryZ, there
>> are several ways in which this can be done. We can have interwiki links
>> on the Wiktionaries articles to WiktionaryZ. When people want to use the
>> WZ content in Wiktionary they can. When a Wiktionary community wants to
>> /integrate /their data in WiktionaryZ integrally, they can vote on this.
>> >From the WZ point of view, if there is at least a 75% majority of the
>> active community in favour, it should provide enough clarity required to
>> investigate the integration of the data of that Wiktionary into
>> WiktionaryZ. In the past several large collections under other licenses
>> like the GPL have been integrated into the different Wiktionaries. The
>> copyright holders of these collections may find it in themselves to
>> grant WiktionaryZ this same privilege they gave to the Wiktionary
>> projects.
>> When people edit content in WiktionaryZ, these changes can be used under
>> a less Free license, you only need to attribute.
>> Thanks,
>>     GerardM
>> Jerome Banal wrote:
>>> Hello,
>>> We had a small chat at Wiktionary fr: since a few days about moving
>> /new/
>>> edits made on Wiktionary fr (and others some other are interested) to
>> dual
>>> licensing GFDL - CC-by. After a small discussion with Anthere about
>> whether
>>> we could be allowed to do it and how, she advised me to come and talk
>> with
>>> you all.
>>> So maybe a little explanation of the reasons and consequences would be
>>> useful.
>>> The main reason we have in mind for discussing it is to have a better
>>> cooperation with the project WiktionaryZ, which is dual-licensed as
>>> specified above. It basically means that we can take its content under
>>> license, but that they can take only contents that are under GFDL and
>> CC-by
>>> at the same time. Which is not our case.
>>> Some people thinks that helping WiktionaryZ reusing our content would
>> make
>>> them progress faster, and in return, that their progresses would help us
>>> making progress in the future in several possible ways (software part,
>> data
>>> part...).
>>> What would be the consequences about this license modification ?
>>> * A site license somewhat more complex. Edits prior to the date of
>> change
>>> would have to remain GFDL only (unless specific agreement with users),
>> new
>>> edits would be dual-licensed. This is not awful: people can still reuse
>> the
>>> whole Wiktionary as if it was GFDL-only. CC-by is just a bonus.
>>> * As this is not a CC-by-SA (incompatible with WiktionaryZ), Wiktionary
>>> content could be taken, possibly modified and redistributed under any
>>> compatible licence with CC-by, which is about all as long as you give
>>> attribution, including non-free licenses (but of course, the original
>>> remains free so it should not be a big deal).
>>> * Import from Wikipedia and other GFDL-only projects will not be
>> possible
>>> without prior agreement with past contributors. These imports are not
>>> insignificant but remain limited in amount and often in quality.
>>> * If we have to negotiate importing external source, we would have to
>>> request dual-licensing, as WiktionaryZ needs to, right now. CC-by is
>> more
>>> free (I know, it's paradoxical; see it as "there are less restrictions,
>>> including the one to keep derivative free") than GFDL so it may be more
>>> difficult, as it is possible that the original authors can't get the
>>> enhancements made by someone else back in their own work due to a
>> different
>>> license choice.
>>> So there are good points (better collaborative work with WiktionaryZ)
>> and
>>> bad points (probably more difficult reusing of some external sources
>> -like
>>> some other GFDL dictionaries- which brought a good amount of articles in
>> the
>>> past and of derivative works).
>>> OK, I think that's the picture. What do you think about it? Should
>>> Wiktionary users start a poll on their projects? On Meta? Or does that
>> just
>>> sound bad to you?
>>> Thanks all,
>>> Jerome Banal

More information about the foundation-l mailing list