Moving forward with Armory

[goatpig]

Happy to take a look at the IP issue and give you some informal feedback / personal view.

Thanks for the help =). This is my current situation:

I'm mostly concerned about how to properly deal with license headers and wording on the repo, to make it clear the new code is MIT and mine and the old code is GPL3 and ATI's.

This is the original license: https://github.com/etotheipi/BitcoinArmory/blob/master/LICENSE

This is the modified one on my fork: https://github.com/goatpig/BitcoinArmory/blob/dev/LICENSE

Is this acceptable?

Also, this is what the license header looks like on the original code: https://github.com/etotheipi/BitcoinArmory/blob/master/cppForSwig/BlockUtils.cpp#L1

I have modified some of that code already by did not modify the license text on any of the original code files.

This is the header on all new code files: https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/BlockDataMap.cpp#L1

Those files are 90~95% new code, I've copied some of the original utility code into the new class.

Did I mess up anything?

We at BitMEX would be happy to help with resources and hosting. Please email us at support at bitmex dot com if you would like any help. We have plenty of extra capacity.

As for releases and documentation I heartily recommend doing releases on GitHub itself, and creating a gh-pages branch of the repository (or another repo) for docs/public website. That way we all benefit from open development of the docs site. I find in practice that if the repo is discoverable (e.g. there should be links to the GitHub page all over it), the community will submit PRs regularly. This makes keeping documentation helpful and up to date far easier.

Very sorry to hear how 0.94 went. As a team we're happy to help any way we can. Thank you for taking the lead on getting the work started to create a libre 0.94.

That's a kind offer and I appreciate it. While this is an important matter, I'd like to get back to it once I actually have code ready for a release. I will have an easier time doing things properly once I have a new version ready.

I am open to suggestions on this matter, although I think the GitHub release is a seller.

The gh-pages approach sounds really good too. I'll try to figure something out, I'm looking forward to the community submitting PRs.

[1714905471]

1714905471

[1714905471]

1714905471

[1714905471]

1714905471

[1714905471]

1714905471

[1714905471]

1714905471

[Acejam]

This is unfortunate - Armory is one of the best wallets out there in my experience.

Not sure if this helps, but if anyone is looking for inspiration: https://github.com/acejam/BitcoinArmory/tree/ffreeze

[coins101]

Happy to take a look at the IP issue and give you some informal feedback / personal view.

Thanks for the help =). This is my current situation:

I'm mostly concerned about how to properly deal with license headers and wording on the repo, to make it clear the new code is MIT and mine and the old code is GPL3 and ATI's.

This is the original license: https://github.com/etotheipi/BitcoinArmory/blob/master/LICENSE

This is the modified one on my fork: https://github.com/goatpig/BitcoinArmory/blob/dev/LICENSE

Is this acceptable?

Also, this is what the license header looks like on the original code: https://github.com/etotheipi/BitcoinArmory/blob/master/cppForSwig/BlockUtils.cpp#L1

I have modified some of that code already by did not modify the license text on any of the original code files.

This is the header on all new code files: https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/BlockDataMap.cpp#L1

Those files are 90~95% new code, I've copied some of the original utility code into the new class.

Did I mess up anything?
....

First, I'm not a lawyer. But, unfortunately, I have spent many years in dark rooms with lawyers talking about IP on software.

I think what you have done looks ok. I've read through the Armory GNU licence and basically you need to add this to the source code that was created by Armory:

Code:

<one line to give the program's name and a brief idea of what it does.>
    Copyright (C) <year>  <name of author>

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU Affero General Public License as
    published by the Free Software Foundation, either version 3 of the
    License, or (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU Affero General Public License for more details.

    You should have received a copy of the GNU Affero General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.

http://www.gnu.org/licenses/agpl-3.0.en.html

So, you'll have a mixture of code licences that you might want people to compile according to where the code starts:

* Armory code should start with the Armory licence terms

Code:

Copyright (C) 2011-2015, Armory Technologies, Inc.                        //
//  Distributed under the GNU Affero General Public License (AGPL v3)         //
//  See LICENSE or http://www.gnu.org/licenses/agpl.html 

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU Affero General Public License as
    published by the Free Software Foundation, either version 3 of the
    License, or (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU Affero General Public License for more details.

    You should have received a copy of the GNU Affero General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.

* Your new code can then start with:

Code:

//   Copyright (C) 2016,  <copyright holders>         //
//  Distributed under the MIT License                           //
//  See LICENCE or https://opensource.org/licenses/MIT //

I take it there is no other code you'll be using that has come form Armory, that has not been released on the GNU licence?

By using the Armory code now, you should be ok if someone decides to buy the company or its assets and then changes the licence.

I'll keep reading around to see if the above thoughts need modification.

[coins101]

The risk you face, without knowing the details, is this:

Along the way, we accumulated a mess of legal and corporate complexity that has made it difficult to do anything constructive with Armory's intellectual property.  These complexities make it risky for me to continue development, even if the money was there to pay me a salary.  It has also made it difficult to be acquired by another company that shares my vision, that could provide funding to see its execution.  

https://bitcointalk.org/index.php?topic=1351792.0

The CEO / core developer is evidently aware of some legal issues and in particular around IP.

It could be that the GNU licence made if difficult to raise investor money as the company was giving away its core product for free.

What you might want to do is write to Armory stating what you are doing with the Armory source code that is on their github repo. Then also explain that you may modify and add to their source code, but you are doing so under the MIT licence on any new additions. Then give them a period, say 30 days, to respond with any specific objections. The response period is not relevant as they or future owners of the IP have many years to raise legal objections. Asking them to give you feedback is more of a way to get some guidance back to you within a reasonable time period.

* Personally, I would also drop the Armory name or significant references to it, other than in passing or for historical reference. The name could be seen as necessary brand IP the company might want to protect in order to gain value from.

* Trade secrets - I'd also avoid saying things like, 'based on my internal knowledge, Armory were going to do .....xxxxx...., so that's what I'm going to do as part of my new road map.'

[RoadStress]

Many thanks to both @etotheipi and @goatpig for all you've done,

please any chance to keep Armory alive and include Trezor support?

  Look who's back!

Hello hello mister 'Orama. How are you doing?

[goatpig]

I take it there is no other code you'll be using that has come form Armory, that has not been released on the GNU licence?

By using the Armory code now, you should be ok if someone decides to buy the company or its assets and then changes the licence.

I'll keep reading around to see if the above thoughts need modification.

Indeed, I won't touch anything from ATI that hasn't been explicitly released under the GNU license. I also won't touch any of the original 0.94 code (that I have locally, but won't be using because it is mired in the IP entanglement like a lot of our former code). I'm actually approaching the DB design under a different angle entirely, so I won't even look at that stuff for inspiration.

A couple questions:

1) Is it fine if I don't update the license anywhere on original Armory files even though I'm modifying its content (sometimes up to 10~15% I expect)? I don't care if those changes are somehow considered falling under the scope of the GPL license, not like they make any sense without the new MIT licensed code.

2) Do I have to add the GPL license header to my new code files if I recycle some 5~10% of Armory's code there? (copy paste code blocks in new file and modify them there)

----------------------------------

The CEO / core developer is evidently aware of some legal issues and in particular around IP.

What you might want to do is write to Armory stating what you are doing with the Armory source code that is on their github repo. Then also explain that you may modify and add to their source code, but you are doing so under the MIT licence. Then give them a period, say 30 days, to respond with any specific objections. The response period is not relevant as they or future owners of the IP have many years to raise legal objections. Asking them to give you feedback is more of a way to get some guidance back to you within a reasonable time period.

I've worked at Armory for over 2 years, I know the details of the IP snafu. Alan gave me the go ahead to work on top of 0.93.3 (as in it's the legally safe start point). I'm not expecting any legal back fire on that front. I also believe the share holders in general approve that I forward development on my own time under the conditions that I don't go around leaking IP in contention.

What I am mostly concerned about is keeping this whole forking "Kosher": I don't want the new code that will coexist and be intertwined with the old code to somehow fall under the umbrella of the preexisting IP contention because I messed up on my due diligences with license language and what not.

[coins101]

...
What I am mostly concerned about is keeping this whole forking "Kosher": I don't want the new code that will coexist and be intertwined with the old code to somehow fall under the umbrella of the preexisting IP contention because I messed up on my due diligences with license language and what not.

That's an interesting point.

GNU does say you're able to modify and adopt. The intention of the licence is:

Developers that use our General Public Licenses protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License which gives you legal permission to copy, distribute and/or modify the software.

Because you are releasing all new code under the MIT licence, I tend to think you don't have any issues to worry about when mixing/matching code.

[coins101]

..... Alan gave me the go ahead to work on top of 0.93.3 (as in it's the legally safe start point). I'm not expecting any legal back fire on that front. I also believe the share holders in general approve that I forward development on my own time under the conditions that I don't go around leaking IP in contention.

..

Unless you have something in writing, you don't have anything. That's been my experience. Verbal agreements are valid, but hard to prove if someone changes their mind, moves on, etc.

[goatpig]

Unless you have something in writing, you don't have anything. That's been my experience. Verbal agreements are valid, but hard to prove if someone changes their mind, moves on, etc.

Good to know.

[wttbs]

Sad to hear about the end of the road with armony but good to hear development is picked up again.

Maybe a noob question, but I am using Armory 0.93.3, I assume I can keep on using it without any problem?

[goatpig]

Sad to hear about the end of the road with armony but good to hear development is picked up again.

Maybe a noob question, but I am using Armory 0.93.3, I assume I can keep on using it without any problem?

Yes you are fine. I do suggest you upgrade once I'm done with the next version though =).

[Roy Badami]

What I am mostly concerned about is keeping this whole forking "Kosher": I don't want the new code that will coexist and be intertwined with the old code to somehow fall under the umbrella of the preexisting IP contention because I messed up on my due diligences with license language and what not.

CAUTION: I AM NOT A LAWYER.  But I think I can probably steer you in broadly the right direction nonetheless.

You own the copyright to the new code that you write on your own dime.  Nothing can restrict your right to do what you like with your code, short of selling or otherwise assigning the copyright to someone else.  The license you release your code under is your grant of a license to other people; it tells other people what they are allowed to do with your code.  But you are always free to do what you like with your code - including relicense it under different terms - since you own it.

(EDIT: rewritten this para)  The things you have to worry about are that you don't end up using code that ATI owns contrary to any license grant.  And secondly that you don't end up releasing a product that it is effectively impossible for anyone to run without using code that ATI owns contrary to any license grant.  At the moment, the only license grant for the ATI-owned code is the GNU Affero GPL it was publicly released under, but of course you're always free to try to negotiate some more permissive license grant with ATI.

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. 0.93.3 files that you modify should instead be treated as derivative works, IMHO.  The way I'd proceed is as follows.

The way I see it, you have three types of files.

1. Files from 0.93.3 which you haven't modified.  Keep the copyright notice and license unchanged on these files.  These files are owned and licensed by ATI.  Obviously over time there will be fewer of these; that's fine.

2. Files from 0.93.3 that you have modified.  These files are derivative works of ATI's work, and both you and ATI have copyright claims on them.  Keep these files under the GNU Affero GPL, but update the copyright notice to include both your copyright claim and ATI's.  You can't relicense these derivative works except in accordance with ATI's license grant.  Fortunately the GNU Affero GPL allows you to create derivative works provided they are licensed on the same terms.

3. New files that are entirely your own work, on your own dime.  You own the copyright on these files, so you are technically free to release these under any other license you choose - but if this license you choose were incompatible with the GNU Affero GPL then it may be impossible for anyone to legally comply with all the licenses.  Any license that is compatible with the GNU Affero GPL is fine here, so a permissive license such as the MIT license should be absolutely fine.  These new files should contain just your copyright notice and the relevant license (and no reference to ATI).

Your LICENSE file should then simply indicate that portions are copyright ATI and portions are copyright you, and that furthermore portions are licensed under the GNU Affero GPL and portions are licensed under the MIT license, and include the text of both licenses for reference.  It should instruct people to refer to individual source files to find out the copyright and license that applies to those files.  EDIT: I'd rename the existing LICENSE file to LICENSE-ATI or LICENSE-0.93.3 or some such, and leave it unchanged except for a some added text at the beginning saying this was the license under which ATI released 0.93.3.  I'd then reference the LICENSE-ATI file from your new LICENSE file, too, and indicate that this was the license under which the ATI-owned code was orignally released.  This is useful for reference, and it also avoids breaking the reference in the ATI copyright messages to see the LICENSE file.

Obviously, you want to aim to modularise things in such a way as to maximise the number of files that fall into category 3 - but of course you have to be careful when refactoring not to accidentally move pieces of ATI-derived code into your category 3 files - or at least, if you do, you should recategorise those files as category 2.

I'm pretty sure what I describe above is safe, and is the most sensible way to proceed, but once again IANAL.  Happy  to answer questions, though, if any of the above is unclear.  EDIT: And of course happy to review and comment on your updated license/copyright notices.

Regards,

roy

EDIT: Significant edits to the above - you may want to reread.
EDIT: Further edits to the advice on LICENSE files.

[wttbs]

Sad to hear about the end of the road with armony but good to hear development is picked up again.

Maybe a noob question, but I am using Armory 0.93.3, I assume I can keep on using it without any problem?

Yes you are fine. I do suggest you upgrade once I'm done with the next version though =).

Thanks for the quick reply. I sure will use your next version. If you (beta)tester just let me know and I will follow this topic of course.

[iwasneverhere]

Hope it all works out. When the time comes I will play my part and donate.

[Roy Badami]

And to follow up, of course for an easy life, you could just release everything under the GNU Affero GPL.  But I applaud your desire to release under a permissive license.  It will only really benefit anyone, though, where there are significant amounts of self-contained new permissively licensed (category 3) code that would be useful to some other project that for what ever reason couldn't (or didn't want to) use any ATI-derived code.

[Roy Badami]

Also to add.  99% of this is about avoiding legal disputes in the first place.  Whether or not you intend to follow my advice, you'd be well advised to run whatever approach you do settle on by any contacts you have at ATI for their opinion.  It ultimately matters not who would win in court, unless you have the inclination and resources to see a lawsuit.  What matters is whether you're doing something that might cause ATI to feel aggrieved and which might incline them to take legal action.

EDIT: But don't worry too much if ATI is effectively defunct and you can't get a formal opinion.  An informal opinion is still better than nothing (particularly given unspecified legal complications with the IP) but I would say it's by no means essential, and I wouldn't worry unduly.

[gangtraet]

goatpig:

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.

An alternative might be to keep Armory under the original license, but if you make whole, self-contained modules then release these under the MIT license as well.
It might be less satisfactory, but may keep your life simpler.

[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.

[unamis76]

I get away from the forums for a bit of time and this happens... Pretty sad to see so many complications surrounding my favorite desktop and Cold Storage client. I'd like to wish etotheipi all of the best and I hope to see him back to Armory development soon.

I guess the lack of updates predicted something bad was happening at Armory. I guess Armory is a great idea that is turning into reality too soon for the general public/companies.

Anyways, good to see someone taking up development on their own! I'd like to wish goatpig all of the best in developing this, hopefully without too many licensing complications which may unfortunately hinder development... We'll see what the future has in store.

I'd also like to say I am available to contribute with funds for further development, if needed. I don't have much, but if every user contributes a bit, we can make things happen.

Beyond this, I have no help to offer. No code talents, neither a licensing whiz either (Thanks for everyone leaving valuable input, pretty interesting to learn about all these licensing issues). I can however help testing further Armory versions, if needed.

[goatpig]

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've followed your advice and update the licensing language, also added LICENSE-MIT and LICENSE-ATI. Please let me know if that is satisfactory.

And to follow up, of course for an easy life, you could just release everything under the GNU Affero GPL.

My goal in all this is to forward Bitcoin in some way. I believe Armory is the ideal vessel to deliver a complete stack, key in hand professional grade solution that fully embraces Bitcoin's model, in that it allows individuals and organizations to have total control over the code they run and the cryptographic material they own. I believe that kind of tool is necessary for Bitcoin to thrive.

With all due respect, to whom it may concern, if there was good competition in this space, I would not see the need to keep Armory going. I do not believe such competition exists right now, nor in the few years to come, and that is mainly because of the models other people in this space adopt, which do not fully embrace the opportunity of a paradigm shift in finance and business that Bitcoin offers us.

While I commend Armory's competitor on their hard work and passion, I do not believe they will fill the gap Armory would create was it to actually disappear, and I believe that role to be foundational to the good health of the Bitcoin ecosystem.

My vision of Armory is to keep forwarding it as an industry standard, with cutting edge, robust and high performance features to deliver the full Bitcoin experience to power users, financiers and businesses. Don't get me wrong, I love the individual users too, but they aren't encumbered by the legality of intellectual property rights the same way as businesses and organizations are.

Open source code is a full and unalienable property of Bitcoin's model. As such, any tool hoping to achieve what I just described has to be open source as well. On top of that, the particular license should not deter the target, otherwise I would consider the Armory experiment a failure and all my work for naught.

The MIT license (or something as permissive like OpenLDAP license) is a sine qua non condition to my ongoing involvement. If I was unable to develop Armory in such open manner, I would either have to start from scratch or I would try the next best thing I have in mind to forward Bitcoin, i.e. participate directly to Bitcoin's development.

If my memory serves right, Armory became AGPL3 when ATI was created, because it allowed the code to remain publicly available while offering opportunities to charge businesses that looked to integrate with our stack. Instead, here we are. Don't get me wrong, I like money. I believe the people involved with Armory deserve proper compensation for their effort. I believe I deserve proper compensation for my work too, and I do not believe in free lunches. But so far, the only thing I've seen the AGPL license achieve is to complicate the situation and slow down the project to a halt, as well as barring me from code I wrote.

The results do not justify the potential benefits, and there will be no code created under the AGPL3 license while I remain in charge. My long term plan is to phase out all mission critical pieces of code by overhauling them one at a time, while maintaining the new code properly secluded. I will also refrain from copy pasting old Armory code into new code from now on and instead rewrite the functionality fully. There aren't 20 ways of doing certain things correctly though, so there is only so much divergence I can introduce on purpose in certain places.

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.

you'd be well advised to run whatever approach you do settle on by any contacts you have at ATI for their opinion.

I have Alan's verbal consent.

What matters is whether you're doing something that might cause ATI to feel aggrieved and which might incline them to take legal action.

Hopefully that won't happen. When it comes down to it, my actions benefit ATI in that it keeps the brand alive and the software up to date. It's a win-win if they simply let me do my thing while the IP encumbrance is being worked out.