October 16, 2015
On Friday, 16 October 2015 at 15:36:26 UTC, Steven Schveighoffer wrote:
> You certainly can link with it, and then your code becomes GPL.

No, the code is code. It is an artifact. The GPL is a legal document. The legal document says what rights you have to the copy you received and what requirements that follows it. You are allowed to modify it and do anything you want with it that is covered under fair use. This varies between jurisdictions.

The license primarily comes into effect  when you _distribute_ or _publish_, because the legal precedent for putting restrictions on distribution and publishing is much stronger. And WIPO is much more clear there.

So, if you build websites for a third party you can use GPL without redistribution by writing the contract in such a way that the third party is using your service. Meaning, you run the software. So circumventing the GPL isn't all that hard if you want to.

The AGPL also affects publishing as a service, so it makes such arrangements much more difficult.

October 16, 2015
On 10/16/15 11:56 AM, Ola Fosheim Grøstad wrote:
> On Friday, 16 October 2015 at 15:36:26 UTC, Steven Schveighoffer wrote:
>> You certainly can link with it, and then your code becomes GPL.
>
> No, the code is code. It is an artifact. The GPL is a legal document.
> The legal document says what rights you have to the copy you received
> and what requirements that follows it. You are allowed to modify it and
> do anything you want with it that is covered under fair use. This varies
> between jurisdictions.
>
> The license primarily comes into effect  when you _distribute_ or
> _publish_, because the legal precedent for putting restrictions on
> distribution and publishing is much stronger. And WIPO is much more
> clear there.

Right, so what happens when you accidentally distribute it? What license is it under?

For example, let's say you have a product that doesn't use JSON. It's proprietary, and you distribute it under a proprietary license. You want to include JSON parsing, so you incorporate this GPL'd library. Then you distribute it under your proprietary license.

Recipient says "Wait, you used fast.json! That means this is now GPL, I want the source". Then what?

> So, if you build websites for a third party you can use GPL without
> redistribution by writing the contract in such a way that the third
> party is using your service. Meaning, you run the software. So
> circumventing the GPL isn't all that hard if you want to.

Being able to use GPL on SAAS doesn't satisfy the use case here. This is a compiled library, it can be used in any piece of software.

-Steve
October 16, 2015
On Friday, 16 October 2015 at 17:38:01 UTC, Steven Schveighoffer wrote:
> For example, let's say you have a product that doesn't use JSON. It's proprietary, and you distribute it under a proprietary license. You want to include JSON parsing, so you incorporate this GPL'd library. Then you distribute it under your proprietary license.
>
> Recipient says "Wait, you used fast.json! That means this is now GPL, I want the source". Then what?

The recipient has no say in this, but the original author can demand that you either stop distribution or purchase a compatible license.

> Being able to use GPL on SAAS doesn't satisfy the use case here. This is a compiled library, it can be used in any piece of software.

My point was that you can use GPLed code in a proprietary service. But you can also ship propritary code separately that the end user links with the GPLed code. It is only when you bundle the two that you get a derived work.


October 16, 2015
On 10/16/15 2:24 PM, Ola Fosheim Grøstad wrote:
> On Friday, 16 October 2015 at 17:38:01 UTC, Steven Schveighoffer wrote:
>> For example, let's say you have a product that doesn't use JSON. It's
>> proprietary, and you distribute it under a proprietary license. You
>> want to include JSON parsing, so you incorporate this GPL'd library.
>> Then you distribute it under your proprietary license.
>>
>> Recipient says "Wait, you used fast.json! That means this is now GPL,
>> I want the source". Then what?
>
> The recipient has no say in this, but the original author can demand
> that you either stop distribution or purchase a compatible license.

Exactly my point.

>> Being able to use GPL on SAAS doesn't satisfy the use case here. This
>> is a compiled library, it can be used in any piece of software.
>
> My point was that you can use GPLed code in a proprietary service. But
> you can also ship propritary code separately that the end user links
> with the GPLed code. It is only when you bundle the two that you get a
> derived work.

And I don't disagree with your point, just that it was not a correct response to "but you definitely can't link any proprietary code aganist [sic] it."

-Steve
October 16, 2015
On Friday, 16 October 2015 at 18:53:39 UTC, Steven Schveighoffer wrote:
> And I don't disagree with your point, just that it was not a correct response to "but you definitely can't link any proprietary code aganist [sic] it."

That I don't understand. You can indeed build your executable from a mix of proprietary third party libraries and GPL code, that means you definetively can link. You cannot distribute it together to another third party, but your employer can use it and run a service with it.

People attribute way too many limitations to GPL codebases. For many organizations the GPL would be perfectly ok for their software stack.


October 16, 2015
On 10/16/15 3:36 PM, Ola Fosheim Grøstad wrote:
> On Friday, 16 October 2015 at 18:53:39 UTC, Steven Schveighoffer wrote:
>> And I don't disagree with your point, just that it was not a correct
>> response to "but you definitely can't link any proprietary code
>> aganist [sic] it."
>
> That I don't understand. You can indeed build your executable from a mix
> of proprietary third party libraries and GPL code, that means you
> definetively can link. You cannot distribute it together to another
> third party, but your employer can use it and run a service with it.

The distribution is implied in the comment. If there isn't distribution, the license taint isn't important, why bring it up? In any case, having a GPL license for a library diminishes its usefulness to proprietary software houses.

> People attribute way too many limitations to GPL codebases. For many
> organizations the GPL would be perfectly ok for their software stack.

It depends on what you do. Sure, if you are a pure SAAS house, GPL is perfectly fine, but if one day you want to license that as an installable server, you need to re-develop that GPL piece, and make sure your developers never looked at the code. It's not something to take lightly.

-Steve
October 17, 2015
On Friday, 16 October 2015 at 21:01:02 UTC, Steven Schveighoffer wrote:
> The distribution is implied in the comment. If there isn't distribution, the license taint isn't important, why bring it up?

That was not implied. You can have a license which is much more limiting, the GPL is fairly liberal. Most software that is written is not for redistribution!

> In any case, having a GPL license for a library diminishes its usefulness to proprietary software houses.

If that's what you you mean, then be explicit about it.

> It depends on what you do. Sure, if you are a pure SAAS house, GPL is perfectly fine, but if one day you want to license that as an installable server, you need to re-develop that GPL piece,

It isn't obvious, you should be able to lease a server without that being considered obtaining a copy? To figure that out you'll need a legal interpretation of the GPL for your jurisdiction.

> and make sure your developers never looked at the code. It's not something to take lightly.

No, having read code in the past does not affect copyright. If you don't translate the GPL code while writing then it isn't a derived work.

What you are thinking about is clean room implementation of reverse engineered APIs to hardware where the code only is tiny stubs of machine code that has to be written in a certain way to be compatible.



October 17, 2015
Am 16.10.2015 um 17:11 schrieb Marco Leise:
> Am Thu, 15 Oct 2015 18:17:07 +0200
> schrieb Sönke Ludwig <sludwig@rejectedsoftware.com>:
>
>> (...)
>> Do you have a test case for your error?
>
> Well it is not an error. Rory originally wrote about
> conversions between "1" and 1 happening on the browser side.
> That would mean adding a quirks mode to any well-behaving JSON
> parser. In this case: "read numbers as strings". Hence I was
> asking if the data on the client could be fixed, e.g. the json
> number be turned into a string first before serialization.
>

Okay, I obviously misread that as a once familiar issue. Maybe it indeed makes sense to add a "JavaScript" quirks mode that behaves exactly like a JavaScript interpreter would.
October 17, 2015
On Wednesday, 14 October 2015 at 07:35:49 UTC, Marco Leise wrote:
>   - Data size limited by available contiguous virtual memory

Mmaping files for sequential reading is a very debatable choice, b/c the common use case is to read a file once. You should at least compare the numbers w/ drop_caches between each run.
https://github.com/mleise/fast/blob/69923d5a69f67c21a37e5e2469fc34d60c9ec3e1/source/fast/json.d#L1441
October 17, 2015
On Saturday, 17 October 2015 at 08:07:57 UTC, Martin Nowak wrote:
> On Wednesday, 14 October 2015 at 07:35:49 UTC, Marco Leise wrote:
>>   - Data size limited by available contiguous virtual memory
>
> Mmaping files for sequential reading is a very debatable choice, b/c the common use case is to read a file once. You should at least compare the numbers w/ drop_caches between each run.
>

It's a sensible choice together with appropriate madvise().