Four Freedoms... and a right?

Open Source Definition
1

Hi all,

I’ve been involved in various discussions about how the current state of FLOSS isn’t quite what folk wanted a few decades ago. On the one hand, it’s ubiquitous. On the other hand, there is a lot more corporate extraction from the commons than anyone imagined, while it stays difficult to be a maintainer.

The general understanding that something needs fixing seems to exist, but as yet there is no consensus on how.

For my own part, I wrote this a while back: In Search of Foundational FLOSS Freedom(s)

The TL;DR is that we need an amendment to the OSD that effectively encodes that participants have the right to support from each other, from which then follows the requirement to give that support. When encoded in a license or contract, it should provide for a healthier, more sustainable ecosystem.

I see this a conversation happening in a lot of places. I think that going back to the OSD and refining that should be the start of any concrete movement of change. So this is me bringing that conversation here!

Thoughts, discussions, all very welcome!

1 Like
2

I’ve been thinking a lot about this topic recently, though not nearly as much as you have obviously as my ideas on it are nascent, triggered recently by interactions with OSD author Bruce Perens and his Post-Open proposal (What comes after open source? Bruce Perens is working on it).

My general feeling is that while there are some errata (like modernising the term programmer as practitioner, and dealing with the subjective term “preferred form”), fundamental changes like @giacomo’s minimalist amendment to cover data for completeness do not in fact expand the scope of Open Source, rather merely update it to reflect the nature of modern software (e.g., media, databases, and more recently, AI models).

I think there would need to be a very high bar set for any changes that fundamentally altered the meaning of Open Source. If I understand well, such a change would invalidate most/all of the 96 currently approved licenses. As would others like it, for example requiring patent grants. The data proposal on the other hand may force existing projects out of compliance if they ship with proprietary data, but would not conflict with the licenses themselves.

Have you considered creating a license that implements the right to receive (and obligation to give) support to participants, and whether that would comply with the current Open Source Definition? I suspect it would not, but I’m not sure what specific clauses would be problematic and that may depend on the implementation itself. We could then consider whether the OSD should be updated to cater for such license/s, and the implications and unintended consequences of same.

1 Like
3

I have considered such a license, but rejected that avenue after a while. It turns out that eventually you run afoul of the OSD’s letter (less so the spirit, at least as some would interpret that).

Part of the issue lies in a similar direction as Perens and his Post-Open proposal, in that it invariably exceeds copyright law, and so licensing terms, and instead becomes a contract. What I strongly dislike about the Post-Open proposal is less that, and more the specifics of the contract template he proposes (TL;DR). Also, contracts violate #7 of the OSD.

In terms of OSD violation, any obligation immediately violates #5 - or at least that can be argued. If one makes participation contingent on giving back, it’s a clear violation. If one defines giving back as “according to their ability”, which is the approach I am taking, it’s a lot better in this regard.

But a particularly aggressive reading of #5 could convince one party that giving back is possible and the other that it is not, and have them argue over whether this point is violated. You can avoid this via a contract (which in turn violates #7).

So first, implementing this in an OSD compatible fashion is not possible. Implementing it in a different way would look very much more like the Post-Open construct, except I’d favour more of a framework with configurable parts similar to CC licensing.

One specific concern is that #6 turns out not to serve humanity as well as it should. Not restricting fields of endeavour per se is IMHO the right approach for a framework, but for an individual agreement, it is not.

Take the following kind of scenario, which we have seen play out:

  • A creates an innocuous piece of software
  • B uses that software to violate the rights of C. Legally, this may be possible because B’s legislation permits such violations, even if C’s does not.
  • For simplicity’s sake, assume A and C share legislation or have compatible legal backgrounds.
  • You now have a situation in which C must receive protection, and A would have to give it, but because of B’s outside-of-the-local-legislation status, neither has recourse to addressing the issue.

My suspicion is that #6 exists primarily to keep licenses simple. But if we have to move from licenses to contracts anyway, then a) a framework with optional elements is the best form of reducing complexity, and b) this kind of consideration is no longer central.

This path has led me down to precisely what I started out with, that rather than focus on licenses first, or maybe the OSD as it stands first, we should likely revisit the foundational ideals first. An adjustment of the OSD should likely happen in parallel to an effort to create such a contractual framework, for much the same reasons you raise. But if you finish one before the other, chances are they’re not going to match as well as one would like.

4

Interesting point about licenses vs contracts, and it’s a similar issue with Common Crawl and Llamas’ terms of use.

That being said, I believe Open Source works so well because it is just a license, and you don’t need a counterparty with which to enter into a contract. As a developer I would be very wary of entering into contracts over work I was providing for free or a modest fee, and it’s likely you’d need infrastructure like legal entities to execute said contracts (which, granted, could be shared). I believe Bruce has discovered the same need from a quick pass over his documents, though that may also be business-model related.

By now I think Open Source has proven itself and that the risk of changing its meaning is not worth the perceived benefits, rather a new brand architecture would be required. I’ve been discussing an approach with @mattasmall that could build on existing Open Source licenses but that’s still very early days and may not see the light of day.

5

I cannot disagree with the feedback you’re providing here, but I would like also add that the conversations I am aware of on this topic are converging on the notion that Open Source is simply done – it is necessary to create a “new brand architecture”, because change is necessary and OS will not change.

Modifying the OSD as it stands now to include those concerns is, effectively, an attempt to salvage OS.

The point is, I am not sure everyone is aware of how much trust OS is losing in the community at the moment.

6

For fear of falling into a logical fallacy, let’s use a specific example:

  • A is a western researcher contributing to a computer vision library like OpenCV
  • B is Russia
  • C is Ukraine
  • B uses A’s work to attack (in the most literal sense) C
  • A doesn’t like this but can’t do a thing about it because of OSD5 / OSD6
  • You “fix” OSD to prevent B attacking C, but B is outside of your regulatory sphere and does it anyway

In this case you’ve just broken it for A (and everyone else dependent on them) without fixing what you set out to fix anyway. Further complicating the situation is when [the jurisdiction of] A flip-flops from supporting C to supporting B, as may be happening as we speak.

This is one of myriad reasons why ethics must remain outside of the scope of Open Source, but can certainly be addressed by other frameworks.

While I accept that the “stewards” of Open Source in particular have done incredible damage to the brand by releasing a definition (i.e., OSAID) that doesn’t require the source (i.e., data), I don’t believe it’s irreparable harm (yet), and the technology doesn’t care for hurting marketers’ feelings — either we have a litmus test that works and protects the four freedoms so the software/models can form the foundation for future generations, or we do not. Right now, we do not, but @giacomo’s minimalist amendment to cover data for completeness at least demonstrates that we could without creating a conflicting definition.

If we can’t achieve clear consensus in the community on this, then dare say we can’t achieve it on that (I wouldn’t support it, and I know many others who wouldn’t), and that’s fine… it just means Open Source goes on meaning what it has since it was “invented” over a quarter century ago, as defined by the Open Source Definition at v1.9.

7

“Bad dudes do crimes anyway” is the worst possible argument for not fixing law.

Make no mistake, licenses like any other legal agreement, are extensions of the law because they only work because of the legal framework they’re based on.

This is, frankly, bullshit.

You also picked a particularly defensible argument using Russia. Let’s pick a much more likely one, namely:

  • A is a FLOSS maintainer
  • B is a corporation using that FLOSS according to an OSD-based license agreement
  • C is a user of B’s software
  • A and C are EU entities
  • B is a US entity based somewhere not in California
  • B sells personally identifiable information of C’s
  • Now both under A and C’s legislation, GDPR makes this illegal. Under B’s legislation, CCPA doesn’t apply so they’re free to do so.
  • Copyright law is international, so copyright derived licenses are enforceable also in B’s legislation.
  • A has a legal mandate to do their part in protecting C’s privacy, and thanks to OSD5/6 being gone, now they can fulfil it - to the degree as its license agreement excludes B’s practices. (There is more to it than that, but it’s a start)

This is the kind of scenario we’re dealing with these days.

We’re also dealing with warring nations, but that’s always a scenario in which legal recourse can mostly mop up after the fact.

If you want a conflict-based scenario, just assume a friendly nation is using a FLOSS package to power a genocide machine. Being a friendly nation, recourse to the law is much more likely.

It’s always possible to create scenarios where weaking OSD5/6 will do nothing, but that is just a distraction from all the scenarios in which it would benefit.