Moving forward with Armory

[goatpig]

goatpig, I think you should grab the tags from etotheipi's repo and then upload the 0.93.3 release to github so that the latest versions are in a place that you have control over so that if ATI goes offline for some reason, the latest release is still available until 0.94 is finished.

Updated the tags. I don't have the patience to figure out the release functionalities of github tonight. I'll look into that sometimes this week.

[achow101]

goatpig, I think you should grab the tags from etotheipi's repo and then upload the 0.93.3 release to github so that the latest versions are in a place that you have control over so that if ATI goes offline for some reason, the latest release is still available until 0.94 is finished.

Updated the tags. I don't have the patience to figure out the release functionalities of github tonight. I'll look into that sometimes this week.

The releases is really easy to use. Click on the Releases tab in the github repo and then click on the tag (the name of the tag is a link) you want (in this case 0.93.3). Then click the button to edit the tag and drag and drop the binaries into the box where it says the binaries are. If you want to add a message that goes with the release, type it into the textbox. When you are done click publish release.

[RoadStress]

Hey goatpig has etotheipi told you anything about the website? If not will you discuss this with him?

[goatpig]

No he hasn't but I expect it is off limit, and he can't do anything about it either.

[Roy Badami]

I'm very dubious of your plan to manage copyright at the level of commits - i.e. one copyright and license up to a particular commit, and another for subsequent commits.  This is very unconventional and sounds like a recipe for legal confusion.  You can't meaningfully pick apart the commits to a single file.   Don't try to do this without advice from a lawyer.

I thought it was proper to indicate where the code starts to diverge, by hash. There is no clearer way to designate a point in the development time line where all code is ATI's property before and anything after is a mix and match. I've removed it from the license.

I don't think it's bad to indicate where they diverge (but it would be more readable to reference the commit by tag, now you've imported them).

My main concern (sorry if I didn't read it carefully enough and misunderstood) was that your original approach seemed to me to be saying that there would be files in your distro that had portions under one license but subsequent changes under another.  I think attempting to apply licenses to an individual file at the commit level is problematic - hence my advice to just accept that modified files are derivative works and will have to be licensed in their entirety under the GNU Affero GPL.

It's late now, I'll try and review your updates soon.

EDIT: Or put another way -  where the development diverges is useful and interesting information, and there's no reason not to include that information.  But I wouldn't personally word the license in such a way that it depends on this; such commentary should be purely informational and clearly not part of the license terms.

[goatpig]

I don't think it's bad to indicate where they diverge (but it would be more readable to reference the commit by tag, now you've imported them).

My main concern (sorry if I didn't read it carefully enough and misunderstood) was that your original approach seemed to me to be saying that there would be files in your distro that had portions under one license but subsequent changes under another.  I think attempting to apply licenses to an individual file at the commit level is problematic - hence my advice to just accept that modified files are derivative works and will have to be licensed in their entirety under the GNU Affero GPL.

You read me correctly but assumed too much. I wanted to have a record in the license file of when the code started to diverge, since I'll be changing code and licenses in a lot of original files. I've amended that by tag in LICENSE.

The releases is really easy to use. Click on the Releases tab in the github repo and then click on the tag (the name of the tag is a link) you want (in this case 0.93.3). Then click the button to edit the tag and drag and drop the binaries into the box where it says the binaries are. If you want to add a message that goes with the release, type it into the textbox. When you are done click publish release.

Done. Was a lot easier than expected =)

[coins101]

You should seriously think about dropping the name Armory or get permission to use it.

Armory is the name of the company, as well as the product.

I know its a pain, but its actually not covered by any open source licence, that I can see.

[opentoe]

All the software I use is free. It is all community developed and have very good support paths. I've donated to all the ones I use and too bad this couldn't be the same with Armory. I have seen some good software ( like this ) go from community type development to being locked down and someone wants to just make money off of it. I don't know anything about IP or the laws, but been good while it lasted.

If you have coins in your wallet and the blockchain/development changes very quickly and/radically couldn't there be a chance you can't send your coins out to another wallet?

[achow101]

Here is a site for the project that I put together using Github Pages: https://achow101.github.io/BitcoinArmory/. It uses Jekyll (which github recommends using) and Github Pages as the hosting. The code is at https://github.com/achow101/BitcoinArmory/tree/gh-pages and if someone can get a domain, that domain can also be pointed to the site so it uses the domain. Let me know what you think about it.

[gangtraet]

I am certainly no expert on copyright law and licenses, but a sound engineering principle is KISS ("Keep It Simple, Stupid").  I can certainly understand that you prefer MIT license over GNU Affero for your own work (I agree with you here), but you should seriously consider if the extra complication of having to keep track of two different licenses is worth the trouble.  In particular, once you start refactor code you will constantly have to worry about not moving code from an Affero file to an MIT file.  Furthermore, the GNU licenses tends to affect the whole work, so the entire Armory will be under that license, even if people can reuse parts of the project that you alone wrote under MIT license.

Read above. I appreciate KISS but I AGPL has to go and I don't want to rewrite everything from the ground up. Phasing out the old code will be a long term effort along the course of at least 2016.

I can certainly see your point.  I doubt that you will ever end with an Armory without AGPL stuff in it, but the new stuff you write will be easier to integrate into other projects with an MIT license.

I have Alan's verbal consent.

"A verbal agreement is not worth the paper it is written on."  

Get a GPG signed email from him.  He seems to be a very trustworthy guy, but still things may change or come out of his control.

[Carlton Banks]

I am certainly no expert on copyright law and licenses, but a sound engineering principle is KISS ("Keep It Simple, Stupid").  I can certainly understand that you prefer MIT license over GNU Affero for your own work (I agree with you here), but you should seriously consider if the extra complication of having to keep track of two different licenses is worth the trouble.  In particular, once you start refactor code you will constantly have to worry about not moving code from an Affero file to an MIT file.  Furthermore, the GNU licenses tends to affect the whole work, so the entire Armory will be under that license, even if people can reuse parts of the project that you alone wrote under MIT license.

Read above. I appreciate KISS but I AGPL has to go and I don't want to rewrite everything from the ground up. Phasing out the old code will be a long term effort along the course of at least 2016.

I can certainly see your point.  I doubt that you will ever end with an Armory without AGPL stuff in it, but the new stuff you write will be easier to integrate into other projects with an MIT license.

I have Alan's verbal consent.

"A verbal agreement is not worth the paper it is written on."  

Get a GPG signed email from him.  He seems to be a very trustworthy guy, but still things may change or come out of his control.

Alan announced the agreement publicly (in this sub), I think that's adequate

[RoadStress]

No he hasn't but I expect it is off limit, and he can't do anything about it either.

What does that mean exactly? Are we able to use the latest builds found on the website or they aren't safe anymore?

[goatpig]

You should seriously think about dropping the name Armory or get permission to use it.

Armory is the name of the company, as well as the product.

I know its a pain, but its actually not covered by any open source licence, that I can see.

I am certainly no expert on copyright law and licenses, but a sound engineering principle is KISS ("Keep It Simple, Stupid").  I can certainly understand that you prefer MIT license over GNU Affero for your own work (I agree with you here), but you should seriously consider if the extra complication of having to keep track of two different licenses is worth the trouble.  In particular, once you start refactor code you will constantly have to worry about not moving code from an Affero file to an MIT file.  Furthermore, the GNU licenses tends to affect the whole work, so the entire Armory will be under that license, even if people can reuse parts of the project that you alone wrote under MIT license.

Read above. I appreciate KISS but I AGPL has to go and I don't want to rewrite everything from the ground up. Phasing out the old code will be a long term effort along the course of at least 2016.

I can certainly see your point.  I doubt that you will ever end with an Armory without AGPL stuff in it, but the new stuff you write will be easier to integrate into other projects with an MIT license.

I have Alan's verbal consent.

"A verbal agreement is not worth the paper it is written on." 

Get a GPG signed email from him.  He seems to be a very trustworthy guy, but still things may change or come out of his control.

I got in touch with the share holders yesterday about the use of their trademark. I'm waiting for their decision before doing anything about that.

No he hasn't but I expect it is off limit, and he can't do anything about it either.

What does that mean exactly? Are we able to use the latest builds found on the website or they aren't safe anymore?

It means I most likely won't have access to the bitcoinarmory.com domain, so unless ATI keeps that up to date, it will decay into obsolescence. As for the builds, it never was a matter of where you downloaded the file, rather if the hash matches the signature and the signature matches Alan's key. This has no changed for now. Once I put out my own builds, I'll make an offline signing key and reveal the public key here for all to check the builds against.

Here is a site for the project that I put together using Github Pages: https://achow101.github.io/BitcoinArmory/. It uses Jekyll (which github recommends using) and Github Pages as the hosting. The code is at https://github.com/achow101/BitcoinArmory/tree/gh-pages and if someone can get a domain, that domain can also be pointed to the site so it uses the domain. Let me know what you think about it.

I'll look into website matters once I have a release.

[RoadStress]

No he hasn't but I expect it is off limit, and he can't do anything about it either.

What does that mean exactly? Are we able to use the latest builds found on the website or they aren't safe anymore?

It means I most likely won't have access to the bitcoinarmory.com domain, so unless ATI keeps that up to date, it will decay into obsolescence. As for the builds, it never was a matter of where you downloaded the file, rather if the hash matches the signature and the signature matches Alan's key. This has no changed for now. Once I put out my own builds, I'll make an offline signing key and reveal the public key here for all to check the builds against.

Much appreciated.

[coins101]

 

[achow101]

You should enable issues on Github, it's in the settings.

Also, I think anything mentioning ATI in the software should be removed, both because ATI is no longer supporting it, and for licensing stuff.

[goatpig]

You should enable issues on Github, it's in the settings.

Also, I think anything mentioning ATI in the software should be removed, both because ATI is no longer supporting it, and for licensing stuff.

Enabled issues.

I can't remove references to ATI, that would break the AGPL licensing terms as well as trademark law (as long as the project uses the Armory name).

[coins101]

You should enable issues on Github, it's in the settings.

Also, I think anything mentioning ATI in the software should be removed, both because ATI is no longer supporting it, and for licensing stuff.

Enabled issues.

I can't remove references to ATI, that would break the AGPL licensing terms as well as trademark law (as long as the project uses the Armory name).

The licensing and trademark are two district issues.  You need to keep the Armory name in the licence, but you need to stop using the name in public to refer to your project, unless the officers of Armory give you written permission to use the name.

Note, there is a difference between shareholders and officers.  The shareholders have no direct say in the day to day running of the Armory business, that's the job and responsibility of the company officers. Getting the permission of shareholders for anything other than buying or selling shares or the whole company is pointless.

[Ente]

I agree to drop the Armory name. This might keep you from bigger problems in the future, and might even give you a slighty better position should all of the old Armory folks come to a round table at a later point. This is a sad moment, with the Armory company structure and dev team being in pieces, so why not take the opportunity to get rid of as much potential ballast as possible.

Another thought: if (all!) the current copyright holders of the code agree, it should be possible to relicense the entire 0.93 code to MIT. Now I don't know the details, but maybe this isn't as impossible as it seems? Maybe they have an (bigger) interest to keep the project and brand alive than to watch the code become obsolete with time..

I read up about GPL vs MIT. Before, I didn't know the details. Goatpig, I applaud you for your strong stance on this topic. "Just" GPL would surely be easier now, but I see your point in being "radically open source" here.
It's an interesting (off topic) discussion point, I personally am unsure what the right way is, generally, on different open source licenses.

Ente

[goatpig]

The licensing and trademark are two district issues.  You need to keep the Armory name in the licence, but you need to stop using the name in public to refer to your project, unless the officers of Armory give you written permission to use the name.

There are talks of giving me a renewable license to use the trademark. I'll be meeting with Alan in person on Monday and go from there.

I agree to drop the Armory name. This might keep you from bigger problems in the future, and might even give you a slighty better position should all of the old Armory folks come to a round table at a later point. This is a sad moment, with the Armory company structure and dev team being in pieces, so why not take the opportunity to get rid of as much potential ballast as possible.

I have several reasons to keep on using the Armory name:

1) Armory has brand name recognition. If I uphold that trademark to the standard it has been so far, the IP retains far more value. This keeps the door open for one day getting a new acquirer, and this could all conclude in reviving Armory as a business and getting the team back together. All devs stuck around with no pay for 6 months, my response to that can't be to just shut down all hope by leaving the trademark to decay.

2) The brand name recognition is beneficial to me too. People on this forum know I've been an active developer of Armory for some 2 years now. They know what I've done and where my skills lie. People outside this forum don't. As an example, while Alan is getting flooded with job offers, I ain't getting snuff. Not that I am complaining. I want to work on Armory anyways, but this is a clear picture of what awaited me had I decided to go job hunting right away instead.

There are several ways for a developer to make a living working on an open source project. It doesn't have to come down to donations. But for the other ways to work, I need my name out there with some achievement behind it if I want these other opportunities to materialize. As far as the Bitcoin business space is concerned, Armory is all Alan. I'll have to change to that if I want to have my cake and eat it to. Doing all that development under the Armory name and demonstrating I can take over where Alan left is beneficial to me as well. I have to look out for myself too.

3) The naming omg... what's the current flavor? Slap some random word on top of wallet and you're done? Or just go with something completely unrelated? What is this, hashtag rap? Who's up for MtnDewWallet? Or what about just Bicycle? If push comes to shove, I will have to change the name, but we aren't there yet. And I dread that time if ever it comes.

4) I don't want someone else to use the name. The share holders benefit from letting me use the trademark. If I was to drop it, they could very well just sell the trademark while the IP entanglement is being dealt with. Then what? Do you want to envision a future where the Armory brand name is bought by a web wallet provider?

5) There are still a lot of individual users and businesses that use and recommend Armory. I don't want to disappoint them, and in the case of businesses, I don't want to harm their image by letting the Armory name they rely upon decay into obsolescence. The image has been harmed enough as it is.

6) I'm a romantic, I don't want to see Armory die, even in name.

7) If I have to change the name, I'd rather do it later, once I have demonstrated my ability to keep the project alive.