Linked by Hadrien Grasland on Sat 8th Jan 2011 19:28 UTC, submitted by sjvn
GNU, GPL, Open Source Some people swore to me that just because the free-software General Public License (GPL) clashes with the Apple App Store's Terms of Service (ToS), didn't mean that Apple would actually pull down GPLed apps. Well, Apple just did. Remi Denis-Courmont, a Linux developer of the popular VLC media player, has just announced that Apple had pulled the popular GPLed VLC media player from its App Store.
Thread beginning with comment 456683
To view parent comment, click here.
To read all comments associated with this story, please click here.
sean
Member since:
2005-06-29

"This mess doesn't affect me either, I avoid GPL'ed software like plague unless they're absolutely necessary.


If you write your own code, it is your code, so you may do with that whatever you wish.

If you don't write code, GPL software won't bite you, you know. You are absolutely free to run it without restriction. Fill your boots. Have a ball.

If you want to use someone else's GPL code in conjunction with your work, keep it separated from your work. Do not include any GPL source code actually within your work, but rather write your own code to run "on top of" GPL code. Here is an example of a company with a proprietary product which has done just that:
http://www.bricsys.com/common/news.jsp?ksearch=Linux

If you want to re-distribute someone else's GPL code, then simply re-distribute their source code as well. Its their code anyway, no skin of your nose to re-distribute it even as source code.

You do not have to distribute source code for your work, if you do not want to, if it was actually your work.

So, please explain, what exactly is your reason for avoiding GPL code? I'm peplexed, I truly am.
"

I also avoid GPL software when I can. As a developer that uses a more liberal license (BSD in my case but MIT license would also do), I avoid it, for one reason, because the philosophy behind the license is exclusive. If you go to FSF's website, you will see a list of licenses that are or are not compatible with GNU licenses. You will notice that it does not phrase it as what GNU licenses are compatible with. Yes, it is a small difference, but it demonstrates an attitude against others. For a comparison, consider how software packages mention compatibility. They say they will work on an OS; they do not say an OS is compatible with them.

If I write BSD-licensed software and link it against GPL-licensed software, I have to redistribute it under the GPL license according to the FSF. The MPL or CDDL do not have this issue as long as I keep the code apart in separate files. Although they are friendlier licenses, I still prefer BSD/MIT licenses since they are closer to altruistic sharing than the others. If I shared something with somebody, I would not view it as nice to require anything back in return.

This post is not intended as flamebait, but I could not help seeing a similarity between Digital Rights Management (DRM) and GNU licenses. Both try to control the usage (development in my eyes is a type of usage). The phrase "Source Rights Management" (SRM) had actually popped into my head.

BTW, as for Apple, I did not see them being at fault in this case. While I may be very wary of their control over their devices, they did not attempt to distribute anything. Someone else tried to distribute VLC over Apple's system against the terms of the GPL; if someone is to be sued, that is the person who should be sued for placing the binary in a place it could not be redistributed. Of course, the source availability of the binary did comply with the terms of the GPL; this was just about the binary.

Reply Parent Score: 3

UltraZelda64 Member since:
2006-12-05

They say they will work on an OS; they do not say an OS is compatible with them.

Are you sure?

Windows Vista Compatibility Center:
http://www.microsoft.com/windows/compatibility/windows-vista/

Windows 7 Compatibility Center:
http://www.microsoft.com/windows/compatibility/windows-7/en-us/defa...

As for the specs included with individual software, obviously no one is going to waste their time listing hundreds of 100% irrelevant operating systems. It would be a waste of their time and leave the user wondering, "well what the f*** is this POS compatible with, then?" without even bothering to read all that garbage.

Basically, that's a poor comparison; there are obvious reasons why you don't list operating systems that are *not* compatible, starting with the fact that it would be a completely useless piece of information to go by (and seemingly never-ending with all the different choices out there).

There's a reason why proprietary Linux software doesn't list 125-150 of the 300+ distributions out there, and instead choose to mention general specifications such as "Linux 2.6 kernel, glibc x.x.x and up; OpenGL hardware acceleration; OSS or Alsa, etc.," or even something more general like "Most major Linux distributions from around 2007" or whatever.

It sounds like you're complaining about nothing more than language--and in this case I honestly see nothing to complain about to begin with. I don't see any negativity; just facts, on the page you referred to.

Edited 2011-01-10 04:13 UTC

Reply Parent Score: 2

lemur2 Member since:
2007-02-17

I also avoid GPL software when I can. As a developer that uses a more liberal license (BSD in my case but MIT license would also do), I avoid it, for one reason, because the philosophy behind the license is exclusive. If you go to FSF's website, you will see a list of licenses that are or are not compatible with GNU licenses. You will notice that it does not phrase it as what GNU licenses are compatible with. Yes, it is a small difference, but it demonstrates an attitude against others. For a comparison, consider how software packages mention compatibility. They say they will work on an OS; they do not say an OS is compatible with them.

If I write BSD-licensed software and link it against GPL-licensed software, I have to redistribute it under the GPL license according to the FSF. The MPL or CDDL do not have this issue as long as I keep the code apart in separate files. Although they are friendlier licenses, I still prefer BSD/MIT licenses since they are closer to altruistic sharing than the others. If I shared something with somebody, I would not view it as nice to require anything back in return.


If I wrote code that I wanted everyone to share, I would not view it as nice if someone took a copy of my code and refused to share it. This can happen to my code if I license it as BSD/MIT. The GPL simply adds a stipulation beyond BSD/MIT that in effect says: "I shared this with you, you may use it however you like but if you give it to others you must share it with them just as I have shared it with you".

Sorry, but I simply can't agree with any argument that wishes to characterise that position as unreasonable in any way or failing somehow as not being "altruistic sharing".

As for your comments re linking:

LGPL is absolutely safe, as it specifically allows linking (even static linking). Most libraries are LGPL, not GPL.

Despite what the FSF say, copyright law itself allows dynamic linking ... if a later work does not actually INCLUDE any major elements of earlier works, then it does not infringe copyright law.

See:
http://www.osnews.com/permalink?456652

Edited 2011-01-10 06:28 UTC

Reply Parent Score: 2

vodoomoth Member since:
2010-03-30


If I wrote code that I wanted everyone to share, I would not view it as nice if someone took a copy of my code and refused to share it. This can happen to my code if I license it as BSD/MIT. The GPL simply adds a stipulation beyond BSD/MIT that in effect says: "I shared this with you, you may use it however you like but if you give it to others you must share it with them just as I have shared it with you".

I don't know how many times I have been schooled by you here but I wish there'll be many more.

On topic (and on quote so to speak), the reason that some avoid GPL (and I've written it in a previous comment) is a wording/understanding problem. Read a BSD license, you immediately know you can use it in any way you please. I'm very Java these last years so I also know the Apache license is similar in that respect. With GPL, until I read your explanations in several comments, I could not have told someone: "yes you can use GPL even in a proprietary closed-source commercial product, you just have to link to it instead of embedding it in your source code". And honestly, for those who are not native English speakers (like me), it's not that easy to understand. And sections like "Linking and derived works" of the Wikipedia article don't help in clarifying what can and cannot be done. Even your "LGPL is absolutely safe, as it specifically allows linking (even static linking). Most libraries are LGPL, not GPL." doesn't tell explicitly whether I can use or statically/dynamically link to GPL-licensed code. So in case my commercial product uses a library that, unfortunately, happens to be GPL instead of LGPL, what should I do, point the users to where they can download the library and its source code should they wish to?

Last point, I think no one is safe from bona fide errors and from some lazy-sloppy-doesn't-care-should-be-fired-rightaway developer. This is a risk I'm not sure I'd be willing to take were I to have a company like I hope.

P.S. can you explain how multi-licensing works with GPL?

Reply Parent Score: 2

vtolkov Member since:
2006-07-26

Absolutely agree. I like the "SRM" analogy. Exactly!

Another thing, that BSD license only require you to respect the author. And you can do whatever you want with this code, but you have to respect the author by mentioning his name. Like if you cite someone in your publication, you need to give a reference. But GPL is opposite, it values code as the only value, not its authors, there are no names, there is only code and when this code touches another code it also becomes GPLed. Kind of "bite of GPL". I also avoid GPL as a developer, because I consider this non-ethical and antihuman.

Reply Parent Score: 0