Comment by yellowapple | Hacker News Reader

Comment by yellowapple | Hacker News Reader

Given the actual condition being imposed on users of MIT/Expat-licensed assets:

    The above copyright notice and this permission notice shall be included in all
    copies or substantial portions of the Software.

I'm failing to see what the hold-up is here.

- If it's an SVG file, what's wrong with including the license text as a comment?

- If it's a raster image, what's wrong with including the license text in the metadata?

The way I'm reading this, as long as the license text is somehow embedded in the asset - whether or not it's actually visible to someone viewing it as an image - then that fulfills the terms of the license, no?

If such an embedded license is sufficient, then I fail to see what the problem is. Is it just file size? Are these people really so averse to content creators being credited for their work that said consumers of said works consider embedded attribution/licensing unacceptable (and why)?

If such an embedded license is not sufficient, then why is it insufficient?

Obligatory: I ain't a lawyer. Given the sorts of quibbling that seems to be happening over a three-paragraph license that's ubiquitous in the world of software, I don't envy the actual lawyers one bit.

> Is it just file size?

The stated purpose of the project is "Icons under 1KB each". So embedding a 1KB license in each one would defeat the purpose.

Even if file size is not the main goal, embedding metadata could be self-defeating in other ways. If the license requires making the license available to end-users, would that prevent the use of asset pipeline optimization tools? (The motivation for using a permissive license is often to enable compatibility with general-purpose tools.) If the license only requires making the license available to maintainers, then why embed it in the first place?

My question is also about the other various instances of objections to MIT-licensed assets that were raised (i.e. in the article linked in the issue, as well as in other related issues). You're right that this specific case justifies minimal file sizes; maybe a modified/clarified license that only requires the copyright statement and a URL pointing to the license would be a better fit?

Re: asset pipelines, those would only be an issue if one of the "optimizations" is to strip metadata, which sounds an awful lot like a premature optimization to me.

On another note: most compression algorithms in vogue today can shrink the Expat license to less than ⅔ the plaintext size when base64-encoded. That's still hefty in the context of this specific project, but does still technically satisfy the letter (albeit probably not the spirit) of the license's requirements. Compressing the whole SVG file could almost certainly allow the icons to stay under 1kb, at least until decompressed (and an in-memory representation of that SVG file doesn't usually need to preserve comments).

Complying with the MIT license by including it in each SVG file would defeat the stated purpose of "SuperTinyIcons" - to consume very few bytes - by ~tripling the file size of each icon.

The icons are ~500 bytes - the license is over 1 kilobyte.

You could use the LibreJS tags, which avoid you having to copy the entire license text.

We have SPDX licence expressions as well though.

Sure, but in fairness LibreJS (like most FSF projects) pre-dated SPDX by at least a year or two. If they redesigned it today, it would use SPDX.

If only they kept their eye on the ball and stopped trying to flag "non-trivial" JS.

Not too late to switch I think, sometimes people should just consolidate efforts.

That wouldn't comply with the license terms, which require the first two paragraphs (The above copyright notice and this permission notice) to be included in copies. LibreJS tags don't include that.

Reply on news.ycombinator.com