Hi Simon, Thanks for your response. I enjoyed reading it (even if I largely disagree with the direction of your argument).
A have a few additional notes for you to consider as you work on your paper. > "As creating new terminology is a well-established tradition in disputes > surrounding the meaning of open source, one might suggest doing so here — > yet we believe instead that along with the democratisation of other openness > movements we are witnessing the evolution of a concept that is, all things > considered, relatively new." I understand this point, surely; however I would also suggest that "creating new terminology in a well-established tradition" is not really what you are doing. You are seeking to enter into a well-established tradition and re-define core concepts that practitioners have debated for decades, and for which they have developed a fairly specific working understanding. So I suppose (as a thought experiment) I would ask: Why not actually take the tack you describe and coin a new term for what you are advocating, rather than piggyback on a term with such a well-documented (and fraught, as you note) history? If this question sounds a bit defensive, I suppose that's because it is. Those of us who care deeply about open source (as a concept, as a political philosophy, as an economic model, etc.) tend to be hyper-aware of attempts to shift and erode its meaning in ways that co-opt, undercut, and occasionally undermine the principles on which it is built (e.g., what's "open" about OpenAI?). Some of us like to call it "open washing": the attempt to use the (again, as you note) definitionally slippery nature of "open" to advance versions of the concept that do not account for some of the values and principles open source practitioners advocate. So in response to this: > Like it or not, other movements are way more open regarding this openness > spectrum/degree of openness. I doubt it would be wise to carry over these > semantic conflicts emerging around the OSD into these other domains. I would simply emphasize that this is not _only_ a question of semantics. It is a question of semantics, for sure—a question of "what this thing means and doesn't mean"—but that meaning has real, effective, powerful consequences for how people are dis/empowered when they engage with the tools that shape their relationships to each other and the world. This is why the definition of open source matters so much to those of us who have invested years of our lives and careers in it. Just a technical note here: > Because the core of these notions is the availability of source file/code, > all of these terminologies are confusing and simply social constructs around > the OSD. Source available, based on the OSI view, is not really the absence > of ability to modify; it's restriction around it (unclear and undefined > notion[s] anyway). This is not technically correct; you are conflating two tenets of the OSD: necessity of the ability to modify (and distribute) and necessity of non-discrimination. For something to be open source, it must: expressly grant the right to modify and distribute derivative works (see criterion 3 of the OSD, *and* not restrict usage based on, e.g. "field of endeavor"—see criteria 5 and 6 of the OSD). > As "open source" is about source at first, the aim is to refocus the debate > on the availability of sources. I understand your aim here, but again I will (hopefully as gently as possible) suggest that this is not, in my view, a very productive move. It siphons key values from the current working definition of open source (ability to share modifications, restrictions on discrimination). See my notes above about the importance of retaining these dimensions of the definition. > And like with software, we see this similar pattern between the editable > format and its rendered/compiled/compressed one. Yes, this is true for sure. But it is a case of necessary and sufficient conditions. The availability of (editable) source code is a necessary condition for something to be considered open source, but that criterion alone it is not sufficient for meeting the definition. Open source is much more a legal and political designation (an issue of licensing and rights) than a technical one (the presence of source and binary), though of course it is both of these. > But what if sources are released without granting these rights, I'm not sure > what should be said and this ambiguity is intentional to allow these debates > to take shape. There is no ambiguity here with respect to the OSI and the OSD. If source code is released without the concomitant ability to modify and subsequently distribute those modifications, or with the provisions that would restrict how the software is used, then it is not open source. It is "source available" at best. I hope these notes are useful to your continued research. Bryan _______________________________________________ tos mailing list [email protected] https://lists.teachingopensource.org/mailman/listinfo/tos TOS website: http://teachingopensource.org/
