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

Bug#830978: Browserified javascript and DFSG 2



On Sat, 16 Jul 2016 06:49:56 -0400
Sam Hartman <hartmans@debian.org> wrote:

> >>>>> "Neil" == Neil Williams <codehelp@debian.org> writes:  
>     >> > * The point of having the source code (with an appropriate  
>     >> licence > etc.) is so that all our contributors, downstreams,
>     >> and users are > able to modify the code and to share their
>     >> modifications with each > other, with Debian, and with
>     >> upstream.
>     >> 
>     >> I agree this is an important consideration, but not serious
>     >> enough to reject a package.  
> 
>     Neil> So you consider that upstream are not fully-qualified users
>     Neil> somehow and therefore do not get the benefits of the DFSG?
>     Neil> If the freedoms of users who choose to interact with
>     Neil> upstream are reduced by choices made within the package
>     Neil> then the package is breaking the DFSG by penalising a field
>     Neil> of endeavour.  
> 
> Neil, I have a fairly strong negative emotional reaction when I read
> the paragraph you wrote.  I'd like to share that because I think if I
> share where I'm coming from it will be easier for me to hear you, and
> easier to participate calmly.
> 
> When I read the above, I'm worried because I think that freedoms I
> care about would be limited, and I don't like to see the DFSG
> reshaped to limit freedoms.
> I'm afraid when I think I hear us seeding the contents of Debian to
> upstream.  We are Debian; we choose what Debian is.
> 
> I want to stress that I think you and I are in agreement on
> handlebars.
> 
> However, I do think the freedom to fork from upstream, to move away
> from upstream practices we disagree with is important.

Absolutely - I think it depends on the upstreams we've each experienced
over time. I have been part of or become the entirety of upstream in
nearly all the packages which I've packaged for Debian and it has
always been friendly. Never a need for a fork, I started to contribute
and shortly afterwards got asked to take over upstream...

So I tend to have a more upstream approach than some other DD's, yet I
haven't needed to fork anything - I just got handed it and told to go
ahead! (It also means I rarely have anything in debian/patches...)
 
> I also think that the freedom to "free," over time software even in
> cases where upstream has a non-free source control system, or where
> we're having to build up a new form of source code because of
> restrictions on what's currently the source code are important.
> 
> I do not agree that being an upstream is a field of endeavour.
> 
> I do not agree that we must always use the same source code form that
> upstream does.  Sometimes upstream is wrong.  Sometimes there are
> multiple upstreams.
> Sometimes we want to fork.

Sometimes we do, yes, and we need to retain that ability. However, that
is actually rare. More often, we are interacting with upstream or
supporting users who want to contribute to upstream themselves.
 
> We do however need to ship the source code we use whatever that is.
> It needs to really be source code.  It needs to be a reasonable form
> in which we would choose to make modifications.  If there are other
> plausible source forms that are being used (even if some of them are
> non-free), and those source forms would make the modifications easier,
> that's a strong argument that the software is probably not free as we
> propose to ship it.
> 
> I do not wish us to make the upstream form of source so special that
> we in our best judgment cannot override it.

OK, I didn't mean that we cannot diverge from upstream ever, just that
the majority of the time we are trying to work with upstream rather
than reaching immediately for a fork. Our decisions should make this
collaboration easy, without denying the possibility of the rather blunt
instrument of forking the package.

Part of this collaboration may involve educating upstream about the
problems of distributing their code. This can include source code
freedom issues, it can include software architecture (lack of stable
APIs preventing a large codebase with plugins being separated out) and
it can include portability issues with assumptions in their code which
don't work on all our architectures. Fixing these things requires a
positive attitude to upstream with few structural barriers.

> I do hear your worry that you want to be able to exchange
> modifications with upstream.  Without modifications, without free
> flow of those modifications, software is not free.  I ask that we
> have the flexibility to reject people who aren't actually shipping
> source they would use to modify software while accepting people who
> legitimately disagree about what the source form is.

Agreed.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgpWPby4pTSij.pgp
Description: OpenPGP digital signature


Reply to: