Re: [OSM-legal-talk] ODbL implementation plan - extra phase proposal
Generally there should be less incompatible data every day, however there still some imports of non-copyrightable (PD, government licensed) that were uploaded by users who did not agree to CT. Because of this the incompatibility test would have to be re-run periodically. (and maybe if some problems with the script get reported). Editors being free to edit is the main purpose of this. Small scale deleting of incompatible data before edit makes re-mapping easier and prevents problems with broken relations and other connections that could be a burden in the database for years. What is hurting the community with regard to licence change is the uncertainty what data will be lost and if really as much as statistics suggest. If every editor has an easy way to make sure his edits remain undeleted, and that he can edit without risking that it is futile no harm will be done. As pointed out, if the armageddon is postponed, people stop caring (maybe not once they started), that was the point of API rejecting non-compliant edits. If the whole process of licence change takes so long, why should the last phase (presumably most important one) - fixing what has to be deleted - take so short. Lukáš Matějka (LM_1) 2012/1/31 Jonathan Harley : > On 30/01/12 23:41, LM_1 wrote: > ... > >> That said there are other ways to ensure the goal of this suggestion - >> seamless transition rather than deletions and angry/leaving >> contributors. >> >> One that comes to my mind and does not require any drastic changes >> would utilise filtering feature of JOSM (and required Potlatch to >> implement equivalent). Every night/week (depending on how demanding >> task it would be) each incompatible object would be tagged >> odbl=incompatible (server side). Editors would then make these objects >> non-editable/less visible... >> >> If API is not changed to serve the cleaned version of data, it would >> be good to have at least some editor-side tool to revert selected >> object to the clean state and then repair/edit it as it should be. >> >> In my original suggestion I said that this period (remapping what has >> to be deleted while still serving data under CC-BY-SA) should take a >> year or two - as long as needed till all the field in >> http://odbl.poole.ch/ show 99% or more. The time pressure is a false >> one, there has not really been any argument why it is important to >> change the licence fast. > > ... > > Non-CT-agreers can't make changes any more, right? So the tagging of objects > odbl=incompatible would only need to be done once; the number can never go > up, only down as editors replace those features. The tag would be visible in > editors without any change (but would make it easy for editors to highlight > those features and/or warn any user editing them) and it would make it > crystal clear to all of us which features would be removed for the ODbL > version when it arrives. That seems like a pretty good idea to me. > > We're coming up towards the 5 year mark on this so nobody can accuse us of > moving too fast. Personally I'm feeling demotivated knowing that lots of my > work is likely to be removed (although I've mapped other places from > scratch, most of my edits around here have been corrections and > improvements) and I haven't added anything for months. I know more clarity > about exactly what's going to happen to the map would help me. > > I know we're still hoping that some CT refusers will change their minds, but > I think we need a definitive decision at some point about exactly what is > going to be done to which features - and that point needs to be BEFORE the > license change is implemented - preferably well before. Tagging seems the > obvious way to communicate that. > > > Jonathan. > > -- > Dr Jonathan Harley : Managing Director : SpiffyMap Ltd > > m...@spiffymap.com Phone: 0845 313 8457 www.spiffymap.com > The Venture Centre, Sir William Lyons Road, Coventry CV4 7EZ, UK > > > > ___ > legal-talk mailing list > legal-talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] [OSM-talk] Critical Mass for license change-over
Hi Robert, On 31 January 2012 21:53, Robert Kaiser wrote: > andrzej zaborowski schrieb: > >> I'm not sure if I would have joined OSM in the first place if it had >> not used this wikipedia model at this time, same as I haven't >> contributed (more than bug reports) to FSF or Mozilla owned projects. > > > Interesting to see Mozilla mentioned here as clearly every contributor > retains his rights when contributing to Mozilla code and does not assign any > of his rights to anyone. Assignment of your rights requires a written agreement in some jurisdictions so there's no talk of that. Mozilla, Facebook, etc, as you say, require a grant of the right to sublicense and other rights. As a result individual contributors are no longer the end licensors as in most projects I know as free and as in OpenStreetMap today. Various reasons are being quoted for doing that and there are various reasons against it (see the last two years of this list's archives). > You're right when it comes to FSF though, they have > a strict copyright assignment policy, when you contribute code there, you > don't own it any more but the FSF does. > > Also note that under the OSM CTs, there is no copyright assignment per se, > there is only a sub-license agreement. You don't *give away* your copyright, > but you allow the OSMF to to *use* your copyrighted material and sub-license > it. Yes, of course, I think it is Mike DuPont who said "give away". But obviously we're talking about the grant of rights. Cheers ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] [OSM-talk] Critical Mass for license change-over
Mike Dupont schrieb: This is my understanding. all of my edits belong to me, they are my contributions that I then willingly share with others. This is exactly what the CTs say. You sign there that you own your edit and grant the OSMF to sub-license it if needed and under well-defined terms. IMHO it's a shame we only introduced such terms so late. When I started contributing, my understanding was that I was *giving my contributions to the project* which includes that the project can use it under share-alike-style terms and license them for use of anyone, but I always wondered why there was no agreement I needed to OK that said that in detail. (Of course, the OSMF is the legal representative of the project, as "the project" has no legal standing by itself at all.) Robert Kaiser ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] [OSM-talk] Critical Mass for license change-over
andrzej zaborowski schrieb: I'm not sure if I would have joined OSM in the first place if it had not used this wikipedia model at this time, same as I haven't contributed (more than bug reports) to FSF or Mozilla owned projects. Interesting to see Mozilla mentioned here as clearly every contributor retains his rights when contributing to Mozilla code and does not assign any of his rights to anyone. You're right when it comes to FSF though, they have a strict copyright assignment policy, when you contribute code there, you don't own it any more but the FSF does. Also note that under the OSM CTs, there is no copyright assignment per se, there is only a sub-license agreement. You don't *give away* your copyright, but you allow the OSMF to to *use* your copyrighted material and sub-license it. Robert Kaiser ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] The Copyright of Split Ways
On 30 January 2012 15:21, Richard Fairhurst wrote: > andrzej zaborowski wrote: >> (I thought it is i->i+j, at least in JOSM it was up to some point) > > It is. But it's very difficult to extract that with certainty from a > non-trivial changeset. Add enough splits, and you may find i->i+j+k+l. Then > add some merges and some deletes, and you possibly have [p+i]+j and [l+p] > and an odd isolated section of k. > > Probably the only case in which you can actually check whether the user was > splitting, or creating afresh but using some of the same (agreeing) nodes, > is if they were using Potlatch 1's live mode. And I don't think that's been > good practice for a while. ;) > >> In any case if a way is an arrangement of node references + some >> tags, then if inside some changeset an arrangement of nodes and/ >> or tags is reused, as in your example, then, even if the editor's >> "split" operation wasn't used to arrive at it, for practical purposes >> the effects is the same. > > Practical purposes, sure, but not IP purposes. If we're saying that there is > IP in the sweat-of-the-brow required to create those tags or that > arrangement of nodes, then we need to know whose brow was sweaty. As I understand, you're assuming that whether ways j+k were created from way i using a split operation is significant for IP purposes. I think it isn't, same as for practical purposes. Deleting a way and recreating it with the same tags and nodes inside a changeset shouldn't be treated as creating a new way, imho. The only thing that changed is the way Id. So I'd say you can get pretty good reliability of detecting splits, merges and copying tags from nodes to ways, my guess is below 1% error frequency. Whereas always assuming the object Id to represent the history of the object yields 100% error in those cases. Cheers ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] ODbL implementation plan - extra phase proposal
On 30/01/12 23:41, LM_1 wrote: ... That said there are other ways to ensure the goal of this suggestion - seamless transition rather than deletions and angry/leaving contributors. One that comes to my mind and does not require any drastic changes would utilise filtering feature of JOSM (and required Potlatch to implement equivalent). Every night/week (depending on how demanding task it would be) each incompatible object would be tagged odbl=incompatible (server side). Editors would then make these objects non-editable/less visible... If API is not changed to serve the cleaned version of data, it would be good to have at least some editor-side tool to revert selected object to the clean state and then repair/edit it as it should be. In my original suggestion I said that this period (remapping what has to be deleted while still serving data under CC-BY-SA) should take a year or two - as long as needed till all the field in http://odbl.poole.ch/ show 99% or more. The time pressure is a false one, there has not really been any argument why it is important to change the licence fast. ... Non-CT-agreers can't make changes any more, right? So the tagging of objects odbl=incompatible would only need to be done once; the number can never go up, only down as editors replace those features. The tag would be visible in editors without any change (but would make it easy for editors to highlight those features and/or warn any user editing them) and it would make it crystal clear to all of us which features would be removed for the ODbL version when it arrives. That seems like a pretty good idea to me. We're coming up towards the 5 year mark on this so nobody can accuse us of moving too fast. Personally I'm feeling demotivated knowing that lots of my work is likely to be removed (although I've mapped other places from scratch, most of my edits around here have been corrections and improvements) and I haven't added anything for months. I know more clarity about exactly what's going to happen to the map would help me. I know we're still hoping that some CT refusers will change their minds, but I think we need a definitive decision at some point about exactly what is going to be done to which features - and that point needs to be BEFORE the license change is implemented - preferably well before. Tagging seems the obvious way to communicate that. Jonathan. -- Dr Jonathan Harley :Managing Director: SpiffyMap Ltd m...@spiffymap.com Phone: 0845 313 8457 www.spiffymap.com The Venture Centre, Sir William Lyons Road, Coventry CV4 7EZ, UK ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
