repo-criteria-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Repo-criteria-discuss] What's needed to publish the evaluations (ak


From: Aaron Wolf
Subject: Re: [Repo-criteria-discuss] What's needed to publish the evaluations (aka the longest email ever {aka two specific tasks})}
Date: Thu, 14 Apr 2016 12:19:18 -0700

On 04/14/2016 07:58 AM, Zak Rogoff wrote:
> On 04/13/2016 03:07 PM, Aaron Wolf wrote:
>> On 04/13/2016 05:51 AM, Mike Gerwitz wrote:
>>> On Tue, Apr 12, 2016 at 21:47:54 -0700, Aaron Wolf wrote:
>>>> On 04/12/2016 09:36 PM, Mike Gerwitz wrote:
>>>>> On Tue, Apr 12, 2016 at 21:27:34 -0700, Aaron Wolf wrote:
>>>>>> I find the Sourceforge report problematic. I haven't verified this
>>>>>> myself, but I believe that the vast majority of Sourceforge JavaScript
>>>>>> is free, if not all, and comes directly as part of Apache Allura.
>>>>>
>>>>> But it's not LibreJS-compatible, which is the criterion.
>>>>>
>>>>
>>>> If LibreJS-compatible is *the* criterion, then GitLab fails. Period.
>>>
>>> It does not, unless things have changed recently; I worked with Sytse to
>>> make sure all the essential features worked with JS completely
>>> disabled.  That's either in the message archives for this mailing list,
>>> or in our threads before it was created; I forget.
>>>
>>>> (A) specify the criteria as verifiably-free and state that Sourceforge
>>>> JS isn't verifiable
>>>>
>>>> or
>>>>
>>>> (B) specify the criteria as LibreJS-verified specifically and fail GitLab
>>>
>>> I'm okay with A, but not B.  If I can use Gitlab without JS enabled,
>>> then it's not an issue; at least by rms' philosophy.  I personally don't
>>> want to recommend sites where users will run proprietary JS, but that
>>> essentially rules out the entire Web, which is his point.
>>>
>>>> I would suggest option (A) and to reach out to Sourceforge asking for
>>>> their assistance in verifying the freeness of their JS.
>>>
>>> Zak (and rms) want to get this out, so we may have to make a mention and
>>> then update it after the fact.
>>>
>>> Zak, just let me know what you and rms would like done and I'll make
>>> some text changes.
>>>
>>
>> Ok, so the issue is *not* just freedom of JS, it is *only* LibreJS or
>> NoScript / no-JS compatible. I.e. Sourceforge would fail even if it were
>> shown that all JS is fully free.
> 
> It depends on which criterion you are talking about. C0 requires simply
> that the site's important functions work with LibreJS turned on. B0
> requires that all scripts sent to the browser are free and correctly
> labeled for an automated license analyzer.
> 
> I don't think I 100% grasp the details of Aaron's concern, but I feel
> that it would definitely be good for us to have a more user-friendly
> explanation of the various levels of suitability for use with LibreJS
> that we see exhibited by different Web sites. However, I think that the
> criteria are not ambiguous, and Mike's report applies the criteria
> correctly.
> 

Thanks for clarifying. The issue is that the report for Sourceforge's F
rating could be read to say that if the JS were free, the items would
pass. That leads people to assume the JS is non-free when it is likely
actually free. The wording for Sourceforge report should say "these
items cannot be done if /libreJS is on (because LibreJS does not
recognize the JS as free, and these tasks do not work without the
Javascript)" or something else equally clear that cannot be mistaken for
a claim that the JS is non-free (since that's not the criterion).

Similarly, at least a footnote for Gitlab should say: "Although the JS
has been verified otherwise as being fully free, LibreJS does not
recognize this fact at this time. However, all the essential functions
work without JavaScript anyway, so this criteria for level C passes."

We should remember this is much much bigger than the notes about each
platform. The clarity about each case provides concrete examples for
websites of all sorts about how these criteria work. These are
demonstration examples about the issues at hand. If we confuse people, I
guarantee, we'll see folks wrongly complaining about other sites, just
like we see cases of accusations of GPL violations that aren't actually
violations because people get confused about the requirements. With this
report, it's essential that readers understand clearly why a site was
rated a certain way.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]