Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Friday August 18 2017, @02:36AM   Printer-friendly
from the soldiers-with-benefits dept.

Submitted via IRC for TheMightyBuzzard

The Army's decision to formalize its open-source software development policy is paying off. At least two major projects have benefited from the policy announced this spring, with open source helping to speed development and save taxpayer dollars, according to officials from the U.S. Army Research Laboratory.

"Open source can reduce development time and lower overall costs, resulting in a win-win situation for the Army and the U.S. taxpayer," said ARL Deputy Chief Scientist Mary Harper.

When it comes to defense agencies embracing open-source software development, the Army is hardly at the cutting edge. The National Geospatial-Intelligence Agency paved the way with the launch of its GitHub open-source community in 2014. The Navy issued a guidance on the use of open-source code as early as 2007.

Still, ARL leaders say they expect to reap big benefits by formalizing their approach to open source, a term used to describe software for which the original source code is made freely available and may be shared and modified.

[...] Looking ahead, ARL leaders say their explicit embrace of an open-source approach should be a boon to the other military services. But they aren't yet offering insight into just what those evolutions might look like.

"It's extremely difficult to guess how the code might be used or leveraged by others," Harper said. "ARL's belief is that [the U.S. Army Tank Automotive Research Development and Engineering Center] and other groups will leverage the code as they see fit to support mission and potentially improve ARL's code at the same time. This has been the case for extremely popular open-source projects such as the Linux kernel, and ARL hopes to leverage this power as well."

Source: https://www.federaltimes.com/it-networks/2017/08/14/army-reaps-benefits-of-open-source-policy/


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 0) by Anonymous Coward on Friday August 18 2017, @03:03AM (4 children)

    by Anonymous Coward on Friday August 18 2017, @03:03AM (#555686)

    Open source software is OLD HAT for the Army. Aside from a public proclamation, there is nothing new here.
    When I got my first job out of college way back in 1995, it was writing software for the Army that ran on Linux laptops.

    • (Score: 0) by Anonymous Coward on Friday August 18 2017, @04:21AM (3 children)

      by Anonymous Coward on Friday August 18 2017, @04:21AM (#555702)

      Open Source becomes open source through the use of copyright. But copyright does not apply to government software. It is either Public Domain or Classified.

      You know you need to be more specific when you say you wrote software for the Army. Did you write wholly original software which was Public Domain by law as a work of the US Government? Or did you write partially derivative software which was Open Source under copyright law and open source license?

      In the context you mentioned, the mere fact that the software ran on Linux is fucking irrelevant.

      Now, mod me the fuck down for saying Linux is fucking irrelevant.

      • (Score: 0) by Anonymous Coward on Friday August 18 2017, @05:24AM

        by Anonymous Coward on Friday August 18 2017, @05:24AM (#555727)

        The infrastructure for the software (operating system, common utilities, etc.) was open source.
        I think that was clear.

      • (Score: 1, Informative) by Anonymous Coward on Friday August 18 2017, @05:54AM (1 child)

        by Anonymous Coward on Friday August 18 2017, @05:54AM (#555735)

        You have written quite a bit about copyright for software written for a US Govt contract.
        It's too bad you don't know your subject.

        Here are the facts, excerpted from
        http://www.mccarter.com/Protecting-IP-When-Contracting-With-the-Government-08-31-2010/ [mccarter.com]

        Copyrighted Material

        Contractors may also retain ownership of any copyrighted material developed or delivered under a government contract.

        (...)

        In exchange for the contractor's copyright in material produced during performance of a government contract,
        the government is typically granted a non-exclusive, irrevocable license to use, modify, reproduce, release,
        perform, display, or disclose the copyrighted work by or on behalf of the United States throughout the world.

        End excerpt.
        Notice there is nothing there about public domain. If the contract was written such that the contractor retains copyright, the govt generally can do whatever it wants with the software, even up to releasing it to the public, but that doesn't give the public the right to legally modify and redistribute the software (i.e., put it in public domain).

        • (Score: 2) by The Mighty Buzzard on Friday August 18 2017, @10:51AM

          It depends on if the software was contracted or work-for-hire. In work-for-hire situations, he's absolutely correct; you do not get copyright on your work. This generally isn't going to be the case for software contractors though as we tend to charge way, way more if you want something written that we can never reuse parts of.

          --
          My rights don't end where your fear begins.
  • (Score: 0) by Anonymous Coward on Friday August 18 2017, @03:22AM (1 child)

    by Anonymous Coward on Friday August 18 2017, @03:22AM (#555690)

    Summary is supposed to summarize, a short gist of the main bits. TFA is neither short, nor contain anything of substance - is there actuallly any "main bits?"

    • (Score: 0) by Anonymous Coward on Friday August 18 2017, @03:41AM

      by Anonymous Coward on Friday August 18 2017, @03:41AM (#555693)

      is there actuallly any "main bits?"

      You aren't looking in the right places. Look carefully to your crotch area, do you see any bits there?
      No? Then, as you were, there aren't any bits worth of your attention.
      You found them? Didn't your parents teach you it's not nice to wank in public forums?

  • (Score: 3, Funny) by c0lo on Friday August 18 2017, @03:49AM (5 children)

    by c0lo (156) Subscriber Badge on Friday August 18 2017, @03:49AM (#555695) Journal

    "ARL's belief is that [the U.S. Army Tank Automotive Research Development and Engineering Center] and other groups will leverage the code as they see fit to support mission and potentially improve ARL's code at the same time. This has been the case for extremely popular open-source projects such as the Linux kernel, and ARL hopes to leverage this power as well."

    You know? Not many geeks are able to develop and/or test the software without the appropriate hardware.
    So, unless you provide a tank to 400-1200** [pingdom.com] contributors, I doubt you are going to... mmm... leverage the same popularity as the Linux kernel.

    ---

    ** those numbers are 5 years old

    --
    https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
    • (Score: 0) by Anonymous Coward on Friday August 18 2017, @04:24AM (1 child)

      by Anonymous Coward on Friday August 18 2017, @04:24AM (#555704)

      Tank emulator.

      • (Score: 0) by Anonymous Coward on Friday August 18 2017, @07:50PM

        by Anonymous Coward on Friday August 18 2017, @07:50PM (#556067)

        bzflag?

    • (Score: 2) by Snotnose on Friday August 18 2017, @04:34AM

      by Snotnose (1623) on Friday August 18 2017, @04:34AM (#555711)

      So, unless you provide a tank

      *cough*China*cough*

      Not to mention, the software can give pretty nifty clues as to how the hardware works.

      --
      Why shouldn't we judge a book by it's cover? It's got the author, title, and a summary of what the book's about.
    • (Score: 2) by coolgopher on Friday August 18 2017, @07:35AM (1 child)

      by coolgopher (1157) on Friday August 18 2017, @07:35AM (#555752)

      Yeah, I think that whole idea will tank.

      • (Score: 0) by Anonymous Coward on Friday August 18 2017, @12:51PM

        by Anonymous Coward on Friday August 18 2017, @12:51PM (#555861)

        Is that all the tanks we get?

  • (Score: 3, Informative) by MostCynical on Friday August 18 2017, @07:36AM (1 child)

    by MostCynical (2589) on Friday August 18 2017, @07:36AM (#555753) Journal

    "we've found a way to get geeks to do stuff for us, and we don't even have to pay"

    --
    "I guess once you start doubting, there's no end to it." -Batou, Ghost in the Shell: Stand Alone Complex
    • (Score: 0) by Anonymous Coward on Friday August 18 2017, @11:47AM

      by Anonymous Coward on Friday August 18 2017, @11:47AM (#555835)

      whatever. I say scipy is a lot better than matlab because it is free and open source, and its writers use it so they benefit.

  • (Score: 2) by kaszz on Friday August 18 2017, @10:27AM

    by kaszz (4211) on Friday August 18 2017, @10:27AM (#555815) Journal

    Military -> RedHat -> systemd

    Incoming!! "sorry your system lacks /etc/poett/special/only/red/conslut/specialtypo.txt so can't reboot" .. ..... *BOOM*
    RedHat: No military user has ever complained.

  • (Score: 0) by Anonymous Coward on Friday August 18 2017, @12:12PM

    by Anonymous Coward on Friday August 18 2017, @12:12PM (#555845)

    Here's the git hub site
    https://github.com/USArmyResearchLab [github.com]

    There are 6 projects there.
      2 are not projects, but rather site usage instructions.
      1 is a Python based network traffic decoder.
      1 is a weather data format converter
      2 are programming examples for a low power gpu competitor asic called Adapteva Epiphany

    Pretty harmless stuff. Definitely not giving away any official secrets.

    It's interesting that such a minor site would make the news here.

  • (Score: 1) by pdfernhout on Saturday August 19 2017, @01:13AM

    by pdfernhout (5984) on Saturday August 19 2017, @01:13AM (#556224) Homepage

    https://groups.google.com/d/msg/openmanufacturing/RSKxwIUgB8s/e2fKPZNxWy0J [google.com]

    "Re: [Open Manufacturing] Re: Roadmap for Open Hardware (ohroadmap.org)"

    On 9/24/10 12:51 PM, James - Coder by day, fabber by night wrote:
    > My goal with the www.ohroadmap.org wiki is to develop a technology
    > roadmap which identifies current and future technologies in open
    > hardware/open manufacturing as well as technology gaps, barriers,
    > industry targets, and research areas.
    Here is a rambling sketch of some ideas related to reusability of open
    hardware designs that seeing your Wiki and your description makes me think
    about.
          http://www.ohroadmap.org/ [ohroadmap.org]
          [Link went bad, but see: https://web.archive.org/web/20101030014314/http://www.ohroadmap.org/ [archive.org] ]

    This is also inspired in part from watching the Open Hardware Summit
    streamcast that Bryan posted about, where one participant (possible Eric von
    Hippel?) said there were three big competing issues:
          * project
          * product
          * platform
    Each of these three (project, product, platform) may have different
    requirements or social approaches from an open manufacturing perspective.

    The issue of reusability of designs (especially when all you have is CAD or
    CAM files) is something that has been in the back of my mind for a long
    time, considering the fact that things created by hand often are adapted to
    materials at hand as well as quirky circumstances. Or at least, that's
    tended to be my own experience. :-) I often scrounge around for things and
    adapt designs to materials, tools, and subcomponents that I have easily
    available. I may iterate that process several times, too, as solutions fail
    to be good enough. So, even having detailed 3D designs may not be that
    useful to me, unless I had everything I needed to put together an entire
    complex product. That assuming a design wasn't just all printed as a working
    unit from some amazing nanotech printer, which remains a ways off -- and
    even then, we would probably need to sometimes think in terms of "repair" or
    "improvement" with scrounging whatever was on hand.

    Here is an example inspired by your link to this with a picture of a couple
    of tanks in a desert:
          http://www.mitre.org/news/digest/advanced_research/08_10/layer.html [mitre.org]

    Consider that image, in the context of product, project, and platform.

    I'm personally not very interested in building tanks, as a "product". Tanks
    (or, say, even just self-propelled Howitzers) are a product that is probably
    illegal for me to own, at least if it had live ammo. And even it was legal,
    a tank would be expensive to build and maintain, and having one around might
    worry my neighbors a bunch and mess up the driveway. :-) Related by me:
          "Intrinsic/mutual security vs. extrinsic/unilateral"
          http://slashdot.org/comments.pl?sid=1783364&cid=33537044 [slashdot.org]

    Likewise, I'm not interesting in using a tank to do anything in a desert as
    a "project". Those are typically projects that, as my sig below suggests, I
    consider a likely example of "irony". :-) Also rlated by me:

    http://www.pdfernhout.net/recognizing-irony-is-a-key-to-transcending-militarism.html [pdfernhout.net]

    But tanks have a lot of brackets, and I've very interested in brackets in
    general (as a "platform" in at least two senses of the word. :-) That's as a
    platform to hold things up, and also a platform in a general sense of
    software that might help design brackets to specific needs.

    So, I have a common interest with someone who designs tanks. Brackets are
    just really, really, important in life. :-) I mean, where would be be
    without brackets? Everything would be one big jumble. :-)

    When I was a kid, my father (a merchant mariner, a machinist, and then a
    manufacturing engineer), made brackets for me for some robots I made. But
    now, sadly, he's not around (a casualty to heart disease -- preventable it
    turns out, with the Fuhrman nutritional plan and adequate vitamin D, but I
    did not know that back then).

    So how do I get custom brackets made on demand? Any tank designer must have
    the same problem, or at least the design side of that problem even if other
    people did the manufacturing.

    I could say, look through any non-secret part of a public tank design, and
    hope to get lucky with something that meets my needs for, say, putting up a
    bookshelf.
          "World War II AFV Plans: American Armored Fighting Vehicles"
          http://www.amazon.com/World-War-II-AFV-Plans/dp/0811733408 [amazon.com]

    But, in practice, a bracket with specific dimensions made out of a specific
    material in a specific shape used in a specific tank to hold a specific item
    is probably useless to just about anyone else (except by chance). And even
    if it was a very good design for a similar circumstance, how would you find
    it out of all the other bracket designs out there? And chances are, the
    design for some specific things, like a tank, may just not be shared,
    anyway, even if, as above, you might find some old designs around to some
    degree of detail.

    The logical process that goes into creating an appropriate bracket for
    holding an item at a particular position might be generalizable to some kind
    of "bracket design" software tool. Give it some constraints, and it might
    create you some candidate brackets to consider. Possibly it might do this in
    an interactive and evolutionary way -- perhaps of like this software (we
    wrote) for breeding 3D models of botanical plants, but for brackets? :-)
          http://www.kurtz-fernhout.com/PlantStudio/ [kurtz-fernhout.com]

    My father like probably most people who are handy with tools and have many
    decades of experience making stuff, essentially could do that quickly, maybe
    with a bit of paper and pencil work. But not everyone is so fortunate as to
    have someone like that around for a time.

    There probably is proprietary software already out there that does this,
    like in AutoLISP for AutoCAD? But I'd guess that most everyone still goes
    through these motions every time:
          "Tutorials on Basic Mechanical Design Calculations (part-1) "
            http://www.brighthub.com/engineering/mechanical/articles/15234.aspx [brighthub.com]
    "Today I will talk about design of a simple �L� shaped bracket, one side of
    it is clamped and at the other side it is carrying some amount of load. ..."

    But even if there were proprietary software to do this, it doesn't help me
    personally much, because I'm not going to pay a bunch of money just to
    design one bracket right now. And chances are, the software runs with other
    proprietary software I don't have, either.

    So, one might see that FOSS bracket software tool as part of an open
    "platform" for design. Same for wire routing tools, diagnostic system test
    point insert tools, documentation for maintenance generation tools, viewport
    design tools, and so on. If someone wants to design a new type of vehicle,
    like a SpacePod,
          http://code.google.com/p/openvirgle/wiki/SpacePod [google.com]
    well, one might hope it might eventually be a lot easier and go a lot faster
    using these tools that together make up some kind of open hardware design
    platform. And then many of the same tools could be used for, say, creating
    book shelves stuck on a wall that have brackets. And there's no reason to
    have just the 3D CAD output in a design file. You could have a reference to
    the module you used to design a bracket, and the parameters you used, so
    anyone getting that design could still easily tweak it a bit at the
    parameter level.

      From a mass production standpoint, customization of every vehicle is
    insanity. Why would a big organization want, say, 1000 vehicles each with
    custom parts designed by end users to scratch some specific itch (customized
    seats?) that were not interchangeable? Wasn't it a huge leap forward to have
    interchangeable parts? Still, if you were 3D printing the parts at a
    practically-zero-inventory repair depot that could essentially fix any
    vehicle, then what does it matter if parts are custom? Also, if you had, as
    discussed recently on the list, a really good recycling system, someday, if
    you are really annoyed at a certain vehicle's customization, you just
    recycle the whole thing locally and produce a new one. Or, if you have have
    a vehicle, adapted by its users in various ways that you want to keep and
    bring back into good repair, and you have the CAD files about it, then you
    just print the customized broken part. You might also have automatically
    generated instructions created directly from the design for troubleshooting,
    disassembly, repair, and re-assembly, which a technician could use, perhaps
    guided by graphics displayed on reality by a wearable computer with a heads
    up display? :-) The repair could even be logged and then fed back into
    design software... Thus you have a very adaptive fleet of vehicles... Ones
    that are even flexible reconfigurable. A historic example: :-)
        http://en.wikipedia.org/wiki/Improvised_vehicle_armour [wikipedia.org]

    One key emotional point is that people customizing their equipment probably
    will be motivated to understand it better and probably to take better care
    of it, because it will be "theirs" in that sense. For a story about a world
    of customized products, see:
          http://en.wikipedia.org/wiki/The_Mote_in_God%27s_Eye [wikipedia.org]
    Or for more on the emotional aspect of humans as makers, see my comments
    building on Mark Frauenfelder's:
          http://groups.google.com/group/openmanufacturing/msg/70fec0838320517b [google.com]

    Of course, to create a good platform allowing mass customization may be a
    lot more work (or, at least, different work) than doing specific projects or
    creating specific products. Related to this is the notion that it is easy in
    software to create a class for an "object" in object-oriented programming.
    But to create a generally reusable class to create broadly usable objects
    (probably with some parameters specified at creation time) generally takes
    many times more work than to just create a specific "class". That's why, in
    practice, "reuse" of software has not been as great as expected.

    My father, Klaas Fernhout, the bracket maker (among other talents), as a
    native Dutch speaker, preferred "Klaas" be pronounced different from
    "class", more like the a sound in "hah" (so, customized pronunciation
    compared to a typical English speaker?) But both Klaas and a class are
    related in this context by being able to make things. :-) So, I want a class
    that can do what my father, Klaas, could do as far as generate brackets on
    demand to handle all the unique constraints of the moment. Or, more likely,
    that might take a set of classes that cooperated while maybe generating sets
    of designs that competed, all to help someone do what my father, Klaas,
    could do in his head and with scribbling a bit of paper. :-) Granted, I can
    expect eventually software tools will do bracket design "better" in some
    sense than my father (though perhaps never with as much love. :-)

    Now, from a narrowly defined business perspective that's where it ends.
    There is essentially no point on any specific project for making reusable
    classes, and tools go in and out of fashion, so investment in any platform
    is problematical by a specific company (unless you are selling that platform
    yourself). Who in their right mind would write a piece of software that
    helps people design arbitrary brackets? Unless you were going to sell that
    stand-alone program as a proprietary product -- in which case most people
    probably can't use it. Or unless some big organization who saw the value of
    such tools paid you to do that (and then you promptly abandoned it and went
    on to other new grant-funded things, keeping it artificially scarce just in
    case you might make a bit more money from it someday).
    Related:
          http://www.pdfernhout.net/on-funding-digital-public-works.html [pdfernhout.net]

    And, likewise, for programs, we get programming methodologies like extreme
    programming that design and implement everything just-in-time. And that can
    be a very useful approach for a "project" or even a "product" (especially
    since figuring out the true "requirements" is often most of what any project
    entails). But such an ad-hoc just-in-time approach is more problematical for
    a "platform" that needs to support many projects and products. To make a
    good platform, you usually have to consider a lot of different cases, to see
    what you can generalize from them.

    However, from an open source perspective, the above may just be the
    beginning, not the end. If a lot of people are engaged in using an open
    platform, than it may make sense for people to keep improving different
    things so each is generally reusable, with each person or team working on a
    different module, and the modules somehow working together as a common
    platform used to make products for projects. Someone who cares a lot about
    nice looking functional elegant brackets is going to work really hard on a
    parametrized bracket design module. Maybe it can't design every bracket, but
    it could do a lot of them. This approach might not work well if everything
    was proprietary (and also written to assume different data formats), but
    this approach might work very well if everything was free and open source.
    It might help if such a platform used a common semantic web infrastructure
    too, so communications about design discussions (including determining needs
    and priorities) could be integrated in with each design. Related Wikipedia
    item (and a comment by me):
          http://en.wikipedia.org/wiki/Semantic_Web [wikipedia.org]
          "Raising the bar to supporting a Social Semantic Desktop"
          http://groups.google.com/group/diaspora-dev/msg/8410682ec9ca87ee [google.com]

    So, the platform then is really supporting an incremental design "process"
    as well as an end-product manufacturing "process". So, maybe we need a
    fourth "P" word up at the start, for "process"? :-) And a more
    process-oriented view of open manufacturing might link up with efforts like
    this at NIST:
          "Sustainable and Lifecycle Information-based Manufacturing"
          http://www.nist.gov/mel/msid/dpg/slim.cfm [nist.gov]

    Eventually, we might end up with "designs" that were even just a collection
    of reusable software tools and related parameters, like an electric motor
    design tool linked to a bracket design tool, where you could scale the whole
    thing to fit some need -- produced within a total lifecycle analysis process.

    Now, this is not to say *everything* in a design should be a reusable
    software tool to generate specific things. There may well be some categories
    of things like brackets, porthole creation, wiring, and so on that relate
    more to ad hoc interfacing, whereas some other items (a gyroscope? a CPU?)
    might be more carefully designed items that you are connecting into a system
    just as they are mass produced. One of the very first 3D CAD software, Ivan
    Sutherland's SketchPad, worked in terms of constraints, which are somewhat
    similar to parameterized modules.
          http://en.wikipedia.org/wiki/Sketchpad [wikipedia.org]
    "The main idea was to have master drawings which one could instantiate into
    many duplicates. If the user changed the master drawing, all the instances
    would change as well. Another major invention in Sketchpad was that it let
    the user easily constrain geometric properties in the drawing�for instance,
    the length of a line or the angle between two lines could be fixed."

    So, any real system would probably be a mix of these things, the fixed and
    the variable. And any very generic design that was scalable might well have
    both types of definitions and be scalable within some range. So, for
    example, you might be able to scale a space probe up and down within some
    range until the point where one gyroscope was not powerful enough to orient
    the craft at an acceptable rate. At that point, you'd have to revisit the
    design to replace that component in the design or make other changes.
    (Integrating simulation would help a lot in analysis.) Over time, as 3D
    printing improves, more and more of various open hardware designs might be
    made generic in this fashion. For example, shoes.
          "I just reprapped a left shoe. It cost me 30 pence..."
          http://blog.reprap.org/2008/05/shoe.html [reprap.org]

    It seems that a big promise of open manufacturing is the flexibility to make
    a variety of products to support ad hoc projects or custom fits. But to make
    the most of that flexibility may involve creating a different sort of
    platform than one supporting a more conventional design process where the
    focus is on just one mass-produced product.

    And then once you've specified what you want, scaled as you need it and
    maybe adjusted for local materials and local processes, then you go ahead
    and generate specific CAM files, and have it fabricated (like with SKDB).
    Then, when it breaks, you either recycle it or print a custom part again or
    even an adapter to hold a different part.

    So, the bigger picture on open manufacturing of open hardware is that the
    entire design process may eventually change leading to different products
    maintained in different ways. And we probably want to be creating
    infrastructures for that sort of overall dynamic social design,
    manufacturing, performance analysis, and repair process. But, granted, that
    big picture may be different than any one specific institution with narrow
    objectives may be seeing when it looks at just one part of the open
    manufacturing picture.

    ==

    By the way, the license for the ohroadmap Wiki "Creative Commons
    Attribution-NonCommercial 3.0 License" is not compatible with Wikipedia.
    That may not matter to you, but it is something to consider. Personally, I
    find "non-commercial" clauses problematical, because it's never clear what
    is commercial and what is not (a teacher getting paid to teach about open
    manufacturing seems to me to be commercial, for example). You might ask
    yourself if there any particular reason you want that license as opposed to
    one that is compatible with Wikipedia?
          http://en.wikipedia.org/wiki/Manufacturing [wikipedia.org]

    --Paul Fernhout
    http://www.pdfernhout.net/ [pdfernhout.net]
    ====
    The biggest challenge of the 21st century is the irony of technologies of
    abundance in the hands of those thinking in terms of scarcity.

    --
    The biggest challenge of the 21st century: the irony of technologies of abundance used by scarcity-minded people.
(1)