On 06/17/2016 04:08 PM, Kagamin wrote:
> Uh oh, a license is revokable? What happens when boost license is revoked?

No, it's not, but you can publish stuff under multiple licenses at the same time.

On Friday, 17 June 2016 at 13:35:58 UTC, John Colvin wrote:
> On Friday, 17 June 2016 at 13:05:47 UTC, ketmar wrote:
>> finally, the thing you all waited for years is here! pure D no-frills JPEG decoder with progressive JPEG support! Public Domain! one file! no Phobos or other external dependecies! it even has some DDoc! grab it[1] now while it's hot!
>>
>> [1] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/jpegd.d
>
> awesome.
>
> Without wanting to start a huge thing about this, see http://linuxmafia.com/faq/Licensing_and_Law/public-domain.html and http://www.rosenlaw.com/lj16.htm and please at least add an optional licencing under a traditional permissive open-source license (boost would be nice, who knows, maybe phobos should have jpeg support?).

i put it under unlicense[1], as some other works of the same author is using it, and it is basically the same PD.

[1] http://unlicense.org/

On Friday, 17 June 2016 at 22:15:47 UTC, ketmar wrote:
> i put it under unlicense[1], as some other works of the same author is using it, and it is basically the same PD.
>
> [1] http://unlicense.org/

Unfortunately, using unlicense is just as problematic as using public domain:

https://programmers.stackexchange.com/questions/147111/what-is-wrong-with-the-unlicense

The next best thing is the CC0 license (Creative Commons Zero) which is better written than unlicense but it's currently not recommended for software / source code.

http://copyfree.org/content/standard/licenses/cc0/license.txt

After that, the most-open licenses with good legal standing would be Boost and MIT but then you run into the same issues again with incompatible licenses.

I don't have any recommendations but I thought it was worth pointing out that unlicense isn't the solution here.

On Friday, 17 June 2016 at 23:17:56 UTC, Xinok wrote:
> On Friday, 17 June 2016 at 22:15:47 UTC, ketmar wrote:
>> i put it under unlicense[1], as some other works of the same author is using it, and it is basically the same PD.
>>
>> [1] http://unlicense.org/
>
> Unfortunately, using unlicense is just as problematic as using public domain:
>
> https://programmers.stackexchange.com/questions/147111/what-is-wrong-with-the-unlicense

alas, that is all i can do without breaking the "spirit" of the original terms. i'm ok with it, and people still can fork the code and relicense in under Boost/MIT.

On Friday, 17 June 2016 at 14:20:14 UTC, ketmar wrote:
> ah, i also put `.ptr` to array access to skip bounds checking -- i love to build my code with bounds checking on, and i don't feel that i need it in this decoder -- it should be fairly well-tested.

This statement stands out as a problem.  There are lots of security
notices out there that refer to media-decoding problems.  Remember,
in the context of image decoding, you're often handling untrusted
data from external sources.  The security notices often talk about
"carefully crafted" files; here's just one simple example:

    http://www.videolan.org/security/sa0702.html

Here are a couple more, regarding the infamous Adobe Flashplayer:

    https://hackerone.com/reports/30567
    https://hackerone.com/reports/36279

Not convinced?  Let's not stop there; let's look specifically at
what has happened with JPEG in the past, such as:

    http://download.oracle.com/sunalerts/1000310.1.html
    http://www.theregister.co.uk/2004/09/24/jpeg_exploit_toolkit/

You need to think not just about your own code, but also about the
overall environment in which it will operate.

On Saturday, 18 June 2016 at 19:52:20 UTC, Observer wrote:
> Not convinced?

no. i believe that it's all strongly overrated. don't run software with full access to your system, don't feed it with untrusted data, use sandboxes and such, etc. this is the way to go, not adding endless checks for all possible corner cases.

still, anyone is free to undo that: just replace all `\.ptr\b` with empty string -- and voila! all the bounds checking (and mind you, there is little, as many arrays are just malloc'ed anyway) is back. it's way easier to do than to put `.ptr` into vanilla code.

for my use cases `.ptr` access is ok: i prefer to leave bounds checking on for all builds, and manually escape it in the code when i feel that it is necessary.

in other words: i believe that validating data and loading/processing data should be separated. first validate all your jpegs with some tool, then use loaders to actually load and process 'em.

On Saturday, 18 June 2016 at 19:52:20 UTC, Observer wrote:
> in the context of image decoding, you're often handling untrusted data from external sources

Not always though. The main case I'd use a little single-file thing is for files that I created and packaged with the application myself, but wanted to be small for distribution. If I wanted my program to do something naughty, I wrote it, I'd just make it do something naughty!