[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] New Update Manager UI : Your thoughts
|
I like it!
Do that, plus make the default be: plugin provider requires you to agree to
the license agreement.
-Don
On 6/13/07 2:41 PM, "Brett Wooldridge" <bwooldridge@xxxxxxxxxxxxxx> wrote:
> To clarify my point, it was that if a plugin provider chooses to _require_
> that the user acknowledge a license (this is the software equivalent of
> signing a contract or signing a waiver absolving the provider of liability),
> the UI should not be able to bypass that.
>
> I don¹t think it necessarily needs to be that complex -- in line with
> "keeping simple things simple'.
>
> So a possibly more elegant solution would be that accepting a license _the
> first time_ drops a digital signature locally. Any future updates from a
> site that presents that same signature would not require acknowledgement
> because it is in the local cache (similar to SSH keys, if you know what I
> mean). This allows a one time agreement to the license. If the provider
> decides to change the terms of the license and needs the user to acknowledge
> it, he simply changes the signature he presents.
>
> The beauty of this is, if you have an application with an installer it can
> simply install the signature file and therefore the user would never be
> prompted to accept an agreement by the software (he would have already
> acknowledged it in the installer).
>
> -Brett
>
>
> On 6/13/07 1:28 PM, "Laidlaw, Don" <don.laidlaw@xxxxxxxxx> wrote:
>
>> OK, lets step back and look at it differently.
>>
>> I don¹t think this would be illegal, but I am not a lawyer, and I don¹t play
>> one on TV.
>>
>> Infor (the company writing the software) is using equinox server-side to
>> assemble an ERP system at WidgetCo, the company that manufactures widgets.
>>
>> This is not an eclipse IDE of any kind.
>>
>> WidgetCo and Infor have a licensing agreement between them. WidgetCo has
>> purchased a license for Infor¹s software and can receive free updates for 1
>> year from the purchase date. Now, instead of automatically accepting license
>> agreements, we have a more complex requirement, but a real one that needs a
>> solution.
>>
>> Possible options:
>>
>> 1. There are update sites that are always trusted by the update manager. The
>> user that sets the ³I trust this update site² flag must have in essence
>> agreed
>> to the license in advance. Such as free updates for a year as per a license
>> agreement. In this case, Infor will stop populating the WidgetCo update site
>> with new versions after a certain date, and the onus is on Infor to make this
>> happen. Probably by getting a new license agreement signed. Very little needs
>> to be done in the update manager in this case, except to trust sites that are
>> marked as trusted. Notes could be added as to why it is trusted, perhaps.
>>
>> 2. The update sites in the update manager could have attached multiple
>> license
>> keys. These keys are transmitted to the update site with the update request.
>> Now the update site is not a simple set of web pages and resources served by
>> a
>> apache. It needs to be a web application that can validate the license keys.
>> The update site either sends the updates or rejects the request.
>>
>> 3. The update site provided by Infor could be behind a password protected
>> URL.
>> Access to this URL is only given to customers that have a signed license
>> agreement. The license requirements are all handled outside of the scope of
>> the update manager. The the update manager, the update site is marked as
>> trusted.
>>
>> 4. Infor provides a password protected URL from which WidgetCo can download
>> an
>> update site that WidgetCo can host locally. Again, Infor and WidgetCo have
>> the
>> license agreement managed outside of the scope of the update manager. This
>> downloaded and hosted update site is marked as trusted.
>>
>> In all cases, the marking of an update site as trusted means that all license
>> management is being handled outside of the update manager. And the act of
>> marking an update site as trusted means that the administrator has agreed
>> that
>> all licenses required at that site are already handled outside of update
>> manager.
>>
>> An update site should have the ability to override this and say: ³Never allow
>> update manager to trust me². This could even be the default.
>>
>> Without introducing a full blown license management system, we cannot get too
>> complex in the requirements here. But server-side implementations will
>> require
>> the ability to trust some update sites and not need license agreements
>> individually agreed to. If only because sometimes there will be no human and
>> no UI present when the update happens.
>>
>> -Don
>>
>>
>> Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 | mobile:
>> 416-543-1085 | don.laidlaw@xxxxxxxxx
>>
>> On 6/13/07 11:56 AM, "Brett Wooldridge" <bwooldridge@xxxxxxxxxxxxxx> wrote:
>>
>>> I think there are legal ramifications, at least in the United States for
>>> that. While we¹re all annoyed by licenses, I don¹t think you can
>>> ³auto-dismiss them² any more than you can stamp your car loan with your
>>> signature.
>>>
>>> -Brett
>>>
>>> On 6/13/07 8:59 AM, "Laidlaw, Don" <don.laidlaw@xxxxxxxxx> wrote:
>>>
>>>>
>>>> True, but it can also be a policy of a plugin consumer to accept the
>>>> licenses of trusted update sites. Then the consumer only has to determine
>>>> which update sites will always be trusted.
>>>>
>>>> In using equinox on the server side, the update sites will usually be in
>>>> the
>>>> same company.
>>>>
>>>> -Don
>>>>
>>>> Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 |
>>>> mobile:
>>>> 416-543-1085 | don.laidlaw@xxxxxxxxx
>>>>
>>>> On 6/13/07 9:55 AM, "Peter Manahan" <manahan@xxxxxxxxxx> wrote:
>>>>
>>>>>
>>>>> The need for license acceptance is typically a requirement discretion of
>>>>> the plugin provider and not the consumer of the plugins. So allowing the
>>>>> consumer to disable the license acceptance should only be optional at the
>>>>> discretion of the plugin provider.
>>>>>
>>>>> Peter
>>>>>
>>>>> equinox-dev-bounces@xxxxxxxxxxx wrote on 06/13/2007 09:04:39 AM:
>>>>>
>>>>>>
>>>>>> The provisioning system should already know about the sites and
>>>>>> should be able to discover more.
>>>>>>
>>>>>> Actually I missed in there where the users said which plugin they wanted.
>>>>>>
>>>>>> User should not have to accept a license if the plugin is coming
>>>>>> from a known/trusted site. Sites should be ranked in this way
>>>>>>
>>>>>> Restart may not be needed
>>>>>>
>>>>>> Jeff
>>>>>>
>>>>>>
>>>>>
>>>>>>
>>>>>> "Prashant Deva" <prashant.deva@xxxxxxxxx>
>>>>>> Sent by: equinox-dev-bounces@xxxxxxxxxxx
>>>>>> 06/12/2007 08:26 PM
>>>>>>
>>>>>> Please respond to
>>>>>> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>>>>>>
>>>>>> To
>>>>>>
>>>>>> "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
>>>>>>
>>>>>> cc
>>>>>>
>>>>>> Subject
>>>>>>
>>>>>> Re: [equinox-dev] New Update Manager UI : Your thoughts
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ok, here is some thoughts on the gui for installing a new plugin.
>>>>>> This is in keeping with the philosophy of keeping the simple things
>>>>>> simple.
>>>>>> I wish there were a place where I could upload some docs and sample
>>>>>> images to make the point more clear, but i will just type some stufffor
>>>>>> now.
>>>>>>
>>>>>> 1. User clicks on 'Install new plugin' button
>>>>>> 2. Dialog box with single text field asks to enter the url of
>>>>>> pluign update site.
>>>>>> 3. update manager automatically gets the latest available
>>>>>> version of the plugin.
>>>>>> 4. asks the user to accept the license.
>>>>>> 5. if license accepted, then installs plugin and asks user
>>>>>> torestart.
>>>>>>
>>>>>> The update site url, etc are automatically saved by the program and
>>>>>> user doesnt need to give a 'name' along with the url as we have to do
>>>>>> now.
>>>>>> Also no dialog box for confirming 'install all'. All user has to
>>>>>> enter is the url and accept the license.
>>>>>>
>>>>>> the dialog in step 2 can have an 'advanced' button, which when
>>>>>> selected allows user to choose the exact version to install.
>>>>>>
>>>>>> your thoughts? any compulsory steps in the install process we might
>>>>>> be missing this way?
>>>>>>
>>>>>> prashant_______________________________________________
>>>>>> equinox-dev mailing list
>>>>>> equinox-dev@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>>>> _______________________________________________
>>>>>> equinox-dev mailing list
>>>>>> equinox-dev@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> equinox-dev mailing list
>>>>> equinox-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> equinox-dev mailing list
>>>> equinox-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> equinox-dev mailing list
>>> equinox-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>
>>
>>
>>
>>
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 | mobile:
416-543-1085 | don.laidlaw@xxxxxxxxx
