[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On being web-friendly and why info must die
From: |
chad |
Subject: |
Re: On being web-friendly and why info must die |
Date: |
Mon, 15 Dec 2014 12:23:02 -0800 |
> On 14 Dec 2014, at 17:32, Stephen J. Turnbull <address@hidden> wrote:
>
>
>> It would be interesting to see browsers and javascript packages
>> adopt a GPL-compatibility declaration,
>
> Good luck. The people advocating HTML are using IE, Firefox, Chrome,
> or Safari (or DFSG variants of the above, where legally feasible), I'd
> bet. GPL browsers are minor.
I must have been unclear: I’m talking about declarations in the
javascript code that is delivered to the browser. That requires
absolutely nothing of the browser authors themselves that isnt
already long-available - you need the javascript authors to make a
GPL-compatible declaration, and then you need a browser extension
to tell the user about the declaration. The browser extension is
an easy task for people familiar with such. Getting the javascript
package/library/framework/whatever authors to agree to the GPL is
harder.
>> There are practical ways in which users can exert some control over
>> client-side javascript today (GreaseMonkey, NoScript, and the like).
>
> I think that's a much better approach. I really don't care if the
> code I'm running is GPL or another FLOSS license or public domain.
> After all, the browsers I use most of the time aren't even GPL
> themselves. I don't think crackers and phishers will hesitate to
> fraudulently present a GPL assertion, either. So what I really want
> is a feature that tells me that I haven't run this script before and
> asks me if I want to run it.
The GPL declarations for, say, gcc, gdb, and (tentatively) emacs
all have the same problem. I am assuming that the approaches that
are acceptable there could also apply here.
Let me try this another way: the theoretical acceptable emacs FFI
adds code to emacs that checks for a GPL declaration. The technical
hurdles to having a browser plugin that does the same for
delivered-to-the-client javascript code are very low; if such a
system were desirable, the political hurdles are much harder. I
dont know if the idea is useful enough to be worth the effort in
general, but it presents a potential way past (what I believe is)
a key objection to reliance on what I had called client-side
javascript.
~Chad
- Re: On being web-friendly and why info must die, (continued)
- Re: On being web-friendly and why info must die, Eli Zaretskii, 2014/12/12
- Re: On being web-friendly and why info must die, Lennart Borgman, 2014/12/12
- RE: On being web-friendly and why info must die, Drew Adams, 2014/12/12
- Re: On being web-friendly and why info must die, Richard Stallman, 2014/12/12
- Re: On being web-friendly and why info must die, chad, 2014/12/13
- Re: On being web-friendly and why info must die, Stephen J. Turnbull, 2014/12/14
- Re: On being web-friendly and why info must die, chad, 2014/12/14
- Re: On being web-friendly and why info must die, Stephen J. Turnbull, 2014/12/14
- Re: On being web-friendly and why info must die,
chad <=
- Re: On being web-friendly and why info must die, Stephen J. Turnbull, 2014/12/16
- Re: On being web-friendly and why info must die, Richard Stallman, 2014/12/17
- Re: On being web-friendly and why info must die, Richard Stallman, 2014/12/16
- Re: On being web-friendly and why info must die, Stefan Monnier, 2014/12/14
- Re: On being web-friendly and why info must die, Stephen J. Turnbull, 2014/12/14
- Re: On being web-friendly and why info must die, David Engster, 2014/12/15
- Re: On being web-friendly and why info must die, Richard Stallman, 2014/12/15
- Re: On being web-friendly and why info must die, Stephen J. Turnbull, 2014/12/15
- Re: On being web-friendly and why info must die, Richard Stallman, 2014/12/16
- Re: On beincg web-friendly and why info must die, Stephen J. Turnbull, 2014/12/16