Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Fw: [cross-project-issues-dev] Remember to update your feature.properties file, to use consistent licensing text


I'll let legal professionals correct me if I'm wrong, but if it were me,
I'd include the new ones in any thing that is new or rebuilt. Even if bundles don't change.
Especially if the feature version (even qualifier) changes then that is to some degree a "new release"
of that feature.  And, especially, of course, if it is to be part of the Helios common repository!
(which is where we need the consistency).

But to be explicit, there is no need in general to do maintenance or re-build old stuff _only_ to get the new SUA.
I've never heard of that being required.

P.S. Actually, anyone can correct me ... you don't need to be a legal professional. :)

 



From: Eric Gwin <eric.gwin@xxxxxxxxxx>
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date: 04/21/2010 01:33 PM
Subject: Re: Fw: [cross-project-issues-dev] Remember to update        your        feature.properties file, to use consistent licensing text
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx





David/All;

I have a legal/procedural question. If I have a repository that contains
old released features, that needs to be rebuilt (P2 and features, but
not plugin bundles), should the new SUA/licence.html be included in the
new/old features or not?

-Eric

David M Williams wrote:
>
> In case anyone hasn't noticed, the Eclipse Foundation has issued a new
> SUA document.
>
> So, for those of you who acted quickly to this request on 4/7, then
> you'll be
> well practiced to easily do it again? :/  
>
> And, for the rest of you, then you've just been reinforced for
> procrastinating. :)
>
> Please revisit bug 306627 for details and exact text to use.
>
https://bugs.eclipse.org/bugs/show_bug.cgi?id=306627
>
> Sorry for the churn. The new SUA is not radically different, but has some
> important clarifications about implications of Eclipse's provisioning
> system.
> Well, you know ... important for legal reasons, hence required for us.
>
> And, in case you are wondering, yes it was considered to "push back" on
> this request, but I think there is just enough time to accommodate it,
> without
> endangering our Simultaneous Release so best to take advantage of
> the timing to get current and consistent.
>
> Much thanks,
>
>
>
>
> ----- Forwarded by David M Williams/Raleigh/IBM on 04/21/2010 10:16 AM
> -----
> From:                  David M Williams/Raleigh/IBM@IBMUS
> To:                  cross-project-issues-dev@xxxxxxxxxxx
> Date:                  04/07/2010 02:03 PM
> Subject:                  [cross-project-issues-dev] Remember to update your
> feature.properties file, to use consistent licensing text
> Sent by:                  cross-project-issues-dev-bounces@xxxxxxxxxxx
>
>
> ------------------------------------------------------------------------
>
>
>
>
> As I'm sure you are all aware, a new Helios Requirement this year is
> to use consistent license text, so the "license acceptance" dialog can
> be made more meaningful and easier to use.
>
> And, that's _exactly_ consistent license text ... same year, same
> text, same capitalization. (I've heard consecutive white space doesn't
> matter, but why push it?).
>
> So, yes, this does means almost all of us have to change.
>
> See bug 306627 for some details on this topic, and the exact text to
> use. _
> __https://bugs.eclipse.org/bugs/show_bug.cgi?id=306627_
>
> Of course, this applies to those features that use the Eclipse SUA and
> if someone was shipping a feature in Helios that didn't use that, then
> you wouldn't want to change yours .... but, then I'd wonder why it was
> in Helios?
>
> For reference, see _http://eclipse.org/legal/guidetolegaldoc.php_
> for details on the legally required documents ... but, this Helios
> requirement goes beyond the minimum requirement and gets us all to use
> the exact same text, so the software can tell when its really the same
> license.
> If you try to get the "standard text" from the website, you need to be
> careful to get the plain HTML and ASCII versions, make sure there's no
> web encoding conversion errors, etc., so probably easiest to get from
> the bugzilla entry.
>
> One disturbing angle that's come up, while some checked if we all use
> the same text, is that some of you are not using ANY (yet).  That is
> really a big "no no" and would be a "stop ship" issue, if found "at
> the last minute" (as far as I know,
> it should be a stop ship issue even for milestones, etc ... but, I'm
> not here to judge ... yet).
>
> So, let's try to get this all corrected for M7, so we don't have to
> monkey around with this routine level of detail for release
> candidates. Plus, if you fix yours for M7, that'll make all the
> slackers really standout in M7 and we can more easily see who they are :)
>
> Much Thanks,
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>  

--
-Eric

Oracle <
http://www.oracle.com>
Eric Gwin | Senior Software Developer
Phone: +613 288 4622 <tel:+613%20288%204622> | | Fax: +613 2382818
<fax:+613%202382818> | | Mobile: +613 8582347 <tel:+613%208582347>
Oracle Java Server Technologies
ORACLE Canada | 45 O'Connor St., Ottawa, Ontario | K1P 6L2
Green Oracle <
http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



Back to the top