Topic: Moving forward with Armory - page 7. (Read 18350 times)

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

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.

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.

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.


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.


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 have Alan's verbal consent.


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.

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

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.

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.

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.

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

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.

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.

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

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?

Good to know.

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.

That's an interesting point.

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


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.

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)

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


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.

  Look who's back!

Hello hello mister 'Orama. How are you doing?

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


https://bitcointalksearch.org/topic/the-end-of-the-road-for-armory-1351792

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