Linked by Thom Holwerda on Sat 21st Apr 2012 19:25 UTC
GNU, GPL, Open Source "A new analysis of licensing data shows that not only is use of the GPL and other copyleft licenses continuing to decline, but the rate of disuse is actually accelerating." This shouldn't be surprising. The GPL is complex, and I honestly don't blame both individuals and companies opting for simpler, more straightforward licenses like BSD or MIT-like licenses.
Thread beginning with comment 515153
To read all comments associated with this story, please click here.
Practical considerations
by jessesmith on Sun 22nd Apr 2012 01:43 UTC
jessesmith
Member since:
2010-03-11

Personally, as an open source developer, I try to choose the license with the least restrictions possible. The reason is simply that it makes it easier for people to use my code in the future and it avoids all sorts of little gatchas.

It's not even the closed source vs open source issues which make GPL a pain to work with. The GPL is hard to work with for open source projects too. For example....

Linux can't include ZFS in the mainline kernel, even though both the kernel and ZFS are open source. It's a problem BSD projects don't have.

GPLv2 and GPLv3 aren't compatible, which was a huge mistake. It means if two projects were both GPLv2 and were sharing patches, and then one project updates to GPLv3 the code can only flow in one direction.

GRUB Legacy (GPLv2) can use signing keys for secure booting, but GRUBv2 (which is GPLv3) can't.

I use the GPLv2 from time to time, but it throws up walls to cooperation. I don't think that's healthy. The GPL has its place, but most of the time it is more trouble than it is a help, especially since GPLv3 came out.

Reply Score: 3

RE: Practical considerations
by Excarnate on Sun 22nd Apr 2012 04:30 in reply to "Practical considerations"
Excarnate Member since:
2011-08-01

Personally, as an open source developer, I try to choose the license with the least restrictions possible.

So you release all your code into the public domain?

Reply Parent Score: 5

galvanash Member since:
2006-01-25

Personally, as an open source developer, I try to choose the license with the least restrictions possible.

So you release all your code into the public domain?


He said "license with the least restrictions possible". He didn't say "give up copyright". Copyright has built in restrictions - licenses can either expand them or relax them - all the way to the point where it has no legal ramification other than being a simple authorship acknowledgement.

You can't license software into the public domain - public domain software has no owner. You need an owner in order to license something. It is simply absent of copyright.

Reply Parent Score: 5

RE[2]: Practical considerations
by pfgbsd on Mon 23rd Apr 2012 02:37 in reply to "RE: Practical considerations"
pfgbsd Member since:
2011-03-12

"Personally, as an open source developer, I try to choose the license with the least restrictions possible.

So you release all your code into the public domain?
"

If people in Africa could *eat* code, it would be our obligation to make all software public domain.

Reply Parent Score: 0

RE: Practical considerations
by Lennie on Sun 22nd Apr 2012 08:52 in reply to "Practical considerations"
Lennie Member since:
2007-09-22

I think ZFS is a bad example, as it is an exception. Not the rule. Lots of people think CDDL was specifically choosen to prevent it from being part of the Linux kernel.

Reply Parent Score: 7

RE: Practical considerations
by Valhalla on Sun 22nd Apr 2012 12:36 in reply to "Practical considerations"
Valhalla Member since:
2006-01-24

Personally, as an open source developer, I try to choose the license with the least restrictions possible.

That's your choice and I applaud your generosity.


Linux can't include ZFS in the mainline kernel, even though both the kernel and ZFS are open source. It's a problem BSD projects don't have.

And the BSD projects can't use GPL licenced code while Linux don't have that problem and can use BSD licenced code, go figure.

The reason ZFS is incompatible with GPL was by design as Sun was facing severe competition from Linux and didn't want to allow it to use their key technology.


GPLv2 and GPLv3 aren't compatible, which was a huge mistake. It means if two projects were both GPLv2 and were sharing patches, and then one project updates to GPLv3 the code can only flow in one direction.

Eh? The GPLv2 licence says 'or later', so unless the 'GPLv2' project has removed the 'or later' clause then they are in no way incompatible. Only project I know of which has done so is Linux, however even here it's not the end of the road as you can dual-licence your code.


GRUB Legacy (GPLv2) can use signing keys for secure booting, but GRUBv2 (which is GPLv3) can't.

It's only incompatible with signing keys for secure booting if it doesn't allow the end user to sign keys, like with UEFI on Microsoft approved ARM machines. If the end user is allowed to sign keys to be valid then there's no problem with GPLv3.

Personally I see this as a great feature of GPLv3 as I don't want hardware which is artificially crippled to only boot code signed by a third party.

Reply Parent Score: 5

jessesmith Member since:
2010-03-11

>> "Eh? The GPLv2 licence says 'or later', so unless the 'GPLv2' project has removed the 'or later' clause then they are in no way incompatible. Only project I know of which has done so is Linux, however even here it's not the end of the road as you can dual-license your code."

Just because you don't know about them doesn't mean they don't exist. Have you actually read the licenses of all the software you use? I can think of about half a dozen, besides the Linux kernel, which don't specify the "or later" version and won't (or can't) update to GPLv3.

Reply Parent Score: 1