There was a small but vocal effort that successfully stopped NOSA 3.0 despite
it fixing issues in NOSA 2.0. The claim was that the problematic clause(s)
failed the OSD and were unnecessary even though government lawyers thought it
was necessary. These clauses, of course, exist in NOSA 2.0.
What about NOSA 3.0?
Thanks,
Cem Karan
—-
Other than quoted laws, regulations or officially published policies, the views
expressed herein are not intended to be used as an authoritative state of law
nor do they reflect official positions of the U.S. Army, Department of Defense
or U.S. Govern
There is a significant difference between deprecating and decertification.
A deprecated api can still be used. One removed (aka decertified) cannot.
The bar for decertification should be exceedingly high.
And how is “bad” decided? Is the limited patent clause in ECL v2 “bad” because
it doe
Nigel T :
> There is a significant difference between deprecating and decertification.
>
> A deprecated api can still be used. One removed (aka decertified) cannot.
>
> The bar for decertification should be exceedingly high.
>
> And how is “bad” decided? Is the limited patent clause in ECL
I agree on all points except rejecting new projects. We don't accept
projects, so we don't reject them. We could ask forges to remove the
license from their list of choices for new projects.
On Tue, Feb 25, 2020 at 10:36 AM Karan, Cem F CIV USARMY CCDC ARL (USA) via
License-discuss wrote:
> Er
Eric S. Raymond wrote on Monday, February 24, 2020 2:10 PM
>
> Simon Phipps :
> > What I'd propose here is that we explore a process for deprecation of
> > licenses by someone other than the license steward. Maybe it would
> > start with a substantiated request endorsed by several regular list
>
