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

Re[2]: Browserified files and DFSG

July 11 2016 9:57 AM, "Pirate Praveen"  wrote: 
>> Yet it is built with a tool not in Debian, from a different form of the
>> work that upstream actually uses for reading and modifying — the source
>> form of the work. So that compiled form is not the source form of the
>> work.
> There is a reason for that requirement, it is not like a bible or Quran
> or another holy book where we have to follow word by word without
> questioning.
> For me, the reason is to be able to modify the code and with readable
> javascript file that is possible.

The key part of this sentence is "For me".  You say that because you don't care about other freedoms that real source gives you, other users must also not care.  Then you conclude that a form which is obviously not real source is "good enough" to use as a substitute.  For you this is true.  But Debian isn't just for you.  Other users use it for different reasons, and we don't want to break our promise to them just because one maintainer didn't care about that part of the promise.

> Yes, to be able to send patches, you will have to change different files
> (just rearranged), but is that enough reason to remove the package?

Yes.  It's reason to not let it into main, and if it got in by accident, that should be fixed.

Note that you seem to misunderstand what "being in main" means.  What it means is that the software is free, and that it is built with an entirely free toolchain, which is also entirely in main.  Failing one of these requirements (in particular the last one, as is the case here) doesn't mean that upstream did something wrong, and so it isn't a punishment for them (but it's not uncommon that it is perceived as such anyway).

> And why is the people who are so strict about packaging the build tool
> not stepping up to package it?

If someone wants to change the rules, and that requires work, the people who want the change should do the work.  But this is not such a case.  Here, you don't want to do all the work that is required for packaging the file (in this case, the part of making sure the tool chain is also packaged in main).  In that case, the answer is not that those who care about our rules must fix your package.

> FRP for node-grunt was filed in 21 May
> 2012 and it is still not complete. So removing these packages until
> grunt is packaged makes debian better?

Yes.  Because people (at least you, I'm guessing others as well) want those packages in Debian.  If we are strict and say that they cannot be in Debian until they satisfy our rules, it is very likely that someone will fix the problems.  If we aren't strict and let them be in main even though they violate the rules, they aren't ever going to be fixed.  Or are you suggesting that you would package the tool chain even if this wasn't a serious bug?


Attachment: signature.asc
Description: Binary data

Reply to: