Live data from Hacker News

Scapegoating free software’s failures

writing.kemitchell.com

111–120 of 123 posts

Re: Scapegoating free software’s failures

#111
post #8

Earlier quoted context omitted.

You can't. It wouldn't be OSS if I couln't take your library and resell it. You could look at CC-BY-NC-SA, but it's not Open Source and not appropriate for software.

I'm dense. Why isn't it appropriate for software?

I think it's mostly because of the kind of legalese used in the license text, as they are designed for art.

From their FAQ:

> Can I apply a Creative Commons license to software?

> We recommend against using Creative Commons licenses for software. Instead, we strongly encourage you to use one of the very good software licenses which are already available. (...)

> Unlike software-specific licenses, CC licenses do not contain specific terms about the distribution of source code, which is often important to ensuring the free reuse and modifiability of software. (...)

https://creativecommons.org/faq/#can-i-apply-a-creative-comm...

Re: Scapegoating free software’s failures

#112

Earlier quoted context omitted.

> But there's nothing about share-alike terms that require that stricture. The Parity license that I mention in the blog post takes a different tack. But they do. "or another license that allows everything this license does" sounds less restrictive at a glance, in that on the surface it permits additions to be separately licensed, but its effect is the same: no license with more stipulations is acceptable, and by sym…

> But they cannot be weaker copyleft terms. Why not? What about, say, the API Copyleft License, which reads very much like Parity, but permits building closed applications? https://apicopyleft.com/ That license allows everything Parity does, plus one more: creating closed applications.

This so-called API Copyleft license is too weak to usefully consider a copyleft license.

Re: Scapegoating free software’s failures

#113

Earlier quoted context omitted.

> But they cannot be weaker copyleft terms. Why not? What about, say, the API Copyleft License, which reads very much like Parity, but permits building closed applications? https://apicopyleft.com/ That license allows everything Parity does, plus one more: creating closed applications.

This so-called API Copyleft license is too weak to usefully consider a copyleft license.

Do you think the same of MPL? https://spdx.org/licenses/MPL-2.0.html

Re: Scapegoating free software’s failures

#114

Earlier quoted context omitted.

The licenses you mention are not Free Software licenses because restricting what people do with their software (and not just how they share it) violates rule 0. > Why can't a license restrict my freedom to build closed applications with free dev tools, in order to prevent the creation of closed software that likewise restrict others' freedom? It can. If just won't be a FOSS license by the traditionally understood def…

> It just won't be a FOSS license by the traditionally understood definition of FOSS. For better or worse, the Free Software definition guarantees more freedom around end-user usage than it does around how you distribute software. I appreciate your frank admission of the distinction, but I have yet to hear a good defense of it that both rests on something other than "that's the way we said it is" and doesn't trap GPL…

> That definition was largely a post hoc rationalization designed to alleviate the cognitive dissonance between the increasingly libertarian, permissive bent taking over open source ideology via OSI/ESR and the overt prescriptivism of GPL.

This is... a view of that debate, and to be fair it's not necessarily unfounded. But let's assume it's 100% accurate.

Would you say that debate was a good thing for the FOSS movement as a whole, or was it a painful years-long argument that fractured the community and forced otherwise productive developers to waste hundreds of hours arguing with each other?

I don't understand the point-of-view of someone who looks at the GPL, says, "that exception was an arbitrary compromise" and then concludes, "let's add more arbitrary compromises."

> I don't apologize for writing copyleft licenses that eschew the compromises of the earlier forms.

I'm not asking you to. I just don't see why that has to involve attacking a tribe that is resistant to fundamental changes of this sort, and that is perfectly happy with its current growth and direction. I don't see what any of that has to do with your ability to build or promote new licenses, and I don't see why the narrow nature of the FOSS tribe means that suddenly we shouldn't be free to create our own terms that accurately and narrowly describe what we stand for. Say what you want, brand dilution is a real thing, and you are causing it.

And what possible benefit could there be to having this argument? Call your licenses Copyleft++, or Shared Source, or Liberty Licenses, or Social Good Licenses, or Share Alike. You say that you're not trying to co-opt a movement, but I don't understand what benefit you could ever gain from going to war with the existing FOSS community other than to seize on the existing expectations of users who feel like they already understand and can trust what FOSS software is and how it acts in the real world.

> When a better mousetrap comes along, the designer of the last model doesn't get to pull the words "mouse trap" out of the newcomer's mouth.

No, of course not. But if you build a bear trap and start advertising it as a mouse trap, I'm going to call you out on that. You can say the distinctions that we have are arbitrary, you can say that the community is small, you can say that we're dumb for holding on to them, you can say that most people want a new movement that's more receptive to their specific goals, you can say we're ineffective. Fine. But the distinctions still exist, and they allow us as a community to precisely describe ourselves, and we have used them for years, and you don't have the right to arbitrarily take them away.

If you think you can build a better movement, and you obviously think you can, then go build a better movement. I have no objection at all to different communities approaching user freedom from different angles and philosophies. I welcome that, the more the merrier. I would genuinely, sincerely love to see more alternatives to the FOSS movement spring up, because I admit that the FOSS movement can't address everyone's needs on its own.

It's especially fantastic to see lawyers getting involved, because there's a huge, real need for more variety of pre-built licenses that devs can safely adopt, and there are a very small number of people who are both advocating for user freedom and equipped to build those licenses. It's really, really good. Just stop saying that it's FOSS.

Re: Scapegoating free software’s failures

#115

Earlier quoted context omitted.

This so-called API Copyleft license is too weak to usefully consider a copyleft license.

Do you think the same of MPL? https://spdx.org/licenses/MPL-2.0.html

Taken on its own merits, I would indeed consider MPL 2.0 inadequate as a general-purpose copyleft license. Formally, you could argue that it's even weaker than the API Copyleft terms. As such, it's hard to recommend MPL for a project standing alone.

It understands, however, its position as a compromise which makes the underlying goal of its approach to copyleft untenable. Despite that, tries to preserve the ability to incorporate downstream changes through one degree of separation. The difference in expectations is palpable. The implied flow for publishing derivatives of MPL work is to distribute also under MPL, with the option of separately licensing non-Covered Software presented as a concession to tightly define the scope of the license. The implied flow for publishing derivatives of API Copyright Licensed work seems to involve carefully considering how much you can get away with under the listed exceptions, with the option to not share alike presented front and center.

The distinction is essentially irrelevant to anyone approaching licensing from a legalistic perspective, bet defaults matter for everyone else.

Re: Scapegoating free software’s failures

#116

Earlier quoted context omitted.

> It just won't be a FOSS license by the traditionally understood definition of FOSS. For better or worse, the Free Software definition guarantees more freedom around end-user usage than it does around how you distribute software. I appreciate your frank admission of the distinction, but I have yet to hear a good defense of it that both rests on something other than "that's the way we said it is" and doesn't trap GPL…

> That definition was largely a post hoc rationalization designed to alleviate the cognitive dissonance between the increasingly libertarian, permissive bent taking over open source ideology via OSI/ESR and the overt prescriptivism of GPL. This is... a view of that debate, and to be fair it's not necessarily unfounded. But let's assume it's 100% accurate. Would you say that debate was a good thing for the FOSS moveme…

Enjoying this conversation!

> I don't understand the point-of-view of someone who looks at the GPL, says, "that exception was an arbitrary compromise" and then concludes, "let's add more arbitrary compromises."

I don't think we should carve more ugly exceptions into a bad rule. I think we should have a better rule that better serves the underlying purpose. Specifically: license conditions that require developers using open source to build software to contribute their own work alike ought to be welcomed, no which kind of "use" as we slice and dice that term triggers the obligation. In FSF-speak: copyleft can regulate exercise of freedom 0 and freedom 1 as well as freedom 2 and freedom 3, to the same end, adaptable for both activist and pragmatic business use.

> I just don't see why that has to involve attacking a tribe that is resistant to fundamental changes of this sort, and that is perfectly happy with its current growth and direction.

Because that resistance to change creates and perpetuates restraints that prevent developers from addressing pressing, practical problems. Embedded library developers have recognized license choices at hand to keep their work free, or to dual license. Service library developers do not. Distributed-application developers have established license choices to keep their work free or to dual license. Developer toolmakers do not. And so on.

Intentionally or unintentionally, consciously or unconsciously, the old-guard posture picks winners and losers. No picking losers, then claiming to represent them.

> going to war with the existing FOSS community

I'm not at war. But there is no singular FOSS community to go to war with. And again, doctrinal specifics---like being able to rattle off the four freedoms from memory---aren't characteristic of any broad set. They're common knowledge only among a particular cohort of developers who came into open practice in particular ways at particular times. I suspect that includes both of us, but not nearly everyone. It took me way too long to internalize that.

For example, I published a noncommercial software license a while back and took great care not to present it as "open source". Many of its early adopters did anyway. When I reached out to them to warn of the feedback I thought they should expect, the answer was often "nobody I code with cares about any of that". I'd send them the Open Source Definition or links to fsf.org. No awe. Lots of good questions I couldn't answer.

That was my experience with the maximal-copyleft license and OSI, too. After a number of weeks, I had to report back that approval didn't seem likely, but that I didn't feel I could make a strong case why in any but political terms. The developers I thought I was serving by taking the debate for the team responded, almost unanimously: "We don't care. I know open source, and it's open source. Why are you wasting your time on that process in the first place?"

> But the distinctions still exist, and they allow us as a community to precisely describe ourselves, and we have used them for years, and you don't have the right to arbitrarily take them away.

Sure I do, but not arbitrarily.

I believed as you do, that FSF and OSI definitions represent rigorous, legal-flavored standards. Having actually dove into them now, the only precision to take away is false precision. Without linking you to a bunch of long blog posts: The OSD is a fork of DFSG, which OSI holds out as a technical standard, but Debian never did. When the text actually met many eyeballs under OSI, the org ended up making a bunch of hasty changes and commentaries to stem the tide of hackers reading it to exclude GPL. Twenty years later, I still saw comments on OSI's mailing list to the effect that the nondiscrimination criteria prohibit copyleft---more confounding than helpful. In the intervening time, OSI approved a number of controversial and just plain bad licenses. They approved stronger-than-GPL copyleft terms like OSL and RPL.

If the organizations' work in today's climate is to preserve a winners' history of open licensing circa 2000-2010, they should build that monument. Monuments don't move. Movements have to.

If "the movement" was just a tribe, you're right. It belongs to its time and place ... long past. But if "the movement" was really more than that, a set of goals beyond mere market penetration and a very niche kind of fame, the mantle belongs to those advancing those goals. Developers unhappy with where software freedom has run aground don't deserve to be marker for scorn or shorn of their "open source" identity. If that happens, they won't bend over backwards to honor open source as predecessor. They'll turn on it. New tribe.

Re: Scapegoating free software’s failures

#117

Earlier quoted context omitted.

Do you think the same of MPL? https://spdx.org/licenses/MPL-2.0.html

Taken on its own merits, I would indeed consider MPL 2.0 inadequate as a general-purpose copyleft license. Formally, you could argue that it's even weaker than the API Copyleft terms. As such, it's hard to recommend MPL for a project standing alone. It understands, however, its position as a compromise which makes the underlying goal of its approach to copyleft untenable. Despite that, tries to preserve the ability t…

The use case for MPL and SSPL was broadly the same: selectively apply permissivity for the primary build-on use case (browser plugins, applications) to stoke adoption and copyleft to other use cases (forks, hosted offerings) as a bulwark against competitors (Microsoft, AWS). In drafting and presentation, I thought SSPL failed to communicate that heritage. So I wrote what became the API Copyleft License.

Re: Scapegoating free software’s failures

#118

Earlier quoted context omitted.

I'm dense. Why isn't it appropriate for software?

I think it's mostly because of the kind of legalese used in the license text, as they are designed for art. From their FAQ: > Can I apply a Creative Commons license to software? > We recommend against using Creative Commons licenses for software. Instead, we strongly encourage you to use one of the very good software licenses which are already available. (...) > Unlike software-specific licenses, CC licenses do not c…

I hadn't noticed that before. Thank you.

Re: Scapegoating free software’s failures

#119
post #47

Earlier quoted context omitted.

The FSF is not 'attacking' such licenses, they're just arguing that they aren't free libre software licenses. It's the SSPL people and others, by trying to co-opt the free and Libre software movement by claim their licenses are something they are not, which are mounting the assault. And let's be clear it is a pernicious, aggressive and deliberate attack threatening, and in some cases knowingly intended to fundamental…

The "aggressive, deliberate, threatening attacks" I have seen in discussions like this almost always seem to come from the FSF crowd. (not necessarily official sources, but supporters in public discussion channels)

If the source available people weren’t trying to appropriate the term Free Software (with capitals) this argument wouldn’t exist. Free Software has a long standing, broadly accepted definition which many of these companies accepted and see to their advantage for many years. Now they want to change their licenses, but keep using the term.

They are trying to take other people’s stuff. They can’t just walk away with all the good Will and social capital Free Software has built up over the years because it’s beneficial to their shareholders. That’s the attack, it’s a smash and grab, and that’s why FOSS is fighting for its life in this.

Re: Scapegoating free software’s failures

#120
post #79

Earlier quoted context omitted.

If the employer distributes to the third party then the employee still doesn't have the rights. But the third party can distribute to anybody.

Hmm GPL states any distributed modifications must be shared. So the employee does not violate any licenses by snagging a copy of the code that was distributed. I’m sure there may be other violations that may cause an involuntary termination event, but per the license the world now has the right (and the company is violating the GPL by not offering the code) I will add if the company fixes their GPL violation then the…

License is between two parties, world doesn't have any rights. I can see how two companies can use GPL to share the code they both use internally, and nobody else has the right to use it unless one of the companies "conveys" it to them.
Post reply on HN