[od-discuss] OD 2.1 draft

Sat Jan 24 20:40:50 UTC 2015

I suggest we actually use the same wording throughout whenever appropriate. How about we use the same wording for 2.2.5 as for the new 2.2.6 wording? "The license may require that distributions of the work…"

I think there's a problem with the wording we missed earlier. The GPL requires source in preferred form, but source is an extra element alongside a binary in many cases.

I suggest a better new 2.2.5:

"The license may require that for any distributions of the work, corresponding source files in the preferred form for modification be made available."

If "any distributions" isn't explicit enough versus "copies and derivatives", then whichever is the preferred wording should be used consistently in the definition (for both 2.2.5 and 2.2.6 and anywhere else appropriate). My concern about "copies and derivatives" is that there's a distinction to be made between the act of distribution versus the status of a copy. The GPL does not apply to derivatives that are not distributed. My preference for the effect of the wording is that it isn't overly specific.

There's actually a very precise issue here regarding private derivatives. The Watcom license is approved by OSI but rejected by FSF. http://opensource.org/licenses/Watcom-1.0 — It says that *private* derivatives are not allowed. It requires that all modifications be published, even if made for only private use. We could think carefully about how we word these details in the OD 2.1 about this. Do we think that type of requirement is acceptable? Or do we think that licenses must allow people to make private modifications?

On 01/24/2015 10:44 AM, Herb Lainchbury wrote:
> For the record, and perhaps for those joining this thread, incorporating
> Mike's suggestion, there are now three proposed changes:
>
> 1. modify "1.3 - Open Format" to clarify and strengthen it.
>
> The main difference is the change from "or" to "and".
> See
> discussion: https://lists.okfn.org/pipermail/od-discuss/2014-November/thread.html
>
> I also incorporated a simplified version of the text I suggested
> here: https://lists.okfn.org/pipermail/od-discuss/2014-November/001129.html
> The simplification is removing the requirement for a published
> specification.
>
> The suggestion for bulk data remains as a suggestion.
>
>
> 2. modify "2.2.6 - Technical Restriction Prohibition" for clarity.
> See
> discussion: https://lists.okfn.org/pipermail/od-discuss/2014-December/thread.html#1178
>
> I have incorporated what I think is the best revision of 2.2.6 so far,
> as provided by Aaron:
> https://lists.okfn.org/pipermail/od-discuss/2014-December/001194.html
>
>
> 3.  modify 2.2.5 to allow source requirement for copies
> See
> discussion: https://lists.okfn.org/pipermail/okfn-discuss/2014-October/010652.html
>
> and
> diff: https://github.com/okfn/opendefinition/commit/6ee94fe4dff1a674347edcffd5e43bae37e6150e#diff-43c1b84a0e962cadb0bc57de43de4d23
>
> Thanks,
> Herb
>
> On Sat, Jan 17, 2015 at 5:06 AM, Peter Murray-Rust <pm286 at cam.ac.uk
> <mailto:pm286 at cam.ac.uk>> wrote:
>
>     I've spent 25 years hacking proprietary formats and have mixed
>     feelings. A large number of formats have implicit semantics and
>     these are provided by the processing proprietary software. A common
>     and notorious example is units of measurement - pounds? what sort ?
>     country codes? etc.
>
>     If you can't convert and roundtrip reliably then the closed format
>     is bound (often not clearly) to the proprietary processing software.
>     Often the proprietary documentation is closed or, more frequently,
>     insufficient (even to customers). I have found vendors who offer
>     "Open APIs" only to discover that this means they make their docs
>     available to customers but under a secrecy agreement. So "Open"
>     means "Documented", not OKD-compliant.
>
>     In compsci things are not too bad. Apache and other create toools
>     that read proprietary formats such as Word and PDF (yes I know they
>     are now "Open Standards" but they often are diffiuclt to read - I
>     work daily with Apache PDFBox and there are many PDFs that can only
>     be read with Acrobat).
>
>     It's much worse outside general computing - scientific instruments
>     and medical devices can be unreadable.
>
>     So, as I write this I have changed my view to argue against this. An
>     Open Data document should ideally have an Open community process for
>     its definition and documentation and at least one Open tool for
>     reading it.
>
>     Can a Powerpoint or XLS  be Open? I don't know because I haven't
>     started to hack with the Apache Tools. Word documents are just about
>     OK - I've worked with DOCX and with Microsoft and know how
>     MS-specific they are but at least there are Open tools.
>
>     So for me data in proprietary format is not Open unless there are
>     open tools and open documentation.
>
>
>     On Fri, Jan 16, 2015 at 10:34 PM, Andrew Katz
>     <Andrew.Katz at moorcrofts.com <mailto:Andrew.Katz at moorcrofts.com>> wrote:
>
>         Hi Aaron
>
>
>         > On 16 Jan 2015, at 17:35, Aaron Wolf <wolftune at riseup.net <mailto:wolftune at riseup.net>> wrote:
>         >
>         > I'm sympathetic to the idea that there is value in acknowledging when data is Open even when delivered in a non-Open format which is at least openable… but on the other hand, it's probably best to go all the way and require Open formats because we can simply say things like "the data from this city's government is almost fully Open but for the format, however, we have taken the data and re-released it in an Open format, so now it is fully Open!
>
>         Spot on. I agree entirely. I retain a little concern that the
>         proprietary format might contain additional information which is
>         not easily translatable, or accessible, into a truly open
>         format, but, in general, if I can get the information I’m
>         looking for in an .xls file, so long as I can easily export it
>         into .csv (for example) and lawfully redistribute it in that
>         format, I’m happy.
>
>
>
>         >
>         > So, as long as we acknowledge that it is possible for non-Open data to be Openable (because the license is permissive enough to allow that), then I'm satisfied. Perhaps we should do something aside from the Open Definition to at least acknowledge this, even though it risks accepting a level of laziness from publishers… I think this sort of grey-area is *good* to acknowledge. It's just reality that there's grey, not everything is completely black and white.
>         >
>         Yep.
>
>
>         > Happy to hear thoughts from others.
>
>         > Cheers,
>         > Aaron
>         >
>         Best
>
>         Andrew
>         _______________________________________________
>         od-discuss mailing list
>         od-discuss at lists.okfn.org <mailto:od-discuss at lists.okfn.org>
>         https://lists.okfn.org/mailman/listinfo/od-discuss
>         Unsubscribe: https://lists.okfn.org/mailman/options/od-discuss
>
>
>
>
>     --
>     Peter Murray-Rust
>     Reader in Molecular Informatics
>     Unilever Centre, Dep. Of Chemistry
>     University of Cambridge
>     CB2 1EW, UK
>     +44-1223-763069 <tel:%2B44-1223-763069>
>
>     _______________________________________________
>     od-discuss mailing list
>     od-discuss at lists.okfn.org <mailto:od-discuss at lists.okfn.org>
>     https://lists.okfn.org/mailman/listinfo/od-discuss
>     Unsubscribe: https://lists.okfn.org/mailman/options/od-discuss
>
>
>
>
>
>
> _______________________________________________
> od-discuss mailing list
> od-discuss at lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/od-discuss
> Unsubscribe: https://lists.okfn.org/mailman/options/od-discuss
>