The issue of licensing

I usually choose MIT too for new projects. I’m not a programmer writing high quality software that many people reuse. So the simplicity wins here.

Larger FOSS projects of course should take care more about their licensing. And they do.

But I don’t know what that means. I GPL my code; it links to SomeMITThing; SomeMITThing starts requiring a proprietary dependency; my code is now not OK and not usable despite me not doing anything, right? I went to bed one night and woke up to an email from @stephenrwalli saying “why can’t people use your code in enterprise?”, and he’s right, and all I did was have a scrummy dream about ponies and not change any code at all.

If I were being funded to write a thing that’d take two years then I’d spend some paid time working out which licence to use; that’s correct advice and due diligence. If I were self-funding… dunno. Might just save myself the two days wages and pick MIT at the outset.

I don’t think they’re allowed to. They can use MIT libs or Python licence libs, and there’s an exception for stuff which comes as part of your OS, but as far as I’m aware if you write a proprietary Python app you don’t get to use GPL libraries from PyPi in it. And… now I’m spending too long thinking about this again :slight_smile:

2 Likes

Nope, Python is permissively licensed, closed-source applications can’t import GPL’d Python modules (not trivially at least).

It cuts both ways, if you depend on any other projects - they might change their licenses to be incompatible with your software or each-other… (ignore the fact you can depend on old software indefinitely… technically true - the cost of becoming the maintainer is often not worth it).

While its not unheard of - in practice the kind of mature projects your likely to depend on projects aren’t changing their license on a regular basis, so find your example a bit strange.

That is, I think, evidence that we’re in different coding worlds. A node project might have, transitively, a few hundred dependencies, some of which are only a few lines long. A GNU project might have three large, fairly static, fairly unchanging mature dependencies. Does what you’re saying (“your dependencies and their dependencies won’t change much”) work well in that GNU world? Yep. Does it work well in a much more granular world? I am much less sure.

(Some would now say “this is evidence that having many small dependencies is in itself a bad idea! stupid node people doing it wrong!” but I hope our community is above that. Besides, it’s only an inconvenient thing to do if you’re worried about this sort of GPL issue, and that’s equally-well expressible as the GPL is only written for large monolithic projects, I think.)

[quote=“sil, post:65, topic:11045”]
That is, I think, evidence that we’re in different coding worlds. A node project might have, transitively, a few hundred dependencies, some of which are only a few lines long. A GNU project might have three large, fairly static, fairly unchanging mature dependencies. Does what you’re saying (“your dependencies and their dependencies won’t change much”) work well in that GNU world? Yep. Does it work well in a much more granular world? I am much less sure.[/quote]

Looks like it! out of curiosity, is node community unusual in this respect?
Note that I was referring only to changing licenses not happening often, the code its self may be under active development. Projects I’ve worked on had more like 20-30 deps… but not 100’s for sure.

Wouldn’t say it’s bad - but there are trade-offs to having many dependencies, for C/C++ applications there are many practical concerns (licensing issues aside), just having to build them on all supported platforms… binary size, keeping up with changes to their API’s takes time, so its worth avoiding the overhead if you don’t need to add dependencies.

It’s more pathological than most, shall we say :slight_smile:

I find this example rather contrived - assuming someone considering spending years to start a new software project has no idea about licensing and how it will impact their project.
As if you would also spend 2 days to pick a programming language and still more to pick version-control and text-editor.

It was your example! I just answered a question that you asked me.

Anyway, I absolutely would spend a couple of days, if not more, deciding on which programming language to use on a multi-year project!

Ah well, if you include research and experimentation in “starting a project”, you could spend a lot longer too.

Am not really that fussed - but if someone told me they had started writing a novel, but were actually learning some different languages since they weren’t sure which to use…
I would be a perplexed!

For what it’s worth, the FSF has a webpage describing what GPL compatibility means and a list of GPL compatible licenses:

you can combine code released under the other license with code released under the GNU GPL in one larger program.

Based on that information, it seems to be perfectly fine to take a BSD, MIT, or Apache 2.0 licensed library as a dependency and have the whole work be under the GPLv3 for example.

Having said that, I don’t agree with the idea that the GPL losing market share is a bad thing. The GPL was created specifically for the needs of the GNU project and the FSF doesn’t deny the legitimacy or usefulness of non-GPL licenses for other projects. Every FOSS project is going to have its own goals and legal needs so BSD/MIT/Apache/whatever doesn’t matter because they are all Free Software :slight_smile:

As the CIO article with the Linus interview posted earlier stated, the GPL is really about sharing contributions and building a community in large projects. For one-off scripts, small solo projects, and code you don’t care that much about the choice of license in most cases frankly doesn’t matter. Larger projects with sustaining contributors should and do care about their licensing.

2 Likes

Well, I think GPLv3 and AGPL everywhere would be ideal, and then license compatibility ceases to be an issue.

…but back in the real world, there are other considerations. We have a contradiction in which I think GPL is most important in large projects - GCC and the Linux kernel wouldn’t be what it is today if Linus had started out with a BSD-like license. Arguably LLVM wouldn’t exist and be as good as it is if there were not companies interested in alternatives to GCC.

But while GPL is most important in large projects, it’s only straightforward and effortless to use in tiny ones. If you have no dependencies or all of your dependencies are GPL or LGPL, then GPL is an easy choice. Otherwise, the headache starts.

1 Like

Exactly my point.

I’d just like to add that the GPL is also the only license, to my knowledge, also intended to protect the Freedoms of the end user (the average everyday non-technical Jane and Joe six packs of the world) and not just the developer. I think when someone chooses it, it’s a good sign that they’ve thought of the user :slight_smile:

But is it true, though?

I’ve seen a few commercial, closed-sourced products releasing the source code of the GPL libraries and tools they’re using (because they have to). Basically they just host a zip file on their website with an outdated version of the library source code and that’s it.

After seeing that, my understanding was that in the end, GPL was not that much of a problem even for companies… Am I wrong?

If a company uses, and distributes, a GPL tool, then they do indeed have to provide only the source code of that tool, and only for the version they distribute. That’s all good.

Libraries are a very different matter. A library is not a stand-alone thing; it’s used as an integral part of a larger program (the technical term here is linking). Tools are like the separate items in your kitchen drawer: big knives, ladles, whisks, forks. They’re all related and they all work on the same thing (food, or data) but they are independent items. Libraries are like ingredients in the meal you’re cooking – eggs, flour, water, yeast. The final article – the pie you’ve made – combines them all together into a whole thing which is different from and more than its ingredients.

Here’s the point about the GPL: if you use a GPLed library in your program, then you must release the source code of the whole program, not just the GPLed library. That’s exactly what the GPL is designed to make you do, even if you don’t want to.

So, any commercial, closed-source product which uses a GPL library in that product and doesn’t release all the source of that product is breaking the GPL and is therefore liable.

However, they may be doing any of the following, all of which are OK: releasing source for a GPLed tool they’re using while carefully not linking any GPLed libraries into their main program; using libraries which are free software but under a non-copyleft licence (BSD, MIT, Apache, etc) and not releasing their source; using libraries under the LGPL and releasing their changes to that library but not to the program it’s linked to.

1 Like

Thanks a lot for that clear explanation. Everything makes much more sense to me now!

The libraries I had in mind was something like libpng or zlib, both of them having a not-GPL license it seems. So you’re correct, any closed-source program using these don’t have to release anything else.

An effort from github. It solves 0.4% of the problem, but that’s more than nothing.

“when you view a repository’s license, we’ll tell you a bit more about it.”

This only helps people who already want to vote the license, and therefore don’t need the help that @stephenrwalli wants them to have, but it’s a tiny toe in the water of actually giving a shit about this issue. More pressure definitely required.

Helping @sil on a different understanding of the licensing problem. Please ignore.