Closed mlinksva closed 9 years ago
I'm quite sure the latest draft https://github.com/okfn/opendefinition/blob/master/source/open-definition-2.1-dev.markdown covers this fully and we can close this ticket.
You're right about the ambiguity being removed wrt GPL, but the latest draft language seems impossible to understand without looking up 'corresponding source' and reading its definition in the GPL (or being someone who has already done so many times):
"The license may require for any distribution of the work that corresponding source files be made available in the preferred form for modification."
I don't have a fix in mind, just noting that it isn't ideal at the moment.
I actually do not agree that 'corresponding source' is inadequate. I understand it is confusing in that it is a broad and slightly complex issue. There are various ways to figure this out. It's not GPL-specific language though. It would apply to something like hardware in that it would require the blueprints or something like that to be made available (although I'm not sure the OD applies to hardware in all respects).
If we really want more clarity here, something like:
"The license may require that any distribution of the work include or provide ready means of access to any corresponding source material in the preferred form for modification. Source refers to human-readable source code for executable computer programs, raw data used in the generation of charts or statistics, or other such material necessary for adapting the work."
That's a rough first try. I actually think it may be better to not try to be totally precise here. All we're doing is providing a qualification for licenses, and in this case, broader is probably better, but I worry about onerous issues. We don't want a license that says, "you can only distribute this along with a complete version of a particular operating system on which this runs…" or anything like that…
I dunno, I think we're already improved enough over 2.0 that we should just use the 2.1 draft in this case and consider it better and not fret about imperfection.
My complaint is not that the language is theoretically GPL-specific in application, rather it requires reading the GPL to understand.
One of the goals with 2.0 was to make it possible to understand without embedded explanatory comments and without having background knowledge about the OSD and its predecessors. I think 2.0 met that goal pretty well. I view this wording as a bit of a regression on that front, though the terminology of the GPL is the background knowledge required.
Embedding a definition of source doesn't help, as "corresponding" is the word that one needs to know the GPL to understand what is really meant.
But I don't have a bright idea for how to rewrite, so I'm going to close anyway. Anyone should feel free to reopen if they do have such an idea.
I didn't write "corresponding" in reference to GPL, fwiw. I just wrote it as a seemingly straightforward English word.
But I didn't understand the concern originally. I understand your point better now.
I think we could indeed go back toward the simpler 2.0 wording but still fix the issue at hand:
"The license may require that anyone distributing the work provide recipients with access to the preferred form for making modifications."
I'm tempted to add "…the work (whether modified or not)" or "…distributing any version of the work…" but don't like excessive words in that case.
Anyway, I now very much like my more generalized update here in this post and suggest we switch to that instead of my earlier GPL-sounding "corresponding" wording.
I misunderstood the role of "corresponding" perhaps. I thought you added it in order to clarify that the GPL's partiuclar requirement is OK wrt the OD. I agree that is not necessary as clearly what the GPL requires is just clarifying what the preferred form for making modifications actually entails, not a different requirement that needs an additional carve out in the OD.
So I like your more generalized update. Pull request?
OD 2.1 should remove this ambiguity. Brought up at https://lists.okfn.org/pipermail/okfn-discuss/2014-October/010652.html