Name: Open Source Licensing
ISBN: 9780131487871

What Hacker News says

mindcrimeJun 2020

Is there a way to sell licenses for usage even though the source code is available freely?

You can definitely sell F/OSS for a profit. One could quibble about the semantics of whether or not you're really selling a license for "usage" or not, but I don't think that's a particularly useful distinction. Maybe the more important point is to understand that you're not really selling software in a sense. Yes, you could choose to not make binaries available unless the customer pays, but they could always build their own binaries, or get them from a third party.

So why do organizations pay companies for F/OSS at all? Well, there is the support aspect, but its not just "support" as in patches / version upgrades, and phone/email/web/whatever technical support. Those things are aspects of what an organization is paying for, but they're also paying for something more subtle. Organizations, especially larger ones, want stability and continuity. By paying your company, instead of just using your software for free, they are investing in the continued development and evolution of your project. And, yes, they're also paying to have "somebody to sue" if the shit hits the fan. Large organizations want contracts and legally binding commitments around things, and they understand that that costs money.

Can someone fork my project, change a few tiny details and the name and provide it for free without licenses?

Pretty much, yeah. You can protect trademarks, and you can always choose the route of not making the documentation available under a license that permits redistribution, and do other small things to discourage a third party from setting up to sell the same thing. But the licenses (I'm assuming some more or less standard, common-place, OSD compliant license) generally permit that.

Would having the project be free of price, but selling "support" worth it, or would they just rely on their IT department and not bother with buying it?

It depends. There would probably always be "cheapskate" orgs that would download and use the code and never engage with you. That's just part of the cost of doing business. But many organizations will buy your package, assuming it creates value for them, for the reasons mentioned above. Not to mention, their internal IT departments are probably already overworked, underfunded, and stretched thin. They would prefer to outsource the maintenance and evolution of the thing, as opposed to taking on that responsibility themselves.

The idea of FOSS sounded better as a consumer than as a supplier tbh, so I would like to know your opinion about this.

It's not for everybody. There are a lot of implications to "selling F/OSS" and you should think through them carefully and do your research before deciding. I kinda feel like this topic has been beaten to death online over the last 15 or 20 years, so there's plenty of discussion of these points for you to read over and consider. See:

https://www.google.com/search?q=open+source+business+models

One thing I would suggest, if you haven't yet, is to read

Open Source Licensing: Software Freedom and Intellectual Property Law by Lawrence Rosen.

https://www.rosenlaw.com/oslbook.htm

thread

tzsDec 2019

> ISC and MIT are functionally equivalent, which really means there are no differences.

ISC> [...] use, copy, modify, and/or distribute this software [...]

MIT> [...] use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software [...]

Note that MIT includes "sublicense". ISC does not. This is a big difference. See page 87 in chapter 5 of Rosen's "Open Source Licensing" book [1] for a discussion of the importance of this.

[1] https://www.rosenlaw.com/oslbook.htm

thread

apoFeb 2012

By far the best work on this subject has been written by Lawrence Rosen in his book "Open Source Licensing":

http://www.rosenlaw.com/oslbook.htm

Free to read online - or buy a hardcopy.

Unlike less useful works, Rosen actually provides a model for thinking about open source models. Even if you only care about commercial software licensing, this this information in this book will be valuable.

thread

an1sotropyFeb 2024

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 intended in adversarial commericial settings [2,3].

[1] https://www.oreilly.com/library/view/open-source-licensing/0...

[2] https://www.tp-link.com/us/support/gpl-code/

[3] https://www.zdnet.com/article/software-freedom-conservancy-w...

thread

gsylvieMar 2017

IANAL. I'm just a random person who studied the book, "Open Source Licensing: Software Freedom and Intellectual Property Law," by Lawrence Rosen.

The OP doesn't mention D.4 much. The first paragraph of D.4 seems fine to me. But I worry the "clarification" (2nd paragraph) in D.4 could potentially cause problems:

> That means you're giving us the right to do things like reproduce your content (so we can do things like copy it to our database and make backups); display it (so we can do things like show it to you and other users); modify it (so our server can do things like parse it into a search index); distribute it (so we can do things like share it with other users); and perform it (in case your content is something like music or video).

Is "modify it" the same as "create derivative works"? If so, seems you've granted Github the right to "modify it" and "distribute it" potentially without any restrictions.

thread

drewcrawfordMay 2016

Saying that licenses should be readable to software developers is like saying sourcecode should be readable to lawyers. It's a nice idea, but in the real world, even problems as simple and universal as loading an image over HTTPS is totally impenetrable to anyone outside the software development profession.

It is the same for the law. Even the basic "email-grade" legal problems are actually very complicated, and it is no good trying to simplify them down to a lay level. I'll defer to Lawrence Rosen on this, from his book Open Source Licensing: Software Freedom and Intellectual Property Law:

> The same programmers who cringe when a lawyer attempts to write high-quality software feel no qualms about writing their own open source licenses. Their goal, it appears, is to craft something that sounds like a license, to define a form of software freedom with reasonable terms and conditions, and then wait for the community to adopt the license and distribute software under it. This technique sometimes works. Some members of the open source community are more concerned with mak- ing a philosophical statement, getting free software distributed to the world, and letting license enforcement take care of itself somehow in the future. That can be a commendable goal, but from a lawyer’s perspective, it is amateurish and risky.

The reason that BSD/MIT seem readable to you is actually that they lack a lot of clarity on important points. For example, they say nothing at all about patents, which is the primary type of software litigation today. So an Oracle-type could offer you software under an MIT license, and then turn around and sue you under patent law for using the software they offered you. Whether they would win is an interesting question, but we will not find out because you will settle.

Meanwhile, Apache2 or GPL3 or other post-1970s licenses have actual clauses to deal with this. So now your lawyer can print out the license, highlight a sentence, scribble "SEE?" below it, add "Respectfully submitted, John Smith Esq." at the bottom and that is the end of your lawsuit.

thread