Live data from Hacker News

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

donatstudios.com

111–120 of 128 posts

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

#111
post #92

Earlier quoted context omitted.

Yeah, I've read the text. And it's trivial to be compliant with AGPL in this case without any effective change to the behaviour or problems caused. Yes, there would be source code link somewhere, but it can take 0.01% of the SEO spam and be still compliant.

There are plenty of examples of BSD-licensed code authors being burnt like this (including original ones from Berkeley, which were an impetus for the creation of the GPL; there were proprietary Unix systems built on top of volunteer-written code competing with the original systems). Can you point me to any concrete examples of authors of AGPL-licensed code being burnt like this? Circumventing the AGPL is trivial only…

AGPL does cause issues in various places, yes. But not in this specific case.

Quickly checking through license text (AGPLv3 as published on FSF website), following steps would have been enough:

1. Ability to view legal notice (does not have to be full, just reasonably visible)

2. A link that opens source of the code

3. AGPLv3 header in source code with notice of who and when modified it

Note that there's no need to explicitly advertise/attribute the creators in any more visible way. AGPLv3 also does not impact code that isn't derivative like all the SEO spam one's blackened heart puts on the site, especially when combined with modern "tag manager".

And we're explicitly talking about pathological cases from the start. To paraphrase oliwarner in this thread[1], we're dealing with people who are deliberately acting dickish.

I'll bypass discussion of BSD-licensed authors being burnt like that, because the legal situation was way more complex (before the GPL came on the scene) regarding a lot of BSD code (shortlist: 1) being derivative of other code 2) in at least one case being explicitly paid-for work with explicit "to be reused freely" conditions on the grant)

[1] https://news.ycombinator.com/item?id=39415042

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

#112
post #82

Earlier quoted context omitted.

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 prebu…

I think regret is common. I don't think it's particularly novel to permissive licensing. Besides, most projects never reach any sort of popularity to draw a contributor count greater than 1, and relicensing at that scale is tremendously easy -- you just do it. I'm also not sure what your on about with regards to big companies vs small companies. Do you mean companies which produce open source software? Or companies c…

> Almost all companies which produce software under GPL or AGPL dual license with a commercial paid option that comes with no strings attached. Personally I find this disingenuous.

There was at least for a time a trend (or at least noted by some) of using AGPL with copyright assignment[1] as a trojan horse to force customers into commercial licensing once due diligence came in.

[1] I consider copyright attribution to be the big sin in this, not AGPL, even though I'm against AGPL on other grounds. I understand why FSF uses (used?) it, but it opens a way for exploitation of people's work in unequal ways.

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

#113
post #70
post #57

Earlier quoted context omitted.

AGPL wouldn't prevent any of the abuses he describes, though.

It's not an abuse. This is by design. It's one thing many don't get about Open Source. The goal is to not discriminate against any kind of use. If you want to discriminate users by how they use it, then you don't want open source.

Your thoughts regarding open source are borderline irrational when places like Amazon will copy and paste your repository and start making billions off of it.

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

#114
post #111

Earlier quoted context omitted.

There are plenty of examples of BSD-licensed code authors being burnt like this (including original ones from Berkeley, which were an impetus for the creation of the GPL; there were proprietary Unix systems built on top of volunteer-written code competing with the original systems). Can you point me to any concrete examples of authors of AGPL-licensed code being burnt like this? Circumventing the AGPL is trivial only…

AGPL does cause issues in various places, yes. But not in this specific case. Quickly checking through license text (AGPLv3 as published on FSF website), following steps would have been enough: 1. Ability to view legal notice (does not have to be full, just reasonably visible) 2. A link that opens source of the code 3. AGPLv3 header in source code with notice of who and when modified it Note that there's no need to e…

.... which would address the author's issue of not having access to the source code.

But you messed up since you proposed a technical solution, where this is an organizational problem. Let me walk you through the more complex issue. The other website follows your steps and is in the clear. However:

* The interactive is more deeply integrated into their web page, whether originally, or through a developer five years later not noticing the AGPL special case.

* OP asks for source code to the full work. The full work is their entire web site in this case.

* The full work happens to include a JavaScript library and a font program which were licensed from a proprietary vendor.

The other website has two options: (1) Negotiate to release the their source code, and worse, their vendor's source code under the AGPL (2) Pay damages.

To avoid this, beyond the steps listed, the other website needs to implement processes and controls to prevent issues like this one. That is where the $$$$$ comes in. Processes are expensive to maintain, much more so than any software.

In general, AGPL code is very safe to use in commercial settings for well-compartmentalized major systems. If I have an AGPL office suite used by my organization, or ed-tech software, that's easy. Used it in a corner like this one, it requires a lot of controls and compliance, which make it prohibitively expensive. AGPL has a few more catches like this. This is why most major organizations tend to require legal review prior to any use of AGPL code.

AGPL tends to be good for several purposes:

1) Establishing open ecosystems. If I do work in civics or education, this can be very important there. If I am making a voting system, for example, I want to guarantee anyone can inspect the system at any level.

2) Dual-licensed systems. Open ecosystem is free. Proprietary pays.

3) Major pieces of well-isolated code, like the aforementioned office suite example, where I don't want freeloaders, and where there isn't an expectation that I will have my code used as a library or piecewise in another system.

4) Places where the goal is more transparency than reuse.

There are a few others too.

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

#115
post #39

About 15 years ago I sold a car I owned. Its fair market value was $5,000, but to get that I'd have to wash it, put an ad on Craigslist, deal with the scammers who want to pay with fake money orders, meet with potential buyers, let them test-drive it, etc., and I didn't have the time or patience to do all that. So instead I sold it to a coworker at a low price, maybe $4,000. I sent an email to the company's water-coo…

> 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.

In retrospect I view that part as an example of "don't hate the player, hate the game." In negotiated deals like this, it's not unusual to represent yourself as the right choice even if the terms you're offering aren't the best. See homebuyer offer letters for a particularly nauseating example. Who knows or really cares whether those parts of the deal are honest?

Maybe the car truly would have been great for his mom.

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

#116
post #77

Earlier quoted context omitted.

MIT doesn't require public attribution on the user's website. Here's what it requires: > The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. If you leave the MIT license anywhere in your server alongside the licensed code, with no public access, you are complying.

IANAL, but that doesn't sound right. A "copy" would be internet visible code repository. If it doesn't contain the LICENSE file (assuming that's what OP has) it's in violation of that rule in my opinion.

Your rationale makes sense if the software is distributed. Providing an output (observe that an output is not the software) through the internet is not considered distribution of the software.

The license doesn't require anyone to provide a copy of the license and attribution along with the output, only when the software is distributed.

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

#117

Earlier quoted context omitted.

> I want you to use things I've written. On top of that I don't believe it's my place to force you to then open source things you have written that expand upon my source code. I'm a big proponent of the GPL and the AGPL, but no they don't sound like good solutions to the author's problems. It might solve the attribution issue but it's going to go counter to the author's other goals.

Except that the author then goes on to say how much they would prefer the derivative works to be open source, so it seems like they do want it but have been convinced they shouldn't. AGPL and an offer that other licenses would be available on request seems perfectly suitable.

The author doesn't say they prefer derivative works (e.g. works using a library) to be open source, only that they want modifications to the library to be open source

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

#118
post #87

Earlier quoted context omitted.

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."

Exactly. Maybe the top-level poster says something like "Oh if you're going to clean it and re-sell it for a profit, I'd rather hold out to see if another coworker actually needs the car, because I also like the warm fuzzy feeling of knowing it's helping them.

"Oh, well what if I told you the $500-1000 I think I can get from taking that work off your hands and re-selling it would really help me out"

"That makes sense. Sold"

See how easy this is without the sleaziness of lying?

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

#119
post #112

Earlier quoted context omitted.

I think regret is common. I don't think it's particularly novel to permissive licensing. Besides, most projects never reach any sort of popularity to draw a contributor count greater than 1, and relicensing at that scale is tremendously easy -- you just do it. I'm also not sure what your on about with regards to big companies vs small companies. Do you mean companies which produce open source software? Or companies c…

> Almost all companies which produce software under GPL or AGPL dual license with a commercial paid option that comes with no strings attached. Personally I find this disingenuous. There was at least for a time a trend (or at least noted by some) of using AGPL with copyright assignment[1] as a trojan horse to force customers into commercial licensing once due diligence came in. [1] I consider copyright attribution to…

Copyright attribution is necessary to avoid tombstoning the project. Imagine you have something using AGPL, and some high profile court cases change the landscape of copyright, resulting in the arrival of new, next generation licenses. For example, let's assume AGPL is defeated in court.

It is effectively impossible to adopt a different license without either:

- getting consent from all authors/copyright holders.

- removing all the contributions of any outstanding authors/copyright holders who don't/can't provide consent.

Your options are pretty bad here.

Furthermore, not having a CLA even for very permissibly licensed projects can be a poison pill for any sort of M&A, even if the project would never need to make use of it. Not using a CLA muddies the IP portfolio of the company, and many investors will spook easily at the scent of IP issues regardless of whether or not they really matter.

Unless you feel like fucking around and finding out (I don't) you get copyright assignment.

Anyways, you can always fork.

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

#120
post #113
post #70

Earlier quoted context omitted.

It's not an abuse. This is by design. It's one thing many don't get about Open Source. The goal is to not discriminate against any kind of use. If you want to discriminate users by how they use it, then you don't want open source.

Your thoughts regarding open source are borderline irrational when places like Amazon will copy and paste your repository and start making billions off of it.

What's the problem with that? If I didn't want others to use my code or make money with it, I wouldn't have gone open source in the first place.

I'd rather use an AWS service with an open source core than a closed-source service. Migrating away from AWS in the former case is arguably easier than in the latter.

And this is because of the open principle.

Post reply on HN