Archives

Tags

Posts with tag "foss"

Departing Libre Lounge

By Christopher Lemmer Webber on Wed 13 May 2020

Over the last year and a half I've had a good time presenting on Libre Lounge with my co-host Serge Wroclawski. I'm very proud of the topics we've decided to cover, of which there are quite a few good ones in the archive, and the audience the show has had is just the best.

However, I've decided to depart the show... Serge and I continue to be friends (and are still working on a number of projects together, such as Datashards and the recently announced grant), but in terms of the podcast I think we'd like to take things in different creative directions.

This is probably not the end of me doing podcasting, but if I start something up again it'll be a bit different in its structure... and you can be sure you'll hear about it here and on my fediverse account and over at the birdsite.

In the meanwhile, I look forward to continuing to tuning into Libre Lounge, but as a listener.

Thanks for all the support, Libre Loungers!

Spritely's NLNet grant: Interface Discovery for Distributed Systems

By Christopher Lemmer Webber on Wed 13 May 2020

I've been putting off making this blogpost for a while because I kept thinking, "I should wait to do it until I finish making some sort of website for Spritely and make a blogpost there!" Which, in a sense is a completely reasonable thought because right now Spritely's only "website" is a loose collection of repositories, but I'd like something that provides a greater narrative for what Spritely is trying to accomplish. But that also kind of feels like a distraction (or maybe I should just make a very minimal website) when there's something important to announce... so I'm just doing it here (where I've been making all the other Spritely posts so far anyway).

Spritely is an NLnet (in conjunction with the European Commision / Next Generation Internet initative) grant recipient! Specifically, we have received a grant for "Interface Discovery for Distributed Systems"! I'll be implementing the work alongside Serge Wroclawski.

There are two interesting sub-phrases there: "Interface Discovery" and "Distributed Systems". Regarding "distributed systems", we should really say "mutually suspicious open-world distributed systems". Those extra words change some of the requirements; we have to assume we'll be told about things we don't understand, and we have to assume that many objects we interact with may be opaque to us... they might lie about what kind of thing they are.

Choosing how to name interfaces then directly ties into something I wrote about here more recently, namely content addressed vocabulary.

I wrote more ideas and details about the interfaces ideas email to cap-talk so you can read more there if you like... but I think more details about the interfaces thoughts than that can wait until we publish a report about it (and publishing a report is baked into the grant).

The other interesting bit though is the "distributed" aspect; in order to handle distributed computation and object interaction, we need to correctly design our protocols. Thankfully there is a lot of good prior art to work from, usually some variant of "CapTP" (Capability Transport Protocol), as implemented in its original form by E, taking on a bit of a different form in the Waterken project, adapted in Cap'N Proto, as well as with the new work happening over at Agoric. Each of these variants of the core CapTP ideas have tried to tackle some different use cases, and Goblins has its own needs to be covered. Is there a possibility of convergence? Possibly... I am trying to understand the work of and communicate with the folks over at Agoric but I think it's a bit too early to be conclusive about anything. Regardless, it'll be a major milestone once Spritely Goblins is able to actually live up to its promise of distributed computation, and work on this is basically the next step to proceed on.

When I first announced Spritely about a year and a half ago I included a section that said "Who's going to pay for all this?" to which I then said, "I don't really have a funding plan, so I guess this is kind of a non-answer. However, I do have a Patreon account you could donate to." To be honest, I was fairly nervous about it... so I want to express my sincere and direct appreciation to NLnet alongside the European Commission / Next Generation Internet Initiative, along with Samsung Stack Zero, and all the folks donating on Patreon and Liberapay. With all the above, and especially the new grant from NLnet, I should have enough funding to continue working on Spritely through a large portion of 2021. I am determined to make good on the support I've received, and am looking forward to put out more interesting demonstrations of this technology over the next few months.

What should fit in a FOSS license?

By Christopher Lemmer Webber on Mon 09 March 2020

Originally sent in an email to the OSI license-discuss mailing list.

What terms belong in a free and open source software license? There has been a lot of debate about this lately, especially as many of us are interested in expanding the role we see that we play in terms of user freedom issues. I am amongst those people that believe that FOSS is a movement thats importance is best understood not on its own, but on the effects that it (or the lack of it) has on society. A couple of years ago, a friend and I recorded an episode about viewing software freedom within the realm of human rights; I still believe that, and strongly.

I also believe there are other critical issues that FOSS has a role to play in: diversity issues (both within our own movement and empowering people in their everyday lives) are one, environmental issues (the intersection of our movement with the right-to-repair movement is a good example) are another. I also agree that the trend towards "cloud computing" companies which can more or less entrap users in their services is a major concern, as are privacy concerns.

Given all the above, what should we do? What kinds of terms belong in FOSS licenses, especially given all our goals above?

First, I would like to say that I think that many people in the FOSS world, for good reason, spend a lot of time thinking about licenses. This is good, and impressive; few other communities have as much legal literacy distributed even amongst their non-lawyer population as ours. And there's no doubt that FOSS licenses play a critical role... let's acknowledge from the outset that a conventionally proprietary license has a damning effect on the agency of users.

However, I also believe that user freedom can only be achieved via a multi-layered approach. We cannot provide privacy by merely adding privacy-requirements terms to a license, for instance; encryption is key to our success. I am also a supporter of code of conducts and believe they are important/effective (I know not everyone does; I don't care for this to be a CoC debate, thanks), but I believe that they've also been very effective and successful checked in as CODE-OF-CONDUCT.txt alongside the traditional COPYING.txt/LICENSE.txt. This is a good example of a multi-layered approach working, in my view.

So acknowledging that, which problems should we try to solve at which layers? Or, more importantly, which problems should we try to solve in FOSS licenses?

Here is my answer: the role of FOSS licenses is to undo the damage that copyright, patents, and related intellectual-restriction laws have done when applied to software. That is what should be in the scope of our licenses. There are other problems we need to solve too if we truly care about user freedom and human rights, but for those we will need to take a multi-layered approach.

To understand why this is, let's rewind time. What is the "original sin" that lead to the rise proprietary software, and thus the need to distinguish FOSS as a separate concept and entity? In my view, it's the decision to make software copyrightable... and then, adding similar "state-enforced intellectual restrictions" categories, such as patents or anti-jailbreaking or anti-reverse-engineering laws.

It has been traditional FOSS philosophy to emphasize these as entirely different systems, though I think Van Lindberg put it well:

Even from these brief descriptions, it should be obvious that the term "intellectual property" encompasses a number of divergent and even contradictory bodies of law. [...] intellectual property isn't really analagous to just one program. Rather, it is more like four (or more) programs all possibly acting concurrently on the same source materials. The various IP "programs" all work differently and lead to different conclusions. It is more accurate, in fact, to speak of "copyright law" or "patent law" rather than a single overarching "IP law." It is only slightly tongue in cheek to say that there is an intellectual property "office suite" running on the "operating system" of US law. -- Van Lindberg, Intellectual Property and Open Source (p.5)

So then, as unfortunate as the term "intellectual property" may be, we do have a suite of state-enforced intellectual restriction tools. They now apply to software... but as a thought experiment, if we could rewind time and choose between a timeline where such laws did not apply to software vs a time where they did, which would have a better effect on user freedom? Which one would most advance FOSS goals?

To ask the question is to know the answer. But of course, we cannot reverse time, so the purpose of this thought experiment is to indicate the role of FOSS licenses: to use our own powers granted under the scope of those licenses to undo their damage.

Perhaps you'll already agree with this, but you might say, "Well, but we have all these other problems we need to solve too though... since software is so important in our society today, trying to solve these other problems inside of our licenses, even if they aren't about reversing the power of the intellectual-restriction-office-suite, may be effective!"

The first objection to that would be, "well, but it does appear that it makes us addicted in a way to that very suite of laws we are trying to undo the damage of." But maybe you could shrug that off... these issues are too important! And I agree the issues are important, but again, I am arguing a multi-layered approach.

To better illustrate, let me propose a license. I actually considered drafting this into real license text and trying to push it all the way through the license-review process. I thought that doing so would be an interesting exercise for everyone. Maybe I still should. But for now, let me give you the scope of the idea. Ready?

"The Disposable Plastic Prevention Public License". This is a real issue I care about, a lot! I am very afraid that there is a dramatic chance that life on earth will be choked out within the next number of decades by just how much non-degradeable disposable plastic we are churning out. Thus it seems entirely appropriate to put it in a license, correct? Here are some ideas for terms:

  • You cannot use this license if you are responsible for a significant production of disposable plastics.

  • You must make a commitment to reduction in your use of disposable plastics. This includes a commitment to reductions set out by (a UN committee? Haven't checked, I bet someone has done the research and set target goals).

  • If you, or a partner organization, are found to be lobbying against laws to eliminate disposable plastics, your grant of this license is terminated.

What do you think? Should I submit it to license-review? Maybe I should. Or, if someone else wants to sumbit it, I'll enthusiastically help you draft the text... I do think the discussion would be illuminating!

Personally though, I'll admit that something seems wrong about this, and it isn't the issue... the issue is one I actually care about a lot, one that keeps me up at night. Does it belong in a license? I don't think that it does. This both tries to both fix problems via the same structures that we are trying to undo problems with and introduces license compatibility headaches. It's trying to fight an important issue on the wrong layer.

It is a FOSS issue though, in an intersectional sense! And there are major things we can do about it. We can support the fight of the right-to-repair movements (which, as it turns out, is a movement also hampered by these intellectual restriction laws). We can try to design our software in such a way that it can run on older hardware and keep it useful. We can support projects like the MNT Reform, which aims to build a completely user-repairable laptop, and thus push back against planned obsolescence. There are things we can, and must, do that are not in the license itself.

I am not saying that the only kind of thing that can happen in a FOSS license is to simply waive all rights. Indeed I see copyleft as a valid way to turn the weapons of the system against itself in many cases (and there are a lot of cases, especially when I am trying to push standards and concepts, where I believe a more lax/permissive approach is better). Of course, it is possible to get addicted to those things too: if we could go back in our time machine and prevent these intellectual restrictions laws from taking place, source requirements in copyleft licenses wouldn't be enforceable. While I see source requirements as a valid way to turn the teeth of the system against itself, in that hypothetical future, would I be so addicted to them that I'd prefer that software copyright continue just so I could keep them? No, that seems silly. But we also aren't in that universe, and are unlikely to enter that universe anytime soon, so I think this is an acceptable reversal of the mechanisms of destructive state-run intellectual restriction machine against itself for now. But it also indicates maybe a kind of maxima.

But it's easy to get fixated on those kinds of things. How clever can we be in our licenses? And I'd argue: minimally clever. Because we have a lot of other fights to make.

In my view, I see a lot of needs in this world, and the FOSS world has a lot of work to do... and not just in licensing, on many layers. Encryption for privacy, diversity initiatives like Outreachy, code of conducts, software that runs over peer to peer networks rather than in the traditional client-server model, repairable and maintainable hardware, thought in terms of the environmental impact of our work... all of these things are critical things in my view.

But FOSS licenses need not, and should not, try to take on all of them. FOSS licenses should do the thing they are appropriate to do: to pave a path for collaboration and to undo the damage of the "intellectual restriction office suite". As for the other things, we must do them too... our work will not be done, meaningful, or sufficient if we do not take them on. But we should do them hand-in-hand, as a multi-layered approach.

Terminal Phase 1.0

By Christopher Lemmer Webber on Sun 19 January 2020

Testing Terminal Phase image

I'm pleased to announce that Terminal Phase, a space shooter game you can play in your terminal, has achieved version 1.0. The game is completely playable and is a fun game (well, at least a number of playtesters told me they thought it was fun). It includes two levels (one of which is more balanced than the other), and more content is on its way (1.0 isn't the end!). You can see it being played above in cool-retro-term but it works in all sorts of terminals, including gnome-terminal and etc.

I also released a video recently (archive.org mirror) of me doing a live playtest of the game and also showing off how to make new levels and program new enemies (which serves as kind of an introduction, but probably not the best one, to Spritely Goblins).

Terminal Phase was actually a reward for hitting the $500/mo milestone on my Patreon account, which we achieved a little over a week ago. I aimed to get 1.0 out the door by midnight on Wednesday but I actually released it a couple of hours later, closer to 2:30am, because I was trying to make the credits look cool:

Terminal Phase Credits

I think I succeeded, right? Maybe you would like your name in there; you can still do so by selecting a tier on my Patreon account. I released the game as FOSS, so whether you donate or not, you can still reap the benefits. But I figure making the credits look cool and putting peoples' names in there would be a good way of making people feel motivated. And there are more releases on the way; I'll be adding to this now and then and releasing more stuff occasionally. In fact you may notice the cool parallax scrolling starfield in the gif at the top of this post; I added that after 1.0. I guess it's a bit sneaky to put that on top of a post labeled 1.0, but the good news is that this means that 1.1 is not far away, which will include some new enemies (maybe a boss?), new levels, and yes, parallax starfields (and maybe your name in the credits if it isn't already).

Anyway, enough self-shilling; let's talk more about the game itself. Terminal Phase really had a number of goals:

  • Fun. Games are fun, and making them is (well, mostly) fun and interesting. And I feel like the FOSS world could use more fun.
  • Fundraising. I do a lot of work to enrich the commons; funding that stuff can be brutally hard, and obviously this was a fundraising tactic.
  • A litmus test. I wanted to see, "Do people care about funding FOSS games, in particular? Does this matter to people?" My suspicion is that there is an interest, even if niche, and that seems to have been validated. Great.
  • Pushing the medium of interactive terminal-based / ascii art content. Probably because it's a retro area, it's not really one where we see a lot of new content. We see a lot more terminal-based turn-based games, most notably roguelikes; why not more live action stuff? (Note that I have done two other projects I did this year in this same vein.)
  • Thanking donors. I had this Patreon account and that's great that people were being generous, but I felt like it would be nice to have something that felt quasi-tactile, like you got something visible back from it. I hope people feel like that succeeded.
  • But most importantly, advancing Spritely Goblins. Terminal Phase is a program to demonstrate and test how well about half of what Goblins does works well, namely transactional object interactions.

I feel like all of those were a success, but I really want to write more about that last one. Except, well, I already have in some detail, and maybe I'd repeat myself. But I'll say that developing Terminal Phase has made me dramatically more confident that the core parts of Spritely Goblins work well and make sense. That's good, and I can say that without a bunch of hand-waving; I built something that feels nice to use and to program.

That lets me move forward with solidifying and documenting what I have and focusing on the next layer: the asynchronous programming and distributed networked objects layers. The former of those two exists, the latter of those needs work, but both will be tested in a similar way soon; I plan on building some highly interactive demos to show off their ideas.

Anyway, I hope you enjoy the game, and thank you to everyone who donated and made it possible! Again, I plan to release more soon, including new levels, new enemies, boss battles, and yes, even some powerups. And if you like the game, consider becoming a supporter if you aren't already!

Now back to working on Spritely Goblins itself...

Noncommercial Doesn't Compose (and it never will)

By Christopher Lemmer Webber on Fri 27 December 2019

NOTE: I actually posted this some time ago on license-discuss and some people suggested that I blog it. A good idea, which I never did, until now. The topic has't become any less relevant, so...

It's sad to see history repeat itself, but that's what history does, and it seems like we're in an awfully echo'y period of time. Given the volume of submissions in favor of some sort of noncommercial style license, I feel I must weigh in on the issue in general. Most of my thoughts on this developed when I worked at Creative Commons (which famously includes a "noncommercial" clause that can be mixed into a few licenses), and it took me a while to sort out why there was so much conflict and unhappiness over that clause. What was clear was that Non-Commercial and No-Derivatives were both not considered "free culture" licenses, and I was told this was drawn from the lessons of the free software world, but here we are hashing it out again so anyway...

(I'm not suggesting this is a CC position; Creative Commons hasn't to my knowledge taken an official stance on whether NonCommercial is right, and not everyone internally agreed, and also I don't work there anymore anyhow.)

I thank Rob Myers for a lot of clarity here, who used to joke that NC (the shorthand name for Non-Commercial) really stood for "No Community". I think that's true, but I'll argue that even more so it stands for "No Composition", which is just as much or more of a threat, as I hope to explain below.

As a side note, I am of course highly empathetic to the motivations of trying to insert a noncommercial clause; I've worn many hats, and funding the software I've worked on has by far been the hardest. At first glance, an NC approach appears to be a way to solve the problem. Unfortunately, it doesn't work.

The first problem with noncommercial is that nobody really knows for sure what it means. Creative Commons made a great effort to gather community consensus. But my read from going through that is that it's still very "gut feel" for a lot of people, and while there's some level of closeness the results of the report result in nothing crisp enough to be considered "defined" in my view. Personally I think that nothing will ever hit that point. For instance, which of these is commercial, and which is noncommercial?

  • Playing music at home
  • Playing music overhead, in a coffee shop
  • A song I produced being embedded in a fundraising video by the Red Cross
  • Embedding my photo in a New York Times article
  • Embedding my photo in a Mother Jones article
  • Embedding my photo on Wikipedia (if you think this is a clear and easy example btw, perhaps you'd like to take a selfie with this monkey?)

But this actually isn't the most significant part of why noncommercial fails, has always failed, and will always fail in the scope of FOSS: it simply doesn't compose.

Using the (A)GPL as the approximate maxima (and not saying it's the only possible maxima) of license restrictions, we still have full composition from top to bottom. Lax and copyleft code can be combined and reused with all participants intending to participate in growing the same commons, and with all participants on equal footing.

Unfortunately, NC destroys the stack. NC has the kind of appeal that a lottery does: it's very fun to think about participating when you imagine yourself as the recipient. The moment you have to deal with it underneath, it becomes a huge headache.

I had an argument about this with someone I tend to work closely with, they began arguing for the need to insert NC style clauses into code, because developers gotta eat, which is at any rate a point I don't disagree with. But recently several of the formerly FOSS infrastructure switched to using an NC license, and they began to express that this opened up a minefield underneath them. If it felt like a minefield with just one or two libraries or utilities following the NC path, what will happen once it's the whole system?

What would using Debian be like if 1/4 of the packages were under NC licenses? Would you deploy it on your home machine? Would you deploy it on your personal VPS? Would you deploy it at your corporate datacenter? Even if I am a "noncommercial" user, if my VPS is at Linode, would Linode have to pay? What about Amazon? Worse yet... what if some of the package authors were dead or defunct?

To me it's no coincidence that we're seeing an interest in NC right at exactly the same time that faith in proprietary relicensing of copyleft code as a business strategy has begun to wane. If you were at my talk at CopyleftConf, you may have heard me talk about this in some detail (and some other things that aren't relevant to this right now). You can see the original table on slide 8 from my presentation, but here it is reproduced:

  Libre Commoner Proprietary Relicensor
Motivation Protect the commons Develop income
Mitigating Tragedy of the commons Free rider problem
Wants Compliance Non-compliance

(By "tragedy of the commons", here I mean "prevent the commons from being eaten away".)

The difference in the "wants" field is extremely telling: the person I will call the "libre commoner" wants everyone to be able to abide by the terms of the license. The "propretary relicensor" actually hopes and dreams that some people will not comply with the license at all, because their business strategy depends on it. And in this part, I agree with Rob's "No-Community" pun.

Let me be clear: I'm not arguing with the desire to pay developers in this system, I'm arguing that this is a non-solution. To recap, here are the problems with noncommercial:

  • What commercial/noncommercial are is hard to define
  • NC doesn't compose; a tower of noncommercial-licensed tools is a truly brittle one to audit and resolve
  • The appeal of NC is in non-compliance

Noncommercial fails in its goals and it fails the community. It sounds nice when you think you'll be the only one on top, but it doesn't work, and it never will.