Re: GNU License warning:

2017-01-18 Thread Kagamin via Digitalmars-d

On Friday, 13 January 2017 at 02:25:03 UTC, Ignacious wrote:
Licenses should be more specific in their terminology and their 
behaviors and effects rather than using arbitrary divisions.


If your plugin uses contrived API riddled with all good C(++) 
misfeatures to customize like 80% of program's functionality - it 
thus creates a competing proprietary product, which is what GPL 
tries to prevent. AFAIK it doesn't allow you to use complex API 
with out of process plugins either. With this division of API GPL 
tries to control what a plugin can do to the host application, 
namely it tries to keep degree of integration and complexity of 
the plugin API low. If you know a better way to do it, you can 
propose it to FSF, that's also why GPL addresses automatic 
license upgrade.


Re: GNU License warning:

2017-01-13 Thread Ignacious via Digitalmars-d

On Saturday, 14 January 2017 at 01:40:58 UTC, Chris M. wrote:

On Friday, 13 January 2017 at 21:53:29 UTC, Ignacious wrote:

On Friday, 13 January 2017 at 19:30:40 UTC, Chris Wright wrote:

On Fri, 13 Jan 2017 15:19:57 +, Ignacious wrote:

[...]


LGPL is much more common, and LGPL isn't a problem when you 
distribute by source. It *is* a problem with static linking 
with binary distributions (which is the default for D).


This is not a new issue. Software licensing is a well 
understood, well publicized concern. It doesn't merit 
alarmism.


Sure it does! Stop being a Nazi war criminal wanna be! Do you 
work for the FOSSF? Otherwise known as the F-OSS-F = Future - 
Office of Strategic Services - Foundation.


What is this thread accomplishing other than ranting about GPL 
and calling others Nazis?


Quite a bit! I has solved the mysteries of the universe and shown 
that you are a Hitler sympathizer and progressteron.


Re: GNU License warning:

2017-01-13 Thread Chris M. via Digitalmars-d

On Friday, 13 January 2017 at 21:53:29 UTC, Ignacious wrote:

On Friday, 13 January 2017 at 19:30:40 UTC, Chris Wright wrote:

On Fri, 13 Jan 2017 15:19:57 +, Ignacious wrote:

[...]


LGPL is much more common, and LGPL isn't a problem when you 
distribute by source. It *is* a problem with static linking 
with binary distributions (which is the default for D).


This is not a new issue. Software licensing is a well 
understood, well publicized concern. It doesn't merit alarmism.


Sure it does! Stop being a Nazi war criminal wanna be! Do you 
work for the FOSSF? Otherwise known as the F-OSS-F = Future - 
Office of Strategic Services - Foundation.


What is this thread accomplishing other than ranting about GPL 
and calling others Nazis?


Re: GNU License warning:

2017-01-13 Thread Ignacious via Digitalmars-d

On Friday, 13 January 2017 at 19:30:40 UTC, Chris Wright wrote:

On Fri, 13 Jan 2017 15:19:57 +, Ignacious wrote:
Yes, but D uses mostly bindings and if any of those bindings 
use it then It effects the D program that uses it. Since many 
of the bindings are written in C/C++ one can expect that many 
of them use the GPL license.


LGPL is much more common, and LGPL isn't a problem when you 
distribute by source. It *is* a problem with static linking 
with binary distributions (which is the default for D).


This is not a new issue. Software licensing is a well 
understood, well publicized concern. It doesn't merit alarmism.


Sure it does! Stop being a Nazi war criminal wanna be! Do you 
work for the FOSSF? Otherwise known as the F-OSS-F = Future - 
Office of Strategic Services - Foundation.







Re: GNU License warning:

2017-01-13 Thread Chris Wright via Digitalmars-d
On Fri, 13 Jan 2017 15:19:57 +, Ignacious wrote:
> Yes, but D uses mostly bindings and if any of those bindings use it then
> It effects the D program that uses it. Since many of the bindings are
> written in C/C++ one can expect that many of them use the GPL license.

LGPL is much more common, and LGPL isn't a problem when you distribute by 
source. It *is* a problem with static linking with binary distributions 
(which is the default for D).

This is not a new issue. Software licensing is a well understood, well 
publicized concern. It doesn't merit alarmism.


Re: GNU License warning:

2017-01-13 Thread Ignacious via Digitalmars-d

On Friday, 13 January 2017 at 15:56:40 UTC, Claude wrote:

On Friday, 13 January 2017 at 15:15:14 UTC, Ignacious wrote:

On Friday, 13 January 2017 at 12:01:22 UTC, bachmeier wrote:
This is not the proper place to blog about software license 
preferences or to make unsubstantiated accusations against an 
organization you don't like. There are other sites for that.


So, what is up with all the wanna be Nazi's running around 
today? Did Hitler come out of retirement??


Retirement?? I thought he commited suicide...


Of course that is what *they* want you to believe. He was simply 
biding his time while his little Nazi army infiltrated every 
aspect of human life. The goal is obfuscation and negativity. 
They realized they couldn't win on firepower so they moved on to 
more powerful psychological warfare tactics.






Re: GNU License warning:

2017-01-13 Thread Chris Wright via Digitalmars-d
On Fri, 13 Jan 2017 15:15:14 +, Ignacious wrote:

> On Friday, 13 January 2017 at 12:01:22 UTC, bachmeier wrote:
>> On Friday, 13 January 2017 at 02:25:03 UTC, Ignacious wrote:
>>> [...]
>>
>> This is not the proper place to blog about software license preferences
>> or to make unsubstantiated accusations against an organization you
>> don't like. There are other sites for that.
> 
> So, what is up with all the wanna be Nazi's running around today?
> Did Hitler come out of retirement??

Nobody's committing genocide here. Nobody is producing murder factories. 
Nobody's even being authoritarian. One person is saying that they don't 
think this is a productive place to discuss this issue.


Re: GNU License warning:

2017-01-13 Thread Claude via Digitalmars-d

On Friday, 13 January 2017 at 15:15:14 UTC, Ignacious wrote:

On Friday, 13 January 2017 at 12:01:22 UTC, bachmeier wrote:
This is not the proper place to blog about software license 
preferences or to make unsubstantiated accusations against an 
organization you don't like. There are other sites for that.


So, what is up with all the wanna be Nazi's running around 
today? Did Hitler come out of retirement??


Retirement?? I thought he commited suicide...


Re: GNU License warning:

2017-01-13 Thread Ignacious via Digitalmars-d

On Friday, 13 January 2017 at 06:37:42 UTC, Joakim wrote:

On Friday, 13 January 2017 at 02:25:03 UTC, Ignacious wrote:

On Friday, 13 January 2017 at 01:27:02 UTC, Chris Wright wrote:

[...]


That makes no sense(it's obvious by the definition of 
derivative so you are not saying anything meaningful/useful). 
Obviously if you build an independent work you are free to 
chose a license and no one building any work off of yours or 
not can cause you problems.


[...]


I agree with you that the GPL is badly written, but we mostly 
don't use it, basically only for the gdc compiler itself, so 
not a big deal here.


Yes, but D uses mostly bindings and if any of those bindings use 
it then It effects the D program that uses it. Since many of the 
bindings are written in C/C++ one can expect that many of them 
use the GPL license.


The boost license seems acceptable but who knows? Look how many 
were "swindled" by GPL.




Re: GNU License warning:

2017-01-13 Thread Ignacious via Digitalmars-d

On Friday, 13 January 2017 at 12:01:22 UTC, bachmeier wrote:

On Friday, 13 January 2017 at 02:25:03 UTC, Ignacious wrote:

[...]


This is not the proper place to blog about software license 
preferences or to make unsubstantiated accusations against an 
organization you don't like. There are other sites for that.


So, what is up with all the wanna be Nazi's running around today? 
Did Hitler come out of retirement??


Re: GNU License warning:

2017-01-13 Thread bachmeier via Digitalmars-d

On Friday, 13 January 2017 at 02:25:03 UTC, Ignacious wrote:

You haven't really said anything relevant to the post.

The issue is with how the GPL defines proper use of 
pre-existing works. The ultimately point is that they 
arbitrarily decide how a work uses another based on "fork and 
exec" and "library". My point is that those are ultimately 
artificial because whether we call a function/app through a 
library or through a command line, they are effectively the 
same(the difference being performance/convenience, which is the 
whole point of loading a library vs using the command line).


They admit this in the gpl FAQ(if you read it you will see) but 
the fact that they still create arbitrary division suggests the 
license is somewhat meaningless/incompetent.


Licenses should be more specific in their terminology and their 
behaviors and effects rather than using arbitrary divisions.


Also, while not proof, the fact that the majority of donations 
to the foundation go to the lawyers(if true) also suggest that 
it is somewhat of a scam(at the very least, something is fishy).


This is not the proper place to blog about software license 
preferences or to make unsubstantiated accusations against an 
organization you don't like. There are other sites for that.


Re: GNU License warning:

2017-01-12 Thread Joakim via Digitalmars-d

On Friday, 13 January 2017 at 02:25:03 UTC, Ignacious wrote:

On Friday, 13 January 2017 at 01:27:02 UTC, Chris Wright wrote:

[...]


That makes no sense(it's obvious by the definition of 
derivative so you are not saying anything meaningful/useful). 
Obviously if you build an independent work you are free to 
chose a license and no one building any work off of yours or 
not can cause you problems.


[...]


I agree with you that the GPL is badly written, but we mostly 
don't use it, basically only for the gdc compiler itself, so not 
a big deal here.


Re: GNU License warning:

2017-01-12 Thread Ignacious via Digitalmars-d

On Friday, 13 January 2017 at 01:27:02 UTC, Chris Wright wrote:
You offer an API and someone decides to build on it using the 
GPL -- no trouble there; your work is not a derivative of 
theirs, so their copyright cannot place restrictions on your 
work.


That makes no sense(it's obvious by the definition of derivative 
so you are not saying anything meaningful/useful). Obviously if 
you build an independent work you are free to chose a license and 
no one building any work off of yours or not can cause you 
problems.


You build against an open standard and the only implementation 
is GPL -- your work is a derivative of the standard, not 
necessarily the GPL'd work.


That depends. The standard could be GPL's too. Anything can be 
copyrighted and licensed how the creator wants as long as it is 
legal. In any case, that says nothing about a single work.


You build against an open standard with an MIT licensed 
implementation and someone else builds a GPL implementation -- 
no trouble there; your work is not a derivative of theirs, so 
their copyright cannot place restrictions on your work.


You haven't really said anything relevant to the post.

The issue is with how the GPL defines proper use of pre-existing 
works. The ultimately point is that they arbitrarily decide how a 
work uses another based on "fork and exec" and "library". My 
point is that those are ultimately artificial because whether we 
call a function/app through a library or through a command line, 
they are effectively the same(the difference being 
performance/convenience, which is the whole point of loading a 
library vs using the command line).


They admit this in the gpl FAQ(if you read it you will see) but 
the fact that they still create arbitrary division suggests the 
license is somewhat meaningless/incompetent.


Licenses should be more specific in their terminology and their 
behaviors and effects rather than using arbitrary divisions.


Also, while not proof, the fact that the majority of donations to 
the foundation go to the lawyers(if true) also suggest that it is 
somewhat of a scam(at the very least, something is fishy).









Re: GNU License warning:

2017-01-12 Thread Chris Wright via Digitalmars-d
You offer an API and someone decides to build on it using the GPL -- no 
trouble there; your work is not a derivative of theirs, so their 
copyright cannot place restrictions on your work.

You build against an open standard and the only implementation is GPL -- 
your work is a derivative of the standard, not necessarily the GPL'd work.

You build against an open standard with an MIT licensed implementation  
and someone else builds a GPL implementation -- no trouble there; your 
work is not a derivative of theirs, so their copyright cannot place 
restrictions on your work.


Re: GNU License warning:

2017-01-12 Thread bachmeier via Digitalmars-d

On Thursday, 12 January 2017 at 17:35:23 UTC, Ignacious wrote:

I think a license should exist that EXPLICITLY states what one 
can do with the source code and binary and what they are.


I'm not sure about what your point is with this. The GPL is 
pretty explicit about what you can do with the code. No software 
license cannot define "derivative work". That is a question of 
law.


GNU License warning:

2017-01-12 Thread Ignacious via Digitalmars-d


https://www.gnu.org/licenses/gpl-3.0.en.html
https://www.gnu.org/licenses/gpl-faq.html


http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Please%20Stop%20Using%20GNU%20Licenses
http://gng.z505.com/cult.htm


And, I should point out:


"If I write a plug-in to use with a GPL-covered program, what 
requirements does that impose on the licenses I can use for 
distributing my plug-in? (#GPLAndPlugins)


It depends on how the program invokes its plug-ins. If the 
program uses fork and exec to invoke plug-ins, then the plug-ins 
are separate programs, so the license for the main program makes 
no requirements for them.


If the program dynamically links plug-ins, and they make 
function calls to each other and share data structures, we 
believe they form a single program, which must be treated as an 
extension of both the main program and the plug-ins. This means 
you must license the plug-in under the GPL or a GPL-compatible 
free software license and distribute it with source code in a 
GPL-compliant way.


If the program dynamically links plug-ins, but the 
communication between them is limited to invoking the ‘main’ 
function of the plug-in with some options and waiting for it to 
return, that is a borderline case.
Can I apply the GPL when writing a plug-in for a non-free 
program? (#GPLPluginsInNF)


If the program uses fork and exec to invoke plug-ins, then 
the plug-ins are separate programs, so the license for the main 
program makes no requirements for them. So you can use the GPL 
for a plug-in, and there are no special requirements.


If the program dynamically links plug-ins, and they make 
function calls to each other and share data structures, we 
believe they form a single program, which must be treated as an 
extension of both the main program and the plug-ins. This means 
that combination of the GPL-covered plug-in with the non-free 
main program would violate the GPL. However, you can resolve that 
legal problem by adding an exception to your plug-in's license, 
giving permission to link it with the non-free main program.


See also the question I am writing free software that uses a 
non-free library.
Can I release a non-free program that's designed to load a 
GPL-covered plug-in? (#NFUseGPLPlugins)


It depends on how the program invokes its plug-ins. For 
instance, if the program uses only simple fork and exec to invoke 
and communicate with plug-ins, then the plug-ins are separate 
programs, so the license of the plug-in makes no requirements 
about the main program.


If the program dynamically links plug-ins, and they make 
function calls to each other and share data structures, we 
believe they form a single program, which must be treated as an 
extension of both the main program and the plug-ins. In order to 
use the GPL-covered plug-ins, the main program must be released 
under the GPL or a GPL-compatible free software license, and that 
the terms of the GPL must be followed when the main program is 
distributed for use with these plug-ins.


If the program dynamically links plug-ins, but the 
communication between them is limited to invoking the ‘main’ 
function of the plug-in with some options and waiting for it to 
return, that is a borderline case.


Using shared memory to communicate with complex data 
structures is pretty much equivalent to dynamic linking.


See also the question I am writing free software that uses a 
non-free library."


Essentially they draw an imaginary line between using "fork and 
exec" vs linking.



"If the program dynamically links plug-ins, and they make 
function calls to each other and share data structures, we 
believe they form a single program, which must be treated as an 
extension of both the main program and the plug-ins"


And so we are in the realm of belief.

As we all know here that every computer program ran on a computer 
is connected by nested "data structures"... so fork and exec are 
just dereferencing linking

by an extra step.

What happens, when in the future, OS's use some other mechanism 
for execution? Is there really any difference between 
exec("app.exe") and LoadLibrary("app.dll")? (I don't mean an 
imginary difference created in the mind by obfuscated data 
structures. I'm talking about a fundamental difference(besides 
performance))



There is a lot of arbitrary language in the GNU license and the 
fact that it was created by lawyers for lawyers(see 
http://gng.z505.com/cult.htm. I realize the link looks a bit 
crackpotish but it has a lot of relevant points and if the 
numbers are right, shows more than enough proof).



As usual, it comes down to who has the biggest bank roll and 
smartest lawyers to obfuscate the issues. The push for free 
software is becoming a nonsensical pursuit like most other human 
behaviors.


I think a license should exist that EXPLICITLY states what one 
can do with the source code and binary and what they are.