Live data from Hacker News

Releasing my tools under the MIT License was probably a mistake (2023)

donatstudios.com

81–90 of 128 posts

Re: Releasing my tools under the MIT License was probably a mistake (2023)

#81

Earlier quoted context omitted.

That's why he is regretting the use of the MIT license. He wonders, now, if having chosen a less permissive license would have given him grounds to shut them down, because they would be in violation.

Hang on - permissive licenses still require attribution. If they're not doing that, then he can absolutely DCMA them. (I think; IANAL)

Not on the rendered web site, only in source code

Re: Releasing my tools under the MIT License was probably a mistake (2023)

#82

The author is sharing second thoughts about using the MIT license and yes, bad actors are going to break bad, but the point of licensing is to control re-use within the (enforceable) legal framework of copyright. Reciprocal licenses (thanks Lawrence Rosen[1] for that term less charged than copyleft or viral) cede less control, and provide more footholds for enforcement. Remember that GPL has (sometimes) worked as int…

To be honest I prefer copyleft or viral over reciprocal. Reciprocal licensing is traditionally an arrangement where a given license is interchangeable with another license. For example, drivers licenses are often reciprocal between states. I've worked for firms which has reciprocal licensing agreements with some of their manufacturers. Copyleft is neither.

The big place that permissive licenses are promoted is in the giant tech companies. This is not a coincidence; it benefits them. That does not mean it benefits us.

With smaller companies we see a lot of *GPL with additional commercial licensing options ... which (assuming the main product is not a library with a non-LGPL license) often is actually still easy to comply with (especially if you only use somebody's prebuilt binaries) if you actually bother, no matter how much the hate train complains.

For individuals it varies a lot by ideology rather than deep thought, but permissive-license-regret is common.

Re: Releasing my tools under the MIT License was probably a mistake (2023)

#83
post #80

Earlier quoted context omitted.

Its not illegal, but it is abuse

If you consider this an abuse, you're not in favor of the spirit of open source to avoid discrimination. You think uses should be discriminated between acceptable and abusive. It's OK to think that way, but it's not an open source way of thinking.

The original goal of Free Software, and the part I vibe with, is that you should have full freedom and control of the software you run.

The people taking someone else's tool and rehosting it with better SEO and more ads steals revenue from the original author and makes them less likely to make more open source stuff. It's greedy and hurts the community. I get why people would want non-OSI licences that allow everything but that.

As for whether its Abuse, idk, I don't want to lay out a precise definition and have a semantics argument. But its definitely not a cool thing to do

Re: Releasing my tools under the MIT License was probably a mistake (2023)

#84
post #78

Earlier quoted context omitted.

I hate that people think they can control the definitions of "free" and "open" . I don't care about these biased propaganda definitions. If you want to promote your definition use a branded trademarkable name, don't try to steal our shared use of common words.

“Free” means something. If you want to stop people distributing your software through a site that has ads, then it’s not “free.” “Open source” means something too. The control people have is in using shared definitions. Language is malleable, so if enough people use a word incorrectly it changes the definition. But those people get to be called wrong for years until enough people misuse it to make it right.

You're redefining big-F "Free" software as defined by the GPL, which aims to give users freedom to change their software - and is indifferent to; at best, restricts at the worst, the rights of intermediate software developers who inject themselves between Free software and users by choosing to redistribute or allow their software to be infected by the GPL bits.

IMO, MIT & BSD give downstream developers more rights and are indifferent to end-users. GPL gives users more rights, and indifferent to downstream developers.

Re: Releasing my tools under the MIT License was probably a mistake (2023)

#85
post #80

Earlier quoted context omitted.

Its not illegal, but it is abuse

If you consider this an abuse, you're not in favor of the spirit of open source to avoid discrimination. You think uses should be discriminated between acceptable and abusive. It's OK to think that way, but it's not an open source way of thinking.

> A number of them even have the gall to post links advertising them in the comments of my own tools.

That and the search engine mayhem are abusive behaviour, even if not abuse of the license.

It's being a dick, deliberately.

Re: Releasing my tools under the MIT License was probably a mistake (2023)

#86
post #78

Earlier quoted context omitted.

I hate that people think they can control the definitions of "free" and "open" . I don't care about these biased propaganda definitions. If you want to promote your definition use a branded trademarkable name, don't try to steal our shared use of common words.

“Free” means something. If you want to stop people distributing your software through a site that has ads, then it’s not “free.” “Open source” means something too. The control people have is in using shared definitions. Language is malleable, so if enough people use a word incorrectly it changes the definition. But those people get to be called wrong for years until enough people misuse it to make it right.

You have one definition, of "free" but its not the only reasonable one.

Is MIT not free because it requires attribution? Is no code free because it cannot be used in ways that break the law?

Just because there are some restrictions does not make it completely unfree, and its fair for people to want to use what is the most natural word to refer to thing that are free enough for them. "OSI-approved" works if you want to be precise but one org does not have the right to dictate the use of a word as common as "open".

Re: Releasing my tools under the MIT License was probably a mistake (2023)

#87

Earlier quoted context omitted.

> My instant emotional reaction was to feel vaguely cheated, or that the guy I sold it to was a sleaze. Were you cheated? Probably not. But the guy was definitely on a sleaziness spectrum.

I mean, I wouldn't do it, just because I don't want to deal with everything. But everyone got exactly what they wanted. I see no sleaze.

the reseller could have been honest:

"why don't you post it on craigslist?"

"don't want to deal with the scum there."

"mind if i buy it off you and then post it?"

"go ahead, and good luck."

Re: Releasing my tools under the MIT License was probably a mistake (2023)

#88
post #28

Not sure they can change the license at all? The author doesn’t own copyright for the code changes they accepted over the years. But kudos to the author for acknowledging they picked up a dumb license. Sad not to see the GPL or AGPL considered though.

You can take MIT software and add additional restrictions to it, which is the main difference between MIT and GPL in the first place

Re: Releasing my tools under the MIT License was probably a mistake (2023)

#89

> In some cases, they are even beating me in search results for my own tools. Correct me if im wrong but the license does not give them the right to name. Author should still be able to request them to change the name?

It's interesting: generally speaking OSS licenses concern copyright for the code, but not trademarks for the name of the project. Licensing Project Foobar under an OSS license should not really be seen as granting permission to use the name "Project Foobar". But I just realized that the MIT license is worded in such a way that one could draw that inference, and it might stand up in court. Permission is hereby granted…

I do not think so. First of all, the license is clear that it is a “copyright license”. In my view, that calls out the distinction from trademark by exclusion. It would not be a reasonable interpretation to assume a trademark license unless trademark is explicitly mentioned and even less so when the license is explicitly described as a “copyright” license. The license defines “The Software” and, again, I see no reason to infer trademark as being part of that definition.

The license also requires you to include attribution and to declare the copyright of the licensor. So, while you have access to the software, ownership has clearly not transferred. You have a copyright license ( that has to be declared ). Nothing more.

Re: Releasing my tools under the MIT License was probably a mistake (2023)

#90

Earlier quoted context omitted.

It's interesting: generally speaking OSS licenses concern copyright for the code, but not trademarks for the name of the project. Licensing Project Foobar under an OSS license should not really be seen as granting permission to use the name "Project Foobar". But I just realized that the MIT license is worded in such a way that one could draw that inference, and it might stand up in court. Permission is hereby granted…

I do not think so. First of all, the license is clear that it is a “copyright license”. In my view, that calls out the distinction from trademark by exclusion. It would not be a reasonable interpretation to assume a trademark license unless trademark is explicitly mentioned and even less so when the license is explicitly described as a “copyright” license. The license defines “The Software” and, again, I see no reaso…

> I do not think so. First of all, the license is clear that it is a “copyright license”

No it doesn't. That's why you can use an MIT-licensed codebase that doesn't have an explicit patent grant and not worry about patent enforcement—it doesn't narrowly constrain itself to copyright.

Post reply on HN