You are not logged in.

#1 2020-07-28 16:05:44

Anchorman
Member
Registered: 2020-07-26
Posts: 18

package archive binary executable

Is it allowed to include a binary executable in a tar.gz package archive?

This would be for my own little app i like to share sometime soon i hope.

Offline

#2 2020-07-28 16:25:29

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 23,899
Website

Re: package archive binary executable

Yes, of course it is as there are ample examples and even guidelines on doing so.

But is there a good reason to do so?  Is the code not public?  Code doesn't need to be open-sourced to be publicly available.  You can maintain a proprietary license over the intellectual content while allowing others to still audit the code and build the program themselves.

Binary-only programs are looked on with a fair share of skepticism even when they come from well known companies; if it is a project from an unknown individual, quite a large majority of archers may steer clear of it as suspicious.

Last edited by Trilby (2020-07-28 16:26:14)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#3 2020-07-28 16:32:22

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 3,513

Re: package archive binary executable


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#4 2020-07-28 17:39:39

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 23,899
Website

Re: package archive binary executable

Eschwartz, that page seems to be all about non-free, not simply closed source - or material that is not publicly shared.  This thread is about the OP's own material, so they wouldn't ask about how to share it if they didn't intend to do so.

So none of the hurdles addressed in that wiki page should be particularly relevant.  It seems the OP simply wants to distribute the precompiled binary.

Last edited by Trilby (2020-07-28 17:40:06)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#5 2020-07-28 17:45:53

Anchorman
Member
Registered: 2020-07-26
Posts: 18

Re: package archive binary executable

Good to know that it is allowed/possible. I understand the possible suspicion one might have. I prefer open software myself, although i have also run many closed source programs, mostly on windows though and with a good virus scanner.

The reasons i like to keep it closed is that it is my first, and perhaps only, pet project so to speak. I guess i don't like to lose control of it at least for now.
Also if i have to look into a proper way to distribute/build it... it's overhead I'm not that eager to take on, i rather just develop it and perhaps a few people like to use it also.

Offline

#6 2020-07-28 17:51:20

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 23,899
Website

Re: package archive binary executable

How would you lose control of it if the source was available?  As for overhead, there is no more work for you to do if you let users build it themselves.

And again, I'm not even (currently) suggesting an open source license.  By all means, keep a proprietary license.  But you can still let users build it themselves.

Last edited by Trilby (2020-07-28 17:52:51)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#7 2020-07-28 18:05:40

Anchorman
Member
Registered: 2020-07-26
Posts: 18

Re: package archive binary executable

Well the program is designed according to my own preference and vision. If the source is available, who knows what others might do with it. As for the overhead, i'm just a beginner who started with a bit of Python and now i would be very happy if i get this thing ready in c++/Qt5. I don't have enough experience to know enough about automated builds from source. Perhaps at a later time...

edit: to be clear: the license would be free to use, completely non commercial

Last edited by Anchorman (2020-07-28 18:16:14)

Offline

#8 2020-07-28 18:17:26

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 23,899
Website

Re: package archive binary executable

Anchorman wrote:

Well the program is designed according to my own preference and vision. If the source is available, who knows what others might do with it.

They can do no more with it than you explicitly authorize them to unless they are willing to break the law.  And if they are willing to break the law, there's nothing stopping them from dissassembling the precompiled binary if they really wanted to.

Anchorman wrote:

As for the overhead, i'm just a beginner who started with a bit of Python and now i would be very happy if i get this thing ready in c++/Qt5. I don't have enough experience to know enough about automated builds from source. Perhaps at a later time...

Again, you have source code that is built into a binary.  There certainly isn't *more* work in providing the code for someone else to build than there is in providing the binary.  There is nothing to know about "automated builds" - you don't need to automate anything.  You let the end user or packager deal with that.

If you are submitting this to the AUR, then in either case you will need to write a PKGBUILD.  And it is actually *less* work to package source code than it is to package a binary (trivially so, but it certainly isn't more work).

Last edited by Trilby (2020-07-28 18:17:44)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#9 2020-07-28 18:45:24

Anchorman
Member
Registered: 2020-07-26
Posts: 18

Re: package archive binary executable

Trilby wrote:
Anchorman wrote:

Well the program is designed according to my own preference and vision. If the source is available, who knows what others might do with it.

They can do no more with it than you explicitly authorize them to unless they are willing to break the law.  And if they are willing to break the law, there's nothing stopping them from dissassembling the precompiled binary if they really wanted to.

Isn't disassembling much harder than just pressing a button and getting the source? It's a specialized field right? So how many people can actually do that...

Anchorman wrote:

As for the overhead, i'm just a beginner who started with a bit of Python and now i would be very happy if i get this thing ready in c++/Qt5. I don't have enough experience to know enough about automated builds from source. Perhaps at a later time...

Again, you have source code that is built into a binary.  There certainly isn't *more* work in providing the code for someone else to build than there is in providing the binary.  There is nothing to know about "automated builds" - you don't need to automate anything.  You let the end user or packager deal with that.

If you are submitting this to the AUR, then in either case you will need to write a PKGBUILD.  And it is actually *less* work to package source code than it is to package a binary (trivially so, but it certainly isn't more work).

This i don't understand, because if we are not building from source we just need a package section that copies a few directories and files? That seems much less error prone than also building. Perhaps you mean that if you know what you are doing it's not more work but remember from the other thread that at this moment i don't even know how to use a prefix for the app data dir and who knows what else i don't know that i should know.

Offline

#10 2020-07-28 18:50:17

ondoho
Member
Registered: 2013-04-30
Posts: 636
Website

Re: package archive binary executable

Anchorman wrote:

edit: to be clear: the license would be free to use, completely non commercial

Please understand that practically all of your operating system is released under a very different license, the GPL.
There's a big difference between "free as in beer" and ... shit, I forgot the other one.
Anyhow: https://www.gnu.org/licenses/gpl-3.0.html or good ol' wikipedia.

Offline

#11 2020-07-28 18:57:31

Anchorman
Member
Registered: 2020-07-26
Posts: 18

Re: package archive binary executable

@ondoho i'm not sure i understand your point, and why do you think i don't know about the GPL and LGPL and other licenses?

Offline

#12 2020-07-28 19:05:21

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 23,899
Website

Re: package archive binary executable

Anchorman wrote:

Isn't disassembling much harder than just pressing a button and getting the source?

It depends on your definition of "much".  But it's certainly not a "specialized field".  In fact, disassembly to assembly code is completely trival (just press the button).  Decompiling to C++ source code is a bit more involved, and they'd never get to the *exact* original source code (e.g., if nothing else, most variable names are lost for good).  But if someone is willing to break the law, there really isn't much of a techical hurdle for them abusing your software simply because they get a precompiled binary.

Anchorman wrote:

This i don't understand, because if we are not building from source we just need a package section that copies a few directories and files? That seems much less error prone than also building.

Yes, but you actually need to build it first then rather that just letting someone else build it.  The build function of a PKGBUILD is just the commands you'd use to build it anyways - so you already have these.  The only question is whether you do it, or someone else does (and you are favoring you doing it all yourself which is more work).  And are you going to build for different architectures?  More importantly, are you going to rebuild and re-share a new build every time a dependency has an ABI change?  If you leave it to others to build, then they rebuild it when there are ABI changes and you can focus on the code rather than rebuilding and redistrubuting the new binaries each time this happens.

Now don't get me wrong - if you want to distribute a binary, do so.  It just sounds like you're making that decision based on an assessment of the costs and benefits which is quite inaccurate.

Last edited by Trilby (2020-07-28 19:06:02)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#13 2020-07-28 20:26:36

Anchorman
Member
Registered: 2020-07-26
Posts: 18

Re: package archive binary executable

Trilby wrote:
Anchorman wrote:

Isn't disassembling much harder than just pressing a button and getting the source?

It depends on your definition of "much".  But it's certainly not a "specialized field".  In fact, disassembly to assembly code is completely trival (just press the button).  Decompiling to C++ source code is a bit more involved, and they'd never get to the *exact* original source code (e.g., if nothing else, most variable names are lost for good).  But if someone is willing to break the law, there really isn't much of a techical hurdle for them abusing your software simply because they get a precompiled binary.

Well it would certainly be interesting to see what someone can do with the binary. From what i just read, https://stackoverflow.com/questions/205 … decompiler it sounds like the results would be poor from a stripped release binary.

Anchorman wrote:

This i don't understand, because if we are not building from source we just need a package section that copies a few directories and files? That seems much less error prone than also building.

Yes, but you actually need to build it first then rather that just letting someone else build it.  The build function of a PKGBUILD is just the commands you'd use to build it anyways - so you already have these.  The only question is whether you do it, or someone else does (and you are favoring you doing it all yourself which is more work).  And are you going to build for different architectures?  More importantly, are you going to rebuild and re-share a new build every time a dependency has an ABI change?  If you leave it to others to build, then they rebuild it when there are ABI changes and you can focus on the code rather than rebuilding and redistrubuting the new binaries each time this happens.

Now don't get me wrong - if you want to distribute a binary, do so.  It just sounds like you're making that decision based on an assessment of the costs and benefits which is quite inaccurate.

My idea was to just share on the AUR. I can't imagine my app getting very popular but if I'm mistaken i can always change the license and follow your advise and let others worry about packaging. Thanks for the information!

Offline

#14 2020-07-28 22:25:22

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 3,513

Re: package archive binary executable

What are you afraid of, anyway?

Anchorman wrote:

Well the program is designed according to my own preference and vision. If the source is available, who knows what others might do with it.

So... let them? That's what open source is about. The converse possibility is that they might, for example, use your program without buying it, or learn proprietary secrets from it. Is that your concern? Another potential reason to do closed-source development is people who are deeply embarrassed by their source code design and don't want people to laugh at them, but I have to ask such people if that really seems likely.

Anchorman wrote:

As for the overhead, i'm just a beginner who started with a bit of Python and now i would be very happy if i get this thing ready in c++/Qt5. I don't have enough experience to know enough about automated builds from source. Perhaps at a later time...

edit: to be clear: the license would be free to use, completely non commercial

If you're going to use Qt5, you're in trouble. Qt5 is dual licensed, you can buy a commercial license to use it in proprietary software (that is how the company makes money developing it), or you can get a free, open source license under the GPL.

It's an elegant approach, allowing anyone to create anything they want with Qt5, but with the caveat that you need to pay the Qt Company for the privilege of not releasing the source.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#15 2020-07-28 23:12:47

Anchorman
Member
Registered: 2020-07-26
Posts: 18

Re: package archive binary executable

eschwartz wrote:

What are you afraid of, anyway?

Anchorman wrote:

Well the program is designed according to my own preference and vision. If the source is available, who knows what others might do with it.

So... let them? That's what open source is about. The converse possibility is that they might, for example, use your program without buying it, or learn proprietary secrets from it. Is that your concern? Another potential reason to do closed-source development is people who are deeply embarrassed by their source code design and don't want people to laugh at them, but I have to ask such people if that really seems likely.

One of the reasons i build this for myself is to have more freedom over content and presentation (it's basically a bible database frontend), without having to connect to the internet or being limited by obscure formats or encrypted databases and without any commercial links. But if it's GPL one can make it commercial again for example or perhaps lock away resources.

Anchorman wrote:

As for the overhead, i'm just a beginner who started with a bit of Python and now i would be very happy if i get this thing ready in c++/Qt5. I don't have enough experience to know enough about automated builds from source. Perhaps at a later time...

edit: to be clear: the license would be free to use, completely non commercial

If you're going to use Qt5, you're in trouble. Qt5 is dual licensed, you can buy a commercial license to use it in proprietary software (that is how the company makes money developing it), or you can get a free, open source license under the GPL.

It's an elegant approach, allowing anyone to create anything they want with Qt5, but with the caveat that you need to pay the Qt Company for the privilege of not releasing the source.

That is not correct. One can use the LGPL conditions. https://doc.qt.io/qt-5/licensing.html
This is easy with shared linking but even  possible with static linking. These questions are often discussed on the Qt forums if you are interested to look it up.

Last edited by Anchorman (2020-07-28 23:13:22)

Offline

#16 2020-07-28 23:49:59

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 23,899
Website

Re: package archive binary executable

Anchorman wrote:

One of the reasons i build this for myself is to have more freedom over content and presentation (it's basically a bible database frontend), without having to connect to the internet or being limited by obscure formats or encrypted databases and without any commercial links. But if it's GPL one can make it commercial again for example or perhaps lock away resources.

Ok, I'm sorry, but this part makes NOOO sense at all.

If you license your code with a permissive open source license, then someone else can modify it and release it as a comercial version - but that would not in any way prevent you from still using what you made.  They can't claim rights to your software.  But more importantly, if you chose anyting other than a permissive open source license (e.g., a copy-left license, or a license to use without modification which is what I've been suggesting from the start) they cannot do any such modifications.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#17 2020-07-28 23:56:41

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 3,513

Re: package archive binary executable

Anchorman wrote:

One of the reasons i build this for myself is to have more freedom over content and presentation (it's basically a bible database frontend), without having to connect to the internet or being limited by obscure formats or encrypted databases and without any commercial links. But if it's GPL one can make it commercial again for example or perhaps lock away resources.

One can always commercially sell GPL software, but by definition the GPL means users are free to download it for free too. Commercial distributors cannot either modify the source, improve it, and sell it without publishing the source for their modifications under a GPL-compatible license. The Free Software Foundation was very particular about this when designing their license, since they considered it their ethical duty to prevent commercial entities from "making it commercial-only".

This is, however, explicitly a danger of licenses such as the BSD/MIT.

Publishing it gratis (zero monetary cost) as closed-source shareware poses a much greater danger of becoming commercial -- the author retains the right to take it commercial. Furthermore, you can use a https://en.wikipedia.org/wiki/Source-available_software license (the best example of what I mean is https://en.wikipedia.org/wiki/Shared_So … e_(Ms-RSL) FYI), and only permit reading the code "for review and commentary", or give people the right to download and compile the code but not modify it for any purposes whatsoever, or whatever other rights you wish.

...

I'm not sure what you mean by locking away resources, if they are published freely they cannot be taken away and if they aren't, they can be withdrawn regardless of your project license.

...

At the end of the day, you can do whatever you want as long as you can legally use your dependencies (LGPL deps are generally fine, GPL ones generally not if you're not using an OSI-approved license).

An AUR package can be created for "myprog-bin" which downloads prebuilt binaries from your thirdparty hosting, and installs them as needed, with the appropriate license=() and license text installed to /usr/share/licenses/${pkgname}/

Anchorman wrote:

That is not correct. One can use the LGPL conditions. https://doc.qt.io/qt-5/licensing.html
This is easy with shared linking but even  possible with static linking. These questions are often discussed on the Qt forums if you are interested to look it up.

Fair enough for the shared linking, though distribution as such would tend to be a pain and depending on the system copy would lead to fragile versioning issues. Not sure I understand how this would work for static linking, though.

Last edited by eschwartz (2020-07-28 23:59:21)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#18 2020-07-29 09:49:57

Anchorman
Member
Registered: 2020-07-26
Posts: 18

Re: package archive binary executable

Trilby wrote:
Anchorman wrote:

One of the reasons i build this for myself is to have more freedom over content and presentation (it's basically a bible database frontend), without having to connect to the internet or being limited by obscure formats or encrypted databases and without any commercial links. But if it's GPL one can make it commercial again for example or perhaps lock away resources.

Ok, I'm sorry, but this part makes NOOO sense at all.

If you license your code with a permissive open source license, then someone else can modify it and release it as a comercial version - but that would not in any way prevent you from still using what you made. They can't claim rights to your software.

You misunderstand my concern. I just don't want to provide anything that can be used commercially. And i would not like it if the character of the program changes. This last point however might just be small-mindedness of me and might change.

But more importantly, if you chose anyting other than a permissive open source license (e.g., a copy-left license, or a license to use without modification which is what I've been suggesting from the start) they cannot do any such modifications.

What do you suggest as the best license if i choose this option?

Offline

#19 2020-07-29 10:09:56

Anchorman
Member
Registered: 2020-07-26
Posts: 18

Re: package archive binary executable

eschwartz wrote:
Anchorman wrote:

One of the reasons i build this for myself is to have more freedom over content and presentation (it's basically a bible database frontend), without having to connect to the internet or being limited by obscure formats or encrypted databases and without any commercial links. But if it's GPL one can make it commercial again for example or perhaps lock away resources.

One can always commercially sell GPL software, but by definition the GPL means users are free to download it for free too. Commercial distributors cannot either modify the source, improve it, and sell it without publishing the source for their modifications under a GPL-compatible license. The Free Software Foundation was very particular about this when designing their license, since they considered it their ethical duty to prevent commercial entities from "making it commercial-only".

This is, however, explicitly a danger of licenses such as the BSD/MIT.

Publishing it gratis (zero monetary cost) as closed-source shareware poses a much greater danger of becoming commercial -- the author retains the right to take it commercial.

This is not a danger but the authors right, the author does not pose a threat to the the author... You are reasoning from the perspective of the users. But what is freely given does not cost them anything. They can keep on using the free version for as long as they want. And in this case the author is against any commercialization based on deep ideological grounds, so that is a pretty good assurance of freedom i would say.

Furthermore, you can use a https://en.wikipedia.org/wiki/Source-available_software license (the best example of what I mean is https://en.wikipedia.org/wiki/Shared_So … e_(Ms-RSL) FYI), and only permit reading the code "for review and commentary", or give people the right to download and compile the code but not modify it for any purposes whatsoever, or whatever other rights you wish.

Thanks, i will consider this. What do you think is the best option if i wanted to give the user a lot of freedom but forbid any commercial usage?

...

I'm not sure what you mean by locking away resources, if they are published freely they cannot be taken away and if they aren't, they can be withdrawn regardless of your project license.

Well sometimes you see custom formats that can only be read with certain software that might or might not be easy to manipulate. Instead of using e.g. sqlite, and without blobs, that anyone can modify.

...

At the end of the day, you can do whatever you want as long as you can legally use your dependencies (LGPL deps are generally fine, GPL ones generally not if you're not using an OSI-approved license).

An AUR package can be created for "myprog-bin" which downloads prebuilt binaries from your thirdparty hosting, and installs them as needed, with the appropriate license=() and license text installed to /usr/share/licenses/${pkgname}/

Anchorman wrote:

That is not correct. One can use the LGPL conditions. https://doc.qt.io/qt-5/licensing.html
This is easy with shared linking but even  possible with static linking. These questions are often discussed on the Qt forums if you are interested to look it up.

Fair enough for the shared linking, though distribution as such would tend to be a pain and depending on the system copy would lead to fragile versioning issues. Not sure I understand how this would work for static linking, though.

How would that be hard with Qt5? It can just be installed with the distribution's package manager. And i think it will probably not change often in such a way that it becomes incompatible with previous version, but i could be wrong about that.

For static linking one must be able to provide the object code if a user request that, so they can link to their version of Qt to make it work on their system. The static linking changes the code's status from "application" to "combined work" if my understanding of the LGPLv3 is correct.


EDIT: "They can keep on using the free version for as long as they want."
From a cost perspective, not from a perspective of software compatibility in the future. So yeah that is a 'danger'.

Last edited by Anchorman (2020-07-29 10:21:42)

Offline

#20 2020-07-29 11:17:58

ondoho
Member
Registered: 2013-04-30
Posts: 636
Website

Re: package archive binary executable

Anchorman wrote:

This i don't understand, because if we are not building from source we just need a package section that copies a few directories and files? That seems much less error prone than also building.

This would be true if the software stood on its own - but no software ever does, it needs to interact with other OS components. Building & compiling it on the target system is an elegant way to ensure that it also works on that system. The end result is likely less error prone, at least over time, as ArchLinux evolves constantly.

Offline

#21 2020-07-29 12:16:57

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 23,899
Website

Re: package archive binary executable

Anchorman wrote:

... in this case the author is against any commercialization based on deep ideological grounds, so that is a pretty good assurance of freedom i would say.

Not if you use a permissive license (e.g., MIT/BSD) it isn't.

I can't tell you which license would suit you best as that depends on your goals - and quite honestly, your goals as presented here don't make any sense: they're self-contradictory.  It's quite clear that you should not use permissive open source licenses (e.g., MIT/BSD) as they certainly are counter to your intent.  And note this is about your intent, MIT/BSD/ISC are my preferred licenses for my work.

From the very very start of this thread I suggested that it sounds like you might be best suited by a license that allows use but no modification of the code.  I'm not familiar with examples of this class of license, but it'd be trivial to modify a MIT license for these purposes, or use one of many that almost certainly exist including the one Eschwartz linked to.

If your goal is for no one else to make modifications, ever, then that is the class of license you should use.  But it doesn't sound like you are sure about that.  If you want to ensure that your code can never be made proprietary (by someone else) then the GPL or another copy-left license would be best.

Thanks, i will consider this. What do you think is the best option if i wanted to give the user a lot of freedom but forbid any commercial usage?

If this is your goal, then you definitely want a copyleft license.  GPL is the most widely used and recognized license of this class (I personally wish there were good examples of less "viral" copy-left, but that's a different discussion.  The LGPL is in that arena.)

EDIT: "They can keep on using the free version for as long as they want."
From a cost perspective, not from a perspective of software compatibility in the future. So yeah that is a 'danger'.

What?  No.  If a user gets a free-to-use licensed version, they can continue using it forever even if someone else released a new paid and incompatible version.  It will also be compatible with any future version you create because it sounds like you are committed to keeping them compatible and free-to-use.

Imagine you release Scripture 1.0.  Even assume you put it under an MIT license.  User Bob gets a copy under the MIT license.  Bob can use that forever for free.  Even when corporate AssHat Interdome Linux grabs it, modifies it to include advertising, and releases it under a proprietary license as ScriptureX 2.0, Bob can keep on using Scripture 1.0.  He will not get any improvements added in ScriptureX ... but he wouldn't get them anyways if your license had not allowed AHIL to make it in the first place.  So preventing AHIL from making a new version does not protect Bob.  It also doesn't offer you much protection (other than having an offshoot of your software that you don't like, which is a valid concern to have).

Of course, even after AHIL releases their version, you can come out with Scripture 2.0 still free-to-use and Bob can get all the benefits of using that updated version: it will be compatible with his old version (if you make it that way) and AHIL cannot stop him from using it.

But this hypothetical example is really neither here nor there.  Whatever license you should use, it's pretty clear that it will not be a permissive open-source license.  If you release your code under a read-compile-use only license, or under the GPL, none of the above hypothetical example of harmless could even happen.


Consider another way of looking at this.  What software do you use or have you used that has been "hijacked" by someone other than the other to inject advertising, or to lock away resources, and/or to make it comercial?  If you have used Windows, most of your software fits this category.  If you run MacOS a fair share of your software is in this category.  If you run linux or unix, I bet you'd be hard pressed to find any examples of software you use in this category.  Why is that?  Which licenses prevent such behavior?  Which ones seem to allow that behavior?  (And if you use Android ... pretty much EVERYTHING on the google play store is in this bad category).

Last edited by Trilby (2020-07-29 12:27:21)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#22 2020-07-29 13:46:49

schard
Member
From: Hannover
Registered: 2016-05-06
Posts: 873
Website

Re: package archive binary executable

I think the first two posts cleared the OP's question.
Though being a contributer to and promoter of free software, I don't think that it is necessary to try to convince the OP to publish their software open source or under any more or less permissive license.
While I cannot follow their argumentation as to why they don't want that, I believe that it's in their right as the author to do whatever the f they want to do with their work.

That being said, and because this seems to be some Bible software:
Let each of you look not only to his own interests, but also to the interests of others. -- Philippians 2:4

Offline

#23 2020-07-29 15:22:16

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 23,899
Website

Re: package archive binary executable

Schard, no one is trying to convince them to do anything other than acheive their goals, quite the opposite.  What's being discussed is the fact that the steps they have chosen seem not well chosen to acheive their goals.

Much like an X-Y problem, when Y is the goal there is no reason to respect an OPs wishes to use X to do Y if they are misinformed on the usefulness of X for that goal.

Last edited by Trilby (2020-07-29 15:23:08)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#24 2020-07-29 19:20:30

Anchorman
Member
Registered: 2020-07-26
Posts: 18

Re: package archive binary executable

schard wrote:

I think the first two posts cleared the OP's question.
Though being a contributer to and promoter of free software, I don't think that it is necessary to try to convince the OP to publish their software open source or under any more or less permissive license.
While I cannot follow their argumentation as to why they don't want that, I believe that it's in their right as the author to do whatever the f they want to do with their work.

That being said, and because this seems to be some Bible software:
Let each of you look not only to his own interests, but also to the interests of others. -- Philippians 2:4

I do care about the interests of others, else i would not want to make this available in the first place and else i wouldn't consider other options based on what people say.

Offline

#25 2020-07-29 19:58:27

Anchorman
Member
Registered: 2020-07-26
Posts: 18

Re: package archive binary executable

@Trilby

A CC license with share-alike and non-commercial looks interesting...
https://en.wikipedia.org/wiki/Creative_ … f_licenses

Offline

Board footer

Powered by FluxBB