71–80 of 198 posts
It was a good idea to post this to HN. Back when I was an LLVM contributor I was using an email address from a provider who is no longer around. I had no idea that the LLVM maintainers were trying to get a hold of me. There's probably a lot of overlap between LLVM contributors and HN readers.
Which provider? What was their domain name?
Earlier quoted context omitted.
Wikipedia changed its license around 10 years ago, I think.
Wikipedia was licensed under GFDL 1.2 or later, so relicensed by convincing the FSF to release an updated version of the GFDL (version 1.3) that adds a very narrowly worded clause allowing relicensing that pretty much only applied to Wikipedia.
Earlier quoted context omitted.
Wikipedia changed its license around 10 years ago, I think.
Wikipedia was licensed under GFDL 1.2 or later, so relicensed by convincing the FSF to release an updated version of the GFDL (version 1.3) that adds a very narrowly worded clause allowing relicensing that pretty much only applied to Wikipedia.
> An MMC [Massive Multiauthor Collaboration Site] is "eligible for relicensing" if it is licensed under this License, and if all works that were first published under this License somewhere other than this MMC, and subsequently incorporated in whole or in part into the MMC, (1) had no cover texts or invariant sections, and (2) were thus incorporated prior to November 1, 2008.
> The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on the same site at any time before August 1, 2009, provided the MMC is eligible for relicensing.
This kind of thing feels like such a waste of humanity's time. Is there an approach you can choose early in a project on that prevents ever getting in trouble later? I guess if I start some big library I will hope that everyone assigns the copyright for their contributions entirely to the project so that I never have to go through that nonsense. But I guess that has other ramifications.
> Is there an approach you can choose early in a project on that prevents ever getting in trouble later? 1. Never accept outside contributions in principle. Works fine for SQLite, for example. 2. Pick a well-known copyleft license and just stick with it. Works fine for Linux, for example. 3. Use a well-known permissive license that allows redistribution of modified code under a different license without burdensome co…
6. Have a CLA (contributor license agreement) that lets the project the right to change the licence. (Different from 4. because there is no copyright transfer).
Is Rafael de Espindola on that list? He seems to have left on not that great terms and I can imagine him not being interested in supporting a license change. He was a prolific contributor.
Earlier quoted context omitted.
Out of curiosity, how does the GPL promise that versus the other common open source licenses? E.g MIT, BSD or Apache?
As I understand it: MIT code can be freely taken into proprietary fork, with software modified and sold and no patches contributed. Not sure how often it happens? Has it actually happened and is it a plausible attack? Nowadays at least AGPL is needed to defang "and we will sell it as service rather than selling software" workaround for GPL.
These are things some projects like to do, and GPL blocks that. So all thing considered, it may be easiest to just not use GPL code.
Earlier quoted context omitted.
Out of curiosity, how does the GPL promise that versus the other common open source licenses? E.g MIT, BSD or Apache?
GPL software, and extensions to it, are free and will stay like that. That can't be said about software under the above mentioned licenses.
Earlier quoted context omitted.
Yeah, agree it is hotly debated and not worth discussing further. I've recently been bitten by GPL and it's fresh on my mind how insidious it can be. That said, I work in commercial environment where BSD-licensed software is highly regarded.
Saying that corporations prefer something they can profit from without giving back vs something they can not is circular reasoning to me. Conversely if you look on the other side you'll see developers bitten by permissive software licences (MongoDB, Elasticsearch, ...).
I prefer the MPLv2, it lets commercial users actually use the code, but they still have to contribute back any changes they make.
Racket had to do this to go from lGPL to Mit, it was a long process. But they did it to make the language more accessible to developers. Developers are scared away by lGPL. Not all contributions were relicensed (resulting in code being rewritten), and we lost some code in the standard library (the csv parser). Now Racket is trying to make it more friendly to people by created a new language (called Rhombus for now) t…
For me it's very much the opposite, I refuse to contribute code to anything licensed under the MIT/BSD/etc family of languages.
It makes me sad to see so much confusion, incorrect information, naiveté and paranoia going around regarding the GPL that it's scaring people off. I think that most of these people would feel differently if they understood better.
I think the systematic defanging and watering down of the free software movement is a great loss.
Earlier quoted context omitted.
As I understand it: MIT code can be freely taken into proprietary fork, with software modified and sold and no patches contributed. Not sure how often it happens? Has it actually happened and is it a plausible attack? Nowadays at least AGPL is needed to defang "and we will sell it as service rather than selling software" workaround for GPL.
As a practical matter, it means you cant just copy the files into your sources to some subdir, or you cant just link it statically. So you cant release a single-exe version of your project. These are things some projects like to do, and GPL blocks that. So all thing considered, it may be easiest to just not use GPL code.
And you can statically link GPL code, assuming you release the source to all app users. You might be confusing it with LGPL, which says you can link to proprietary apps dynamically, but have to release source in all other cases.